DMARC from p=none to p=reject, safely.

Why is p=none not actually protecting you?

A DMARC record at p=none tells receiving servers to take no action on messages that fail authentication. Every message is delivered normally, whether it passes or fails; the record's only job is to generate the aggregate reports that show who is sending mail as your domain. That makes p=none a discovery tool, not a defence — and a domain that sits there permanently is watching spoofing happen without stopping it.

This is not theoretical. Audit a domain at p=none and its reports routinely show mail from IP addresses in countries where the organisation has no presence, sent through servers it has never used. Those spoofed messages get marked as spam and reported as phishing by recipients, and mailbox providers fold that behaviour into your domain reputation — they do not distinguish between mail you sent and mail someone else sent in your name. Staying at p=none lets that damage accumulate.

The scale of the gap is striking. Across domains engaged enough to run a monitoring tool, around forty percent still sit permanently at p=none, and of the top ten million domains by traffic only a few percent enforce quarantine or reject at all. Reaching enforcement therefore does more than protect you — it puts you ahead of the overwhelming majority of the internet that has published DMARC but never switched it on.

What about subdomains and the sp and np tags?

Subdomains are where many enforcement projects quietly leak. If you omit the sp tag, subdomains inherit your p policy automatically — so a root at p=reject also rejects for every subdomain, which is usually what you want. The misconfiguration to hunt for is the opposite: p=reject paired with sp=none, which locks your root domain while leaving every subdomain spoofable. sp governs existing subdomains; np governs non-existent ones. Omit sp and subdomains inherit p. The p=reject with sp=none mismatch is the misconfiguration to watch.

DMARCbis adds np for subdomains that do not exist at all. An attacker can forge mail from a subdomain you never created, and without np a receiver falls back to your sp or p policy for those names. Setting np=reject closes that gap, but test it first — some services spin up dynamic subdomains, and a blanket np=reject can catch legitimate mail you had forgotten about. Under the new DNS Tree Walk, receivers find your organizational domain by walking up the DNS tree rather than consulting the Public Suffix List, which changes nothing day to day but can matter in deep domain hierarchies.

One piece of DMARCbis guidance deserves a direct mention: The spec explicitly advises against p=reject for domains with active mailing-list traffic, to avoid breaking subscribers. If your people post to open-source project lists, industry forums, or association newsletters from your primary domain, full reject can break those messages for subscribers. The usual fix is to send list traffic from a dedicated subdomain with its own, softer policy, keeping the root domain strict.

One DMARCbis pitfall deserves a warning of its own, because it surprises careful administrators. The new t=y testing tag is meant to let you signal "I am still testing enforcement" without applying full policy — but it only works on receivers that already understand DMARCbis. To the large population of receivers still running the older specification as of 2026, t is an unknown tag, so they ignore it and apply your p=reject directly, with no downgrade. The result is two receiver populations behaving differently for the same record: some treating your mail as a test, others rejecting failures outright. If you reach for t=y expecting a universal soft-launch, you will not get one, and the safer path remains the operational ramp — prove your senders pass, then commit to the policy rather than relying on a testing flag whose effect depends on who is reading it.

The third-party senders that break enforcement

If a migration fails, the cause is almost always a sender you forgot you had. The reports surface them, but only if you read them: a marketing platform added last year, a help desk that emails on your behalf, a billing system on a legacy server, an acquisition's old domain still sending invoices. Each one has to pass DKIM or SPF with alignment to your visible From domain before you tighten the policy, and each one tends to fail in its own quietly specific way.

SPF is capped at ten DNS lookups, and that ceiling is easy to breach as you bolt on tools. Add a CRM, a help desk, a marketing platform, and a transactional provider, and the chained includes can push past ten, at which point SPF returns a permanent error and cascades straight into DMARC failures for legitimate mail. The fix is to audit and flatten the record, keeping it inside the limit, and to move providers that send from their own subdomains off the root SPF entirely where the platform allows it.

DKIM has its own failure modes that hide until enforcement catches them. Signatures configured correctly at setup break during a migration — a website provider changes, a CRM is swapped, DNS moves to a new host — and nobody verifies the DKIM records came along. Records get applied to a www subdomain instead of the root, TTL values cause validation failures at strict receivers, and vendor CNAME instructions are simply wrong until the vendor issues corrected values. None of these show up while you are at p=none; all of them block real mail the moment you reach quarantine, which is exactly why the monitoring phase exists.

Where we stand

We host sending infrastructure, so reaching enforcement matters to us: mail sent from clean, well-authenticated infrastructure is what makes a reject policy safe in the first place. But the migration itself is yours to drive from your reports, and the honest advice is the unglamorous kind — go slow, fix senders before you tighten, and never advance a stage to hit a deadline. A domain rushed to p=reject that blocks its own invoices has not improved its security; it has created an outage.

If you run your sending with us, we will make sure your streams pass SPF and DKIM with alignment and keep your reputation clean enough that enforcement is a non-event. If you self-host or send through an ESP, the same sequence applies regardless of who runs the servers: publish p=none, read the reports, fix every legitimate sender, and walk the policy up only as the data lets you. The reward at the end is real — spoofing stopped, reputation protected, and BIMI within reach.