Move DMARC From None to Reject Without Killing Legitimate Email

A DMARC record set to p=reject is the goal. It is the policy that tells the world's mail servers to throw away any message that claims to be from your domain but cannot prove it, which is what actually stops someone from spoofing your domain to phish your customers. But getting there carelessly is how a company accidentally blocks its own invoices, its own password resets, its own marketing, and discovers it three days later when the complaints come in.

To roll out DMARC to p=reject without blocking real mail, move through the policy levels in stages instead of jumping straight to enforcement. Start at p=none with reporting on to discover every service sending as your domain, fix each one until aggregate reports show them passing, advance to p=quarantine, then to p=reject only when the data confirms no legitimate sender still fails.

The reason this happens is that almost no domain has a complete, accurate inventory of everything that sends mail as it. The CRM, the help desk, the payroll system, the marketing platform, the one-off script someone wrote two years ago, all of them send mail that looks like it is from you, and some of them are not properly authenticated. Flip straight to p=reject and every one of those that fails authentication gets bounced. The whole art of a DMARC rollout is finding all those senders and fixing them before you enforce, and DMARC has a reporting mechanism built precisely so you can.

The staged path: none, then quarantine, then reject

You do not jump to enforcement. You move through three policy levels, watching the data at each step, and you only advance when the reports show it is safe.

The sequence:

1. p=none. Enforce nothing, but turn on reporting. Receivers send you aggregate reports of every source sending mail under your domain and whether it passed authentication. This is pure observation, no mail is affected, and it is where the actual work happens.
2. p=quarantine. Failing mail goes to spam rather than the inbox. Less severe than reject, so a mistake here sends a legitimate message to the spam folder instead of deleting it, which is recoverable.
3. p=reject. Failing mail is refused outright. This is the destination, and you only reach it once the reports confirm every legitimate sender passes and the only failures left are unauthorised.

The whole point of the staging is that each step is reversible and observable before the next. You are never guessing whether enforcement will break something, because the reports told you before you enforced.

Start at none and actually read the reports

Publishing p=none with a reporting address is the first move, and it should sit there for a few weeks while you build a complete picture. The record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s

The rua address is where aggregate reports go. These are XML files (most teams feed them into a DMARC reporting tool rather than reading raw XML) summarising, per source IP, how much mail was sent as your domain and whether SPF and DKIM passed and aligned. This is the inventory you never had. It surfaces every legitimate sender you forgot about and every forger pretending to be you, which is the whole craft of reading your DMARC reports to find who is spoofing your domain.

The work at this stage is methodical: for every sending source the reports reveal, map it to a system, an owner, and a business purpose, then confirm it authenticates correctly. The marketing platform needs its DKIM set up and aligned. The help desk needs to be in your SPF or signing with DKIM on your domain. The forgotten script needs to either be fixed or shut off. A clean rollout is also easier when transactional and marketing mail are separated, which is the case for splitting transactional and marketing mail across subdomains the right way. This is where a correct SPF, DKIM, and DMARC setup that actually passes gets earned sender by sender. You go down the list until every legitimate source passes DMARC, and the only failures remaining in the reports are sources you do not recognise, which are the spoofers you are about to block.

Do not rush this. The reports accumulate over time, and a sender that only fires monthly (a billing run, a quarterly newsletter) will not show up in your first week of data. Give it long enough to catch the infrequent senders before you tighten, or you will enforce against a legitimate sender you simply had not seen yet.

Tighten gradually, do not flip the switch

Once your senders are clean, you advance to p=quarantine, and here the historical advice and the current direction of the standard diverge slightly, so it is worth being precise about both.

The long-standing way to advance gradually was the pct tag, which applied your policy to only a percentage of failing mail. You would set p=quarantine; pct=25, so only a quarter of failing messages went to spam, watch for any legitimate mail caught in the net, then step up 25, 50, 75, 100, and repeat the same gradual climb when moving to p=reject. This let you catch a missed sender while affecting only a fraction of mail.

The important update: the pct tag is being removed in DMARCbis, the revision of the DMARC standard that has cleared IETF Last Call and is expected to publish as a Proposed Standard. The reason is that receivers implemented pct inconsistently, with most only honouring pct=0 and pct=100 and treating the in-between values unpredictably, so the gradual-percentage rollout never worked as reliably as the documentation implied. DMARCbis replaces it with a simpler binary t (testing) flag: t=y marks the policy as testing only, so receivers do not actually enforce it (equivalent to the old pct=0), and t=n means full enforcement (equivalent to pct=100).

The practical takeaway for a rollout today: do not lean on pct percentages as a precise dial, because they were never honoured precisely. The reliable gradual path is the policy levels themselves, none to quarantine to reject, each held long enough to read the reports, with t=y as a testing signal during the transition. The staging that actually protects you is moving through the policies while watching the data, not slicing a percentage that receivers may ignore.

Advance only when the data says it is safe

The criteria for each step up are about evidence, not a calendar:

• Move from none to quarantine once your main sending sources pass DMARC and your support team knows what changed, so they can recognise a quarantine complaint if one slips through.
• Move from quarantine to reject once the reports show the remaining failures are unauthorised, obsolete, or mail you intend to block. A common benchmark is a per-domain DMARC compliance rate above 98 percent before you reject, meaning all but a tiny fraction of your legitimate mail authenticates cleanly. This is the same patience that keeps a sender clean overall, the work behind getting out of the Gmail spam folder and staying out and meeting Google and Yahoo's bulk sender rules without getting throttled.

At reject, keep reading the reports. A new tool gets adopted, a vendor changes their sending infrastructure, and suddenly a legitimate source starts failing. The aggregate reports are how you catch that before it becomes a stream of bounced mail, so the monitoring does not end when you reach reject, it continues as long as you care about your domain not being spoofed.

Do not forget the subdomains

One gap that catches teams: your DMARC policy on the root domain does not automatically protect arbitrary subdomains the way you might assume, and attackers love spoofing subdomains. DMARCbis adds an np tag specifically for non-existent subdomains, letting you apply a strict policy to subdomains that should never send mail at all. Set that, because a subdomain you never send from is a clean target for a spoofer, and locking it down costs nothing.

The end state of all this is a domain that cannot be convincingly spoofed: a message claiming to be from you, sent by someone who is not you, gets refused by the receiving server before it reaches the target. That is real protection for your customers against phishing that wears your name, and it is worth the careful rollout to get there without collateral damage. Once you are at reject, you can build on it with a verified logo next to every email through BIMI, which requires a DMARC enforcement policy to be eligible.

This staged work, reading the reports, finding every sender, fixing alignment, advancing only on evidence, is exactly the kind of email deliverability work that is tedious to do well and expensive to do wrong. The difference between a clean rollout and a self-inflicted outage is entirely in the patience to read the data before enforcing. If your domain is sitting at p=none because moving forward feels risky, that risk is what the reports are for, and reading them is how you get safely to reject.