DMARC enforcement: the staged road from p=none to p=reject

Q: What happened to the pct tag?

RFC 7489 used pct to sample enforcement: p=quarantine; pct=25 applied quarantine to a quarter of failing mail. RFC 9989, published in May 2026, removed it in favor of t=y, which tells receivers to apply the next lower policy while you test. Receivers of both generations are in service, so a transition-era record can carry both tags.

Q: How do I roll back a DMARC policy change?

Edit the DNS record to the previous policy, or add t=y; receivers honor the change as the record's TTL expires. Keep the prior value saved and the TTL short during migration, fix the source the reports identified, and re-attempt the stage. Enforcement is a destination you earn with evidence, not a setting you flip on a good day. Collect until the reports are boring, rehearse in testing mode, keep the retreat path warm, and let the DMARC report analyzer referee every stage.

2026-10-09

No mailbox provider will ever email you to say your DMARC policy has been sitting in monitoring mode for three years. p=none satisfies the letter of the bulk-sender requirements, collects reports, and blocks nothing: a spoofer's mail is evaluated, fails, and is delivered anyway, with a note in a report nobody may be reading. Enforcement, p=quarantine and ultimately p=reject, is where DMARC starts protecting anyone. It is also where a careless step destroys your own legitimate mail, which is why the migration is staged. This guide is the staging plan: what to verify at each gate, how to ramp in testing mode, and how to retreat if a stage goes wrong.

The prerequisite reading, if the policy levels themselves are new to you, is DMARC policy, and setup from zero is covered in how to set up DMARC. This guide assumes a published record and takes you from there to reject.

Why none-forever is a real cost

At p=none, DMARC is a sensor. Anyone can send as your domain and reach inboxes wherever local filtering lets it through, your customers and partners bear the phishing risk, and the mailbox providers can see that your domain never asserts protection. The requirements at Gmail and Yahoo accept p=none as the minimum today, which makes it a compliance floor rather than a protection level. The sensor phase is essential; living in it permanently means running the costs of DMARC while declining its benefit.

Stage one: monitor until the evidence is boring

Set rua= reporting and collect aggregate reports across your full sending calendar, several weeks at minimum, long enough to catch the monthly invoicing job and the quarterly board mailing. Parse them with the DMARC report analyzer and work the loop described in how to read DMARC reports: identify every source sending as your domain, finish SPF includes and DKIM signing for each legitimate one, and verify alignment, not just raw passes, with the email authentication checker. Special attention to the sources that break silently: forwarding flows, the office suite, and any SMTP relay devices nobody documented. The exit criterion is simple and strict: multiple consecutive weeks in which every legitimate source passes aligned authentication, and the only failures left are traffic you do not recognize as yours. If that never converges, the blocker is an unauthenticated sender, and DMARC fail is the debugging guide.

Stage two: quarantine, rehearsed in testing mode first

p=quarantine asks receivers to treat failing mail with suspicion, in practice the spam folder. The throttle for this stage changed in May 2026. RFC 7489 offered the pct tag, which applies the policy to a sampled percentage of failing mail and handles the remainder one level down. RFC 9989, the standard that replaced it, removed pct and substituted the t tag: t=y declares that you are testing, and receivers apply the next policy level down, so p=quarantine; t=y behaves like none and p=reject; t=y like quarantine. Receivers adopt a new standard gradually, so a transition-era record can carry both signals, with legacy receivers reading the percentage and updated receivers honoring the testing flag. A conventional sequence:

v=DMARC1; p=quarantine; pct=5; t=y → pct=25; t=y → pct=50; t=y → p=quarantine with both tags removed, holding each step for a week or two.

The last arrow is the one to respect: updated receivers move straight from monitoring to full quarantine there, which is why the report evidence from the earlier steps has to be clean before you take it. At every step, the reports are your instrument panel: watch the disposition field for quarantined mail from sources you recognize, and treat any hit on a legitimate source as a stop signal, not a statistic. Two honesty notes belong here. First, legacy receivers never implemented pct sampling uniformly, so treat the ramp as risk reduction rather than a guarantee. Second, quarantined legitimate mail is recoverable from spam folders, which is exactly why quarantine precedes reject in the sequence. Users reporting missing mail during this stage are your cheapest possible warning; the triage in check if emails go to spam separates policy casualties from ordinary filtering.

Stage three: reject

