Moving DMARC From p=none to p=reject Without Breaking Mail

To move DMARC from p=none to p=reject safely, first use aggregate reports to find every legitimate source sending as your domain and make each one pass aligned SPF or DKIM. Then step to quarantine in testing mode, then full quarantine, then reject, moving on only when the reports show nothing legitimate failing.

The order hasn't changed in a decade. What changed in May 2026 is the tool most guides use for the middle steps. RFC 9989, the new DMARC standard, retired the pct tag. Google's own recommended rollout page, last updated 1 October 2026, still tells you to use pct=5. This guide works with both.

Why p=none isn't the finish line

p=none asks receivers to do nothing different with mail that fails DMARC. It meets the minimum Google, Yahoo and Microsoft set for bulk senders (see Gmail and Yahoo bulk sender requirements), and it gets you reports. It does not stop anyone sending mail that claims to be from your domain.

Most of the large brands we looked at have finished this move. When we checked the published DMARC policy of 40 large consumer and B2B brands with dig on 1 October 2026, 35 were at p=reject, 4 at p=quarantine and 1 at p=none. Those companies have big security teams. The steps below are what they did, scaled down.

What changed: pct is out, t is in

Under the old specification, RFC 7489, pct=10 asked receivers to apply your policy to 10% of failing mail. RFC 9989 explains why that was dropped (Appendix A.6):

Operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.

Its replacement is the t tag, with two values. t=y asks receivers not to apply your stated policy and to apply "one level below" it instead: p=reject; t=y behaves like quarantine, and p=quarantine; t=y behaves like none. t=n (the default) means enforce. RFC 9989 says these are "analogous" to pct=0 and pct=100.

The transition problem is that receivers will update at different speeds. A receiver on the new standard ignores pct ("unknown tags MUST be ignored"), and a receiver still on RFC 7489 ignores t for the same reason. Fortunately the two old and new testing values agree. RFC 7489 says that when mail escapes a reject policy because of pct, the receiver "SHOULD treat the email as though the 'quarantine' policy applies." So during the transition you can publish both and get the same behaviour from either kind of receiver:

v=DMARC1; p=reject; t=y; pct=0; rua=mailto:dmarc@example.com

An RFC 9989 receiver reads t=y and quarantines. An RFC 7489 receiver reads pct=0 and quarantines. That combination is our reading of the two specifications rather than something either document prescribes, so watch your reports after publishing it.

What you lose is the 1%, 5%, 25% ramp. Given the RFC's own finding that receivers applied those values inconsistently, you were losing less than it seemed.

The staged rollout

Stage	Record	What receivers do	Move on when...
0. Monitor	p=none; rua=...	Nothing; send reports	Every legitimate source passes aligned SPF or DKIM for 2-4 weeks
1. Quarantine, testing	p=quarantine; t=y; pct=0; rua=...	Treat as none (new) or apply local classification (old)	No new failing sources appear
2. Quarantine	p=quarantine; rua=...	Failing mail to spam	2-4 weeks with no legitimate mail failing
3. Reject, testing	p=reject; t=y; pct=0; rua=...	Treat as quarantine	Reports stay clean
4. Reject	p=reject; rua=...	Refuse failing mail	Keep reading reports

The time at each stage is a judgement, not a standard. Google's page suggests one week at p=none because "One week is usually enough time for the daily reports to contain data representative of all your mail streams." We'd stay longer if your domain has anything that sends monthly or quarterly, such as invoices, payroll notices or annual renewals. A sender that only mails on the first of the month is invisible in a one-week window.

Three tags to settle before you leave stage 0:

• sp sets the policy for subdomains. If you omit it, subdomains inherit p. If some subdomain still has unaligned mail, set sp=none temporarily rather than holding back the whole domain.
• np, standardised in RFC 9989, is a policy for subdomains that don't exist. np=reject stops spoofing of made-up subdomains like billing-secure.example.com, and you can usually set it early because nothing legitimate can send from a name that doesn't exist.
• rua must be there at every stage. Without reports you are changing policy blind.

You can build any of these records with our DMARC generator and check what is live with the DMARC checker.

Reading aggregate reports

Aggregate (rua) reports are XML files that receivers send, usually daily. RFC 9990 defines the format. A single record from the sample in RFC 9990 Appendix B looks like this:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>pass</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>example.com</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim>
    <spf><domain>example.com</domain><result>fail</result></spf>
  </auth_results>
</record>

Read it as: 123 messages from IP 192.0.2.123 claimed to be from example.com. DKIM passed and aligned, SPF failed, and because DMARC needs only one aligned pass, the result is a pass.

For each source IP, ask three questions:

1. Is this sender ours? Look up the IP's owner and reverse DNS. If it's your ESP, CRM or helpdesk, it's legitimate. If it's a residential IP in a country you don't operate in, it's spoofing, which is exactly what reject is for.
2. If it's ours, does it pass aligned? Look at policy_evaluated. A pass on either dkim or spf is enough.
3. If it fails, why? Compare auth_results with header_from. The commonest pattern is dkim passing but with the vendor's domain (for example <domain>sendgrid.net</domain>) rather than yours. That's a pass on DKIM but not an aligned one. The fix is to set up DKIM for your own domain inside that vendor.

Raw XML is readable for a small domain. Above a few senders, use a report processor, but learn to read one record by hand first so you can check what the processor tells you.

The usual blockers

Symptom in reports	Likely cause	Fix
A known vendor fails both SPF and DKIM alignment	Vendor signs with its own domain and uses its own bounce domain	Set up custom DKIM (and custom return-path, if offered) for your domain
SPF shows permerror	Record over 10 DNS lookups	See fixing too many SPF lookups
DKIM fails only for some messages from a known source	A mailing list or gateway modifying the message, or a footer added after signing	Sign after the last modification; check the gateway
Small volumes failing from many unrelated IPs, header_from is yours	Forwarding (SPF breaks) or spoofing	If DKIM passes, it's forwarding and will survive. If both fail from random IPs, it's spoofing
A subdomain fails that you forgot existed	Old system still sending	Fix or set sp=none while you do

When to stop at quarantine

reject is right for most domains, but not automatically. Stay at quarantine if a meaningful share of your legitimate mail is forwarded through systems that modify it and you cannot get DKIM to survive. Quarantined mail can still be found in a spam folder, while rejected mail is gone. BIMI accepts either quarantine or reject, so you don't need reject for the logo.

The practical takeaway

Publish p=none with a rua address today if you haven't, and read the reports until you can name every sending source. Then step through quarantine to reject, using t=y with pct=0 as the testing step so both old and new receivers behave the same way. Leave rua on permanently. The reports are how you'll find out when someone in marketing signs up for a new tool that sends as your domain.