From p=none to p=reject: a staged DMARC rollout
A step-by-step plan for taking a client domain from DMARC p=none to p=reject, with exit criteria for each stage and what RFC 9989 changed about pct.
By Doug Hall · Updated
- Start at p=none with reports, find every real sender, and fix each one before you tighten anything.
- Move to quarantine, then reject, only when each stage's exit criteria are met. Six weeks is typical for a small business; complex domains take longer.
- RFC 9989 (May 2026) removed pct. Its replacement, t=y, asks receivers to apply one level below the published policy while you test.
Why stage it at all
A DMARC policy of p=reject tells receiving mail servers to refuse email that claims to come from the domain but fails authentication. That's exactly what you want for a forged invoice. It's also exactly what happens to the client's genuine newsletter if nobody set up DKIM for it. Jumping straight to reject swaps a spoofing problem for a delivery problem, usually discovered by the client on a Monday morning.
Staging the move means each step is reversible and each has a clear test before the next. If you haven't yet met DMARC's policies and tags, start with what DMARC is and how it works, then come back.
What RFC 9989 changed: pct out, t= in
DMARC was republished as a standards-track RFC in May 2026. RFC 9989 covers the protocol and RFC 9990 the aggregate reports. Together they obsolete RFC 7489. The record still starts v=DMARC1, and most existing records keep working. Two changes matter for a staged rollout.
pct has gone. Under RFC 7489, pct=25 asked receivers to apply the policy to a quarter of failing mail. Appendix A.6 explains that in practice pct "was usually not accurately applied, unless the value specified was either 0 or 100". The tag is now listed as historic, "not expected to be in use in any current implementation". So a record reading p=quarantine; pct=25 may be treated by a newer receiver as plain quarantine, for all failing mail.
t= replaces the useful part. The new test mode tag takes y or n (the default). With t=y, the domain owner expects failing mail to get one level below the published policy: p=quarantine; t=y behaves like none, and p=reject; t=y behaves like quarantine. RFC 9989 describes t=y and t=n as the equivalents of the old pct=0 and pct=100. It doesn't change reporting.
Receivers won't all move at once. During the changeover you can publish both forms, because each version of the standard ignores tags it doesn't know:
v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc@example.com
Two other additions are worth knowing: np= sets a policy for subdomains that don't exist, and receivers now find the organisational domain by walking up the DNS rather than consulting the Public Suffix List. Neither changes the plan below.
The plan at a glance
These timings suit a typical small business with a handful of senders. Treat the exit criteria as the real gate, not the calendar: a domain only moves on when it passes them.
| Stage | Record | Typical length | Move on when |
|---|---|---|---|
| 1. Monitor | p=none with rua | Weeks 0 to 2 | Reports from the big providers arriving daily; every source named |
| 2. Fix | Still p=none | Weeks 1 to 4 | Every known source passing DMARC, aligned, for 14 days |
| 3. Quarantine | p=quarantine (t=y first if nervous) | Weeks 4 to 6 | No genuine mail failing for 14 days; nobody reporting missing mail |
| 4. Reject | p=reject | Week 6 onwards | Ongoing: watch for new senders |
Stage 1: monitor at p=none
Publish a record that changes nothing for delivery but asks for daily aggregate reports. RFC 9989 section 5.1.4 calls this monitoring mode and recommends starting here.
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The DMARC record generator will write it for you. If the client already has a record, check it with the DMARC checker first: two records, or a rua address at another company's domain without its authorisation record, and you'll get no reports at all.
Exit criteria: reports arriving every day from Google, Microsoft and Yahoo, and every sending source in them named, either as a service the client uses or as something nobody recognises.
Stage 2: fix every real sender
Read the reports and make a list. A typical small business has the mailbox provider (Microsoft 365 or Google Workspace), a newsletter tool, an accounting package that emails invoices, the website's contact form and perhaps a CRM or booking system. Our guide to reading a DMARC report explains which rows matter, or paste one into the DMARC report analyser.
For each genuine source, in this order:
- DKIM with the client's own domain. Most services offer it; it survives forwarding, and RFC 9989 says domains at reject must use it rather than rely on SPF alone.
- SPF with an aligned return path, where the service supports a custom bounce domain. Watch the 10-lookup limit as includes pile up.
- Move bulk mail to a subdomain such as
news.example.comif a tool can't align with the main domain. It keeps the main domain's reputation separate, too.
Wait for a full monthly cycle before you call the list complete. Payroll, quarterly VAT reminders and annual renewals only appear when they send.
Exit criteria: every known source passing DMARC with alignment for at least 14 days. What still fails should be unknown sources: spoofing, or forwarding you can't control.
Stage 3: quarantine
If you're confident, publish p=quarantine. If not, spend a week at p=quarantine; t=y; pct=0 first. Failing mail is still treated as if the policy were none, but some intermediaries, such as mailing lists, start rewriting the From address. Comparing the reports before and after shows how much of the client's mail passes through them. That's the use RFC 9989 kept when it dropped pct.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Tell the client what to look out for: a supplier saying "your emails have started going to junk" is the signal you missed a sender.
Exit criteria: 14 days with no genuine mail failing in the reports, and nobody reporting missing or junked mail.
Stage 4: reject
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Keep the rua address. Reject isn't the end of the job: new tools arrive, a marketing hire signs up for something, a provider changes its sending set-up. Watch the reports weekly at least, or have something watch them for you.
Read section 7.4 of RFC 9989 before this step. It says domains whose users post to internet mailing lists should not publish reject, and suggests at least a month at none and an equally long period at quarantine before trying. For a typical small business that never posts to lists, it's rarely an issue; for a membership body or a university department, it is.
Subdomains and parked domains
Subdomains inherit p= unless sp= says otherwise, and subdomains that don't exist follow np= if it's set. If a newsletter tool on news.example.com needs longer, give it its own record at that name rather than holding the main domain back.
Domains that never send email skip the plan entirely: they can go to p=reject today. See protecting parked domains.
When something breaks after reject
- Find the source in the reports: the sending IP, its organisation, and whether SPF or DKIM failed.
- If it's genuine and urgent, drop back to
p=quarantine(orp=reject; t=y) while you fix it. DNS changes take effect as the old record expires from caches, so keep the TTL short during the rollout. - Set up DKIM for that service, check it with a test message, then restore reject.
The email test is the quickest way to check one sender: send a message and see whether SPF and DKIM pass and line up with the From address.
Explaining each step to the client
| Stage | What to tell them |
|---|---|
| Monitor | We've asked the big email providers to send us a daily summary of every email using your domain. Nothing changes yet. |
| Fix | We found four services sending as you. We're setting each one up properly so they're recognised as genuine. |
| Quarantine | Email pretending to be you now goes to spam. Tell us at once if a customer says your mail is in junk. |
| Reject | Email pretending to be you is now refused outright. We'll keep watching for new services. |
If you'd rather not edit the client's DNS for every step, hosted DMARC lets you change the policy from a dashboard once the record points at us. And when you compare tools for this, our comparison pages set out how the main DMARC services differ.
Doing this for clients? Domain Health Hub checks every client domain each day and puts the results in a monthly report card with your logo. Start a free trial; no card needed.
Questions
Is it safe to keep pct in the record?
It does no harm to receivers that ignore it, but don't rely on it. RFC 9989 marks pct as historic, and values other than 0 and 100 were never applied consistently. For a cautious step use t=y instead.
How long should a domain stay at p=none?
Until every real sender passes, and for at least one full monthly cycle so invoicing and payroll mail shows up. For most small businesses that's two to four weeks; for a domain with many senders it can be months.
Do we need DKIM if SPF already passes?
Yes, for anything you care about. Forwarding breaks SPF but usually leaves DKIM intact, and RFC 9989 says domains publishing p=reject must sign with DKIM rather than rely on SPF alone.
Should staff who post to mailing lists stop us going to reject?
It's a real trade-off. RFC 9989 advises that domains whose users post to internet mailing lists should not publish p=reject. Many small businesses don't use lists at all; ask before you assume.
Watch every client's domains, every day.
Reports read for you, and a monthly report card your clients will understand.