How to get DMARC to p=reject without breaking email

The short version: get to p=reject one rung at a time — p=none, then p=quarantine, then p=reject — and move to the next rung only when your DMARC aggregate reports prove every legitimate sender is aligned. Since RFC 9989, that evidence is the only gentle way to do it. The old advice, ramping a percentage from 25% to 100%, no longer works the way most guides describe.

This guide explains why the percentage ramp stopped working, what evidence unlocks each rung, and why no single DNS scan — ours included — will ever tell you to publish p=reject.

Why the pct ramp stopped working

For a decade the standard advice was to publish p=quarantine with pct=25, then raise pct to 50 and 100, then do the same with p=reject. The pct tag asked receivers to apply your policy to only a share of failing mail, so a mistake would hurt a fraction of your messages instead of all of them. Even then it was a request, not a guarantee: the RFC's own reason for dropping it is that receivers never applied values other than 0 and 100 consistently.

RFC 9989 (DMARCbis, May 2026) removed pct (the registry now marks it historic). A receiver that follows the new standard treats it as an unknown tag, ignores it, and applies your policy to all mail. So p=quarantine; pct=25 is gentle at older receivers and fully enforcing at newer ones, and you cannot tell which one handles a given message. No record shape is partly enforcing at both generations of receiver. (The new t=y testing flag has the same problem in reverse: newer receivers step your policy down one level, older ones ignore the flag. See DMARCbis (RFC 9989) for the details.)

The caution now has to come from evidence instead of a partial policy: you publish each rung in full, and you move up only once the reports show nothing legitimate would be caught.

The three-rung ladder

There are three rungs and no in-between steps:

1. p=none — monitor only. Receivers deliver everything and send you aggregate reports. This is where every rollout starts, and it is useless unless the record carries a rua= address to receive those reports.
2. p=quarantine — mail that fails DMARC goes to spam.
3. p=reject — mail that fails DMARC is refused outright. This is the rung that actually stops spoofing of your domain.

The records differ only in the policy tag. For example, with reports going to dmarc@example.com:

v=DMARC1; p=none; rua=mailto:dmarc@example.com
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Keep the rua= address at every rung. Reports are what tell you the next rung is safe, and they are what tell you something broke after you moved.

Records DNS Doctor writes also carry np=reject, RFC 9989's policy for subdomains that do not exist. No real mail comes from a name that does not exist, so it is safe at every rung.

What evidence unlocks each rung

"Ready" is a calculation over your aggregate reports, not a feeling. This is the check DNS Doctor's readiness engine runs over a trailing 30-day window of reports before it will write the next record:

• Every sending source you recognise is at least 99% aligned. A known source is a mail provider we recognise or a sender you have marked as yours. If your newsletter tool is aligned for only 80% of its mail, the other 20% would go to spam or be rejected at the next rung. That source blocks the step until you fix its SPF or DKIM, and the check names it.
• Unaligned mail from unknown sources is under 0.5% of the total. Unknown mail that is aligned passes at any policy, so it never blocks you. Only the unaligned share is a risk: it could be a legitimate sender nobody told you about. Sources you have marked as "not mine" are left out of the calculation entirely.
• The window is not empty. Zero messages means no evidence, not a perfect score. A domain with no reports is never ready.
• The published record can be advanced. A record that sets t=y, or whose subdomain policy sp= is weaker than p=, is not advanced, and neither is a record that does not parse cleanly: fix the bad tag first. With t=y, receivers step down from the stated policy, so the next rung would not mean what it says.

Moving from p=none to p=quarantine needs those four things, counted from authenticated reports only. Moving to p=reject needs one thing more: at least three separate days of those authenticated reports. The address in your rua= tag is public, so anyone can send a report to it. A forged report claiming that all your mail is aligned must never be what unlocks a policy that turns mail away. So every rung counts only reports we can authenticate as coming from a major receiver or an established report sender (plus reports you upload yourself). The last rung goes one step further: it waits until those authenticated reports cover at least three separate days rather than taking one report's word for it.

Once you are at p=reject, unknown unaligned mail stops counting as a blocker: that is the policy working, and the dashboard shows it as mail being turned away.

Why one DNS scan never derives p=reject

A DNS scan reads your records. It can tell you whether your DMARC record parses, whether SPF stays under its 10-lookup limit, and whether DKIM is published. What it cannot see is your mail: which services actually send as your domain, and whether each one aligns. That only shows up in aggregate reports, collected over time.

So a scan in DNS Doctor recommends at most p=quarantine, and only when it has a signal that your mail aligns. p=reject cannot come from a scan at all. It comes only from the report-based readiness check described above. A scan also never suggests a weaker policy than the one you have published: if your record says p=reject but has a syntax problem, the repair stays at p=reject.

The reporting-first answer

When a scan finds a domain at p=none (or with no DMARC at all) and has no alignment evidence, it does not guess. It gives you no enforcing record. Instead it explains what would unlock the next rung and points you to where that evidence is read: publish a rua= address, let reports arrive, and check readiness against them. That can look like a non-answer, but it is the honest one. A wrong DMARC record still parses and still gets published, and its only symptom is real mail quietly going to spam or being refused.

Doing it yourself, or having it done

To walk the ladder yourself, start with a free scan of your domain and the DMARC record checker to see which rung you are on and whether your record is sound, then collect aggregate reports before each move: our check needs a non-empty window of authenticated reports for quarantine and three separate days of them for reject. If you would rather have it done, the one-time Get to p=reject package takes one domain from monitor-only to reject over up to 90 days. It unlocks each rung only when your reports prove it is safe, gives you each record to paste yourself (we never touch your DNS), and ends with a plain statement of what was proven. A trial shows you when your domain is ready for p=reject; the p=reject record itself ships with the package or Monitor.