p=reject instructs receivers to refuse failing mail during the SMTP conversation; the sender gets a bounce-back and the mail never reaches a folder. Move here after quarantine at pct=100 has run clean for weeks. The same rehearsal works here if you want it (p=reject; pct=25; t=y, where updated receivers hold at quarantine while legacy receivers sample reject), though by this point the failing population should be entirely traffic you are happy to see refused. At reject, spoofing your exact domain stops working against every enforcing receiver, which is the point of the entire exercise.

Two loose ends complete the job. Subdomains: the sp= tag sets their policy, and without it they inherit the root's (RFC 9989 keeps that rule and adds np= for subdomains that do not exist in DNS); an enforcement record that leaves sp=none in place keeps a spoofable side door open, while enforcing sp= before your sending subdomains authenticate breaks them. Audit the tree with the DMARC checker. Reporting: keep rua= forever, because enforcement without monitoring is how the next unauthenticated vendor launch goes unnoticed until the bounces arrive.

Rollback, planned in advance

DMARC lives in DNS, so retreat is one TXT edit: drop reject to quarantine, add t=y, or cut pct back for legacy receivers, and receivers pick up the change as your record's TTL expires. Decide before each stage what evidence triggers a rollback (any quarantined or rejected mail from a source you own is the usual line), keep the previous record value saved, and prefer a short TTL on the record during the migration so mistakes are cheap. A rollback means the process caught a problem while it was cheap, and the fix is almost always one more source authenticated per the forensic or aggregate evidence, then the same stage re-attempted.

Timeline expectations, as a practitioner rule of thumb rather than a documented figure: small domains with one or two sending services commonly complete the whole road in six to ten weeks, while organizations with many vendors spend most of a quarter in stage one alone, and that is the stage worth the patience. A source discovered at p=none costs a line in a report; the same source discovered at p=reject costs bounced legitimate mail.

Related guides

DMARC policy — what none, quarantine and reject each instruct receivers to do
How to read DMARC reports — the evidence loop every stage of this migration runs on
DMARC report analyzer — parse the reports that gate each stage
DMARC fail — debugging the failures that block convergence
DMARC checker — verify the policy, pct and sp the world currently sees
DMARC forensic reports — the per-message failure evidence, where available

About this guide

Written by InboxRatio Editorial. Policy semantics, the t testing tag, and sp=/np= subdomain inheritance follow RFC 9989 (May 2026); the legacy pct mechanism follows RFC 7489, which RFC 9989 replaced; provider expectations follow Google's and Yahoo's published sender requirements. Stage durations and rollback triggers are operational convention, labeled as such, not specification. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on specification and provider documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

9 October 2026. RFC references and provider requirements reviewed quarterly.

Frequently asked questions

What is DMARC enforcement? A DMARC policy that instructs receivers to act on authentication failure: p=quarantine (treat as suspicious, typically spam-folder) or p=reject (refuse delivery). p=none observes and reports but permits everything.

How long should I stay at p=none? Until your aggregate reports show every legitimate source passing aligned SPF or DKIM across your full sending calendar, sustained for several consecutive weeks. Calendar coverage matters more than a fixed duration; monthly jobs are the classic late surprise.

What happened to the pct tag? RFC 7489 used pct to sample enforcement: p=quarantine; pct=25 applied quarantine to a quarter of failing mail. RFC 9989, published in May 2026, removed it in favor of t=y, which tells receivers to apply the next lower policy while you test. Receivers of both generations are in service, so a transition-era record can carry both tags.

What is the difference between quarantine and reject? Quarantine delivers failing mail into suspicion, usually the spam folder, where a false positive can still be found and recovered. Reject refuses it during delivery, producing a bounce at the sender. Quarantine is the rehearsal; reject is the protection.

Can DMARC reject block my own legitimate email? Yes, that is the migration's central risk: any source of yours that fails aligned authentication, a forgotten vendor, an unfinished DKIM setup, will have its mail refused. The staged ramp with report monitoring exists precisely to find those sources while the cost is a spam folder, not a bounce.

How do I roll back a DMARC policy change? Edit the DNS record to the previous policy, or add t=y; receivers honor the change as the record's TTL expires. Keep the prior value saved and the TTL short during migration, fix the source the reports identified, and re-attempt the stage.

Enforcement is a destination you earn with evidence, not a setting you flip on a good day. Collect until the reports are boring, rehearse in testing mode, keep the retreat path warm, and let the DMARC report analyzer referee every stage.