From p=none to p=reject: stage exit criteria for DMARC

The question behind most DMARC projects is not how to write the record, it is how long to stay at p=none and what has to be true before you move. Waiting forever leaves your domain open to spoofing, and moving too early sends your own invoices to spam. This guide gives you stage-by-stage exit criteria, a plan for subdomains, what usually breaks, and how to roll back. The thresholds are our advice, not part of any standard, and we label them that way.

The short answer#

Stay at p=none for at least one full sending cycle, usually two to four weeks, longer if you have monthly or quarterly mail such as statements. Move to quarantine when every legitimate source you know about passes DMARC through an aligned SPF or DKIM check. Move to reject after a further stretch at quarantine with no surprises. Do not plan the ramp around pct=: the current DMARC standard, RFC 9989, removes that tag. It was published in May 2026 and obsoletes RFC 7489, the original DMARC specification. The basics of the record itself are in the DMARC setup guide, which this post does not repeat.

The stages and when to leave each one#

Each stage below has an exit test. Every number in the table is a rule of thumb we suggest, because your volume and mix of senders decide what is realistic.

A stage is done when the unexplained failures are small and boring: a few messages from forwarders, mailing lists or sources you can identify as not yours. If a source with real volume is still unidentified, you are not done with stage 2. The playbook for identifying them is in the how to read DMARC reports guide.

An example calendar#

To make the table concrete, here is one plausible schedule for a company with an ESP, a CRM and a billing tool. It is an illustration, not a promise.

• Weeks 1 to 4: publish p=none, collect reports, and build a list of every source with its owner. Include the one that sends only at month end.
• Weeks 5 to 8: fix alignment source by source, starting with the largest by volume. Recheck the reports after each change, not at the end.
• Week 9: enforce on parked and non-sending domains.
• Weeks 10 to 13: move the main domain to quarantine and watch for new failing sources every week.
• Week 14 onward: move to reject if the last month was quiet, and add a standing rule that new senders are authenticated before launch.

If a source is slow to fix, the calendar waits for it. The date is a plan, the exit test is the rule.

What to do about pct#

If you have seen older advice such as pct=10, then 25, 50, 100, that was a way to apply a stricter policy to a share of failing mail. RFC 9989 removes the tag. Its own rationale says that the tag was usually not applied accurately unless the value was 0 or 100. It adds a t tag in its place, with y for "testing" and n (the default) for normal handling.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"

With t=y, a receiver that supports it should treat a failing message one level softer than the policy says: quarantine becomes none, reject becomes quarantine. It has no effect on p=none. Two honest cautions. First, support for the new tag will take time to spread, so do not depend on it to protect you. Second, a percentage ramp was never a reliable safety net even before the change.

A safer way to limit risk is to stage by scope instead of by percentage: enforce on subdomains and non-sending domains first, then the main domain, and dwell at quarantine for a few weeks before reject. If your current record still contains pct=, you do not need to rush to remove it, but do not add a new ramp that relies on it.

Subdomains and domains that send nothing#

The quickest win comes from domains that never send mail. Parked domains and retired brands are favorite spoofing targets, and they have no legitimate sources to break. Publish an enforcing policy right away, plus an SPF record that authorizes nothing:

parked.example.com.         TXT  "v=spf1 -all"
_dmarc.parked.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
parked.example.com._report._dmarc.example.com.  TXT  "v=DMARC1;"

The third line is the authorisation record. Because the rua= address is in a different domain from the one the policy protects, receivers only send reports if that other domain publishes a TXT record named <protected-domain>._report._dmarc.<report-domain>. Skip it, or put the rua= address on the parked domain itself, and the reports for that domain never arrive. The reports not received guide covers the check.

For subdomains of a domain that does send, the parent policy applies unless the subdomain publishes its own record. The sp= tag sets a different policy for subdomains that have none. RFC 9989 also defines an np tag for subdomains that do not exist in DNS, which is useful against made-up hostnames. If you plan to set sp=reject on the parent, confirm first that each sending subdomain passes, or give it its own record. The sending subdomain guide explains why each mail stream is better on its own subdomain in the first place.

What usually breaks when you enforce#

Almost every enforcement incident traces back to one of these. Look for them in stages 1 and 2, not after the policy change.

• The sender nobody remembered. A billing tool, a survey platform or a recruiting system that sends once a month. A full cycle of reports catches most of these, which is why stage 1 is not skippable.
• Aligned in the test, not in production. A service passes from one sending IP pool and fails from another. Judge each source by its real volume over time.
• Forwarders and mailing lists. Forwarding breaks SPF, and lists that edit a message break DKIM. You cannot fully prevent this. Expect a small residual failure rate and decide in advance that it is acceptable. RFC 9989 is explicit about it: a domain that publishes p=reject must not rely on SPF alone and must DKIM-sign its mail, and a domain whose users post to mailing lists should not publish p=reject at all. For that kind of domain it suggests at least a month at p=none, then an equally long period at p=quarantine, before comparing results. Our shorter windows above suit domains that send mostly system mail, so lengthen them if your staff post to public lists.
• A new tool added after you enforce. The marketing team signs up for a platform on a Tuesday and its mail starts bouncing. This is a process problem: agree that new senders get authentication set up before first use.
• Strict alignment left on. adkim=s or aspf=s turn a working relaxed setup into failures. The alignment troubleshooting guide walks through each cause.

Watching the move with real numbers#

During stages 2 to 4 you want one view: for each source, what share of its mail passes DMARC, and which sources are new this week. Qualisend DMARC reports shows that per domain, over 7, 30 or 90 days, and emails you the day after a domain has at least 10 messages failing both SPF and DKIM, or a new source with at least 5 failing messages. It has no "ready for reject" score, so the judgment is yours: watch each legitimate source reach 100% and stay there. Aggregate data also lags by a day or two and covers only the receivers that send reports, so a quiet week is not proof that nothing failed.

Qualisend's domain health monitoring lists p=none as a warning in a domain's issues, and warns on pct below 100, which helps if you manage several domains and want to see which have not moved yet.

Rollback#

Plan the way back before you move. Three habits make a rollback quick.

1. Keep the previous record text in your change notes, so reverting is copy and paste.
2. Lower the TTL on the _dmarc record to a few minutes a day or so before a policy change, then raise it again once things are stable. Receivers cache DNS, and a long TTL slows your own rollback.
3. Move one step back, not all the way. If a legitimate source starts failing at reject, return to quarantine while you fix it. Messages already rejected during that window are usually bounced to the sender and are not recoverable from the receiving side, so it is better to make the first enforcement window short and watched.

Where enforcement connects to everything else#

Reaching quarantine or reject on the organizational domain is also the precondition for BIMI logos, and the BIMI guide lists what the standard asks for. It does not remove the need for the other basics in the Google and Yahoo requirements. The full picture of how authentication fits with reputation is in the deliverability guide.

An enforced DMARC policy proves the mail is yours, but it cannot make a bad list good. The free plan on the pricing page includes 100 credits that run the full verification on a list. A protected domain still needs a healthy list to earn the inbox.