🛡️

DMARC from p=none to p=reject, without breaking real mail

The safe path from a do-nothing DMARC record to full enforcement. Read the reports first, fix every legitimate sender, and ratchet the policy in stages instead of one risky jump.

A DMARC record at p=none does exactly one useful thing: it sends you reports. It blocks nothing. It protects nothing. Plenty of domains have sat at p=none for years, collecting reports nobody reads, under the comfortable illusion that "we have DMARC." It's the email-security equivalent of a smoke detector with the battery taken out.

Enforcement is the point. p=quarantine and p=reject are what actually stop someone spoofing your domain. Getting there without bouncing your own newsletters, invoices, and helpdesk mail is the whole skill. Here's the staged way to do it.

Why not just publish p=reject today?

Because you almost certainly have legitimate senders you've forgotten about. The marketing platform. The CRM. The accounting tool that mails invoices. The scanner on the office printer that emails PDFs to reception. Some of them send as your domain and some of them are not yet aligned under SPF or DKIM, and several you will meet for the first time in the reports, like distant relatives at a funeral.

Publish p=reject before you've found them, and DMARC does its job perfectly: it rejects them. Your invoices stop arriving. The first you hear of it is an angry phone call about an invoice that never arrived, and now you're debugging in production with the policy live and the finance team watching.

p=reject is not the goal you rush to. It's the reward for having already found and fixed every legitimate sender. The reports are how you find them.

Stage one: publish p=none and actually read the reports

Start at p=none with a reporting address.

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The rua= address is the important part. Within a day or two, the big mailbox providers start sending you daily aggregate reports: XML files listing every source that sent mail as your domain, and whether each one passed SPF and DKIM with alignment.

These reports are XML, not built for human eyes. Paste them into the DMARC report viewer and you get a readable table instead. What you're looking for is a complete inventory of your senders. Give it two or three weeks so the quieter monthly senders show up.

Stage two: fix every legitimate sender

Now the work. For each legitimate source in the reports, you want it passing DMARC through an aligned, authenticated identifier. DMARC needs only one of the two to line up:

  • SPF, with the envelope sender's domain aligned to your From: domain, or
  • DKIM, with the signing domain aligned to your From: domain.

In practice DKIM is the one to lean on, because it survives forwarding and doesn't care about the envelope path. Most senders (Microsoft 365, Google Workspace, the big ESPs) let you set up DKIM signing on your own domain. Do that, confirm it with the DMARC checker, and watch that source flip to pass in the next batch of reports.

The trap here is the long tail. The printer. The one-off script on a server in the corner. These are exactly the sources you'll want to either route through an authenticated relay or deliberately decide to let fail. Which is fine, as long as it's a decision and not a surprise.

Stage three: ratchet to quarantine

When the reports show your real senders consistently passing, move to quarantine. Quarantine is the safety net: a failing message goes to spam rather than being refused outright, so a sender you missed lands in junk instead of vanishing.

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Live here for a couple of weeks and keep reading the reports. Anything still failing now is either a sender you missed or an actual spoofer. Both are things you want to see before the next step.

A word on pct. The old RFC 7489 let you apply a policy to a percentage of mail, like p=quarantine; pct=25, as a throttle. Be careful relying on it: DMARCbis (the 2026 standard, RFC 9989) removes pct entirely. Most receivers still honour it today, but it's on the way out, so don't build a rollout that depends on it. Using quarantine itself as the intermediate stage is the more durable approach.

Stage four: p=reject

Once quarantine has been quiet (your senders passing, only spoofers and forgotten sources failing) move to reject. Now a forged message is refused at the door, which is the protection you wanted all along.

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Don't drop the rua= address when you reach reject. The reports are just as useful afterwards: they're how you spot a new sender being added by some team six months from now, before it starts failing silently.

What about subdomains?

The sp tag sets the policy for subdomains, and the gotcha is that subdomains inherit your p value unless you say otherwise. If marketing.yourdomain.com sends through a platform you haven't aligned, your shiny new p=reject will reject it too.

While you're still onboarding senders, an explicit sp=none lets you enforce the apex without breaking a subdomain you haven't finished with. Tighten it to match once that subdomain's senders are clean.

Real scenarios

Take a small business on Microsoft 365 with one marketing tool. The reports show two sources: Microsoft (already passing on DKIM) and the marketing platform (failing, no DKIM set up). You enable DKIM on the platform, wait for it to pass, then walk none to quarantine to reject over about a month. Straightforward.

Now take a company that has drifted for years. The reports surface eleven sources, four of which nobody can identify. This is the common case, and it's why you don't skip stage two. Each mystery source is a decision: authenticate it, relay it, or let it fail on purpose. Reject only goes live once all eleven are accounted for.

Our take

DMARC enforcement is not hard. It's just patient. The mistake is treating p=reject as a setting to switch on, rather than the last step of an inventory you've already completed. The reports do the hard part for you, but only if you read them.

What to do

  1. Publish p=none with a rua= address and let reports accumulate for two to three weeks. Read them in the DMARC report viewer.
  2. For every legitimate sender, set up aligned DKIM (preferably) or SPF, and confirm each one flips to pass with the DMARC checker.
  3. Move to p=quarantine, set sp=none if you're still onboarding subdomain senders, and watch another fortnight of reports.
  4. Move to p=reject only when the failures are all spoofers or known dead sources. Keep the rua= address forever.
← Back to all articles