Builtplain
Join free
Technology

p=none Blocks Nothing: The Staged Route to DMARC Enforcement, Without the pct Ramp

A DMARC record set to p=none tells receiving servers to do nothing at all. RFC 9989 also deleted the pct tag that most rollout guides still teach. Four stages, an exit criterion for each, and the exact record to publish.

Dana Whitfield 5 min read

If your domain publishes v=DMARC1; p=none, no receiving server is blocking anything sent in your name. That is what the policy says: monitor, report, deliver as normal. Getting to a policy that actually stops a forged invoice means four stages, each with a clear exit criterion, and the work in the middle is inventory rather than DNS. One thing changed in May 2026 that most guides have not caught up with: RFC 9989 obsoleted RFC 7489 and removed the pct tag, so the 10, 25, 50, 75, 100 ramp that Microsoft's own documentation still describes has no standing in the current specification. The replacement is a tag called t.

Why a published record is not protection

DMARC only asks a receiver to check that the domain in the visible From address lines up with a domain that passed SPF or DKIM, then to apply the policy you published when neither aligns. RFC 9989 calls the p=none state monitoring mode: the domain owner gets aggregate reports and nothing else happens. Microsoft's documentation for Microsoft 365 spells out the three dispositions on inbound mail that fails: p=none takes no DMARC-specific action, p=quarantine sends the message to Junk Email, and p=reject refuses it during SMTP with a 550 5.7.1.

Compliance pressure has not closed this gap, because compliance does not require enforcement. Google's sender requirements, in force since 1 February 2024, oblige bulk senders of 5,000 or more messages a day to Gmail to publish DMARC, and then say in as many words: "Your DMARC enforcement policy can be set to none." A domain can satisfy Gmail, pass an audit, and still be spoofable.

For a sense of scale rather than proof: CipherCue queried DNS for 67,336 domains in its tracked-entity dataset between 14 April and 28 July 2026 and found 54.9% with any DMARC record, of which 42.5% sat at p=none, giving 68.4% of all domains checked with either no record or a non-enforcing one (checked 28 July 2026). The authors say the dataset is not statistically representative of companies globally, so read it as a shape, not a population figure.

Stage one: publish monitoring and read what comes back

Set SPF and DKIM up first and wait 48 hours before adding DMARC, which is Google's own instruction. Then publish a TXT record at the host _dmarc:

v=DMARC1; p=none; rua=mailto:[email protected]

Three details save a week each. Send reports to a shared mailbox, never a person's inbox, because the volume is daily and the format is gzipped XML. If that mailbox is on a different domain from the one being monitored, the receiving domain has to publish a TXT record at example.com._report._dmarc with the value v=DMARC1; or the reports are simply never delivered. And skip ruf at the start: Gmail does not support it, Microsoft 365 does not send failure reports at all, and the volume is per-failure.

Exit criterion: two full weeks of aggregate reports in which every sending source you can see is one you recognise. Expect gaps. Microsoft puts report coverage at typically 70% to 90% of total mail volume, so a quiet week does not mean a clean inventory.

Stage two: align the senders you found

Almost every failure at this point is one of two patterns, and the aggregate report XML tells you which. Read the policy_evaluated block against the auth_results block:

  • SPF authenticated but did not align. Your invoicing tool or newsletter platform sends with its own bounce domain, so SPF passes for bounce.vendor.com while your From address says example.com. Two fixes: set a custom MAIL FROM at the vendor pointing to a subdomain you control, or turn on DKIM signing at the vendor with d=example.com.
  • DKIM authenticated but did not align. The vendor signs with its own domain. The fix is custom DKIM signing at the vendor, which most now support and few enable by default.

Either fix is enough on its own. A message passes DMARC if SPF alignment or DKIM alignment passes, and fails only when both fail. Prefer the DKIM route where you have the choice, because a DKIM signature survives forwarding when the body is not modified, while SPF does not survive it at all.

While you are enumerating senders, keep bulk and transactional mail on separate subdomains. Each subdomain needs its own SPF and DKIM even though it inherits the parent's DMARC policy, and the separation means a marketing platform cannot drag your password resets down with it.

Exit criterion: seven consecutive days where every source you recognise shows an alignment pass, and the only failures left are ones you cannot identify.

Stage three: quarantine, and the tag that replaced pct

Move the policy up:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

The old advice was to soften this with pct=25 and climb. RFC 9989 removed pct in Appendix A.6, and the tag list it defines is now v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t. The t tag is the sanctioned way to hold back: it signals whether the domain owner wants the policy in p, sp or np actually applied, and when set to y it asks receivers to apply a policy one level below the one you declared. So p=reject; t=y behaves like quarantine while telling everyone where you are heading, and removing t is the switch.

Two caveats worth knowing before you flip it. Older receivers still implement RFC 7489 and will not understand t, and mail you send through Microsoft 365 that fails DMARC at the destination gets routed through the high-risk delivery pool once your policy is quarantine or reject, with no override. Start with a low-volume subdomain rather than the domain your customers reply to.

Exit criterion: two weeks at quarantine with no legitimate mail reported missing by staff or customers.

Stage four: reject, and the domains nobody sends from

The final record, with a subdomain policy stated explicitly rather than inherited:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]

np is new in RFC 9989 and covers non-existent subdomains, which is precisely what a spoofer picks when the parent domain is locked down. RFC 9989 also replaced the Public Suffix List with a DNS tree walk, capped at eight queries, for finding which policy applies to a given name, which is why declaring your own subdomain policy is now worth the bytes.

Then handle the domains you registered and never used. Microsoft's guidance for parked domains is a single line with no reporting address, since no valid mail should ever come from them:

v=DMARC1; p=reject;

Check what you have published with one command: dig +short TXT _dmarc.example.com.

The attacks this does not touch

DMARC governs exact-domain spoofing and nothing else. An email from example-billing.com or exarnple.com passes its own authentication perfectly and arrives untouched, which is why the payment-diversion emails that cost businesses real money usually come from look-alike domains rather than yours. Enforcement also creates a known failure mode with mailing lists and forwarding, where the body is modified and both checks fail; the remedy is ARC, and for a small sender the practical answer is often to accept the loss and keep the policy. And none of this changes deliverability on its own: reputation and complaint rate still decide whether your mail lands, which is a separate set of published thresholds.

What enforcement does buy is narrow and worth having: nobody can send mail that displays your exact domain in the From line to a receiver that honours DMARC. For a company whose name is on a product, that is the same instinct as filing against a counterfeit of your own app. The identity is the asset, and leaving it at p=none is leaving the door open while filing the paperwork that says you have a door.

Discussion

Sign in with Google or just a name. No email link, no password to remember.