Part 1 of a five-part email deliverability playbook.

Your DMARC record says p=none. Technically, you have DMARC. Practically, you have a security camera that records burglaries and stops none of them.

That’s not a dig. p=none is exactly where you’re supposed to start. The problem is that most domains never leave. The record gets added during some compliance scramble, everyone moves on, and three years later it’s still sitting there enforcing nothing while the domain stays spoofable.

Here’s the path out. It’s not complicated, but the order matters.

Why you can’t just flip it to reject

Tempting, I know. One-line change. Done by lunch.

The catch: DMARC enforcement applies to everything that sends as your domain, not just the senders you remember. The marketing platform, sure. But also the billing system, the survey tool someone in CS set up in 2022, the CRM that sends quotes, the ticketing system. If any of those isn’t passing SPF or DKIM in alignment with your domain, the moment you enforce, their mail starts going to spam or vanishing.

And you won’t hear about it from the tool. You’ll hear about it from a customer asking why they never got their invoice.

So the whole game is: find every legitimate sender before you tighten the policy. DMARC gives you the instrument for that. You just have to actually use it.

Step 1: Turn on the reports

Add a rua tag to your DMARC record so receivers send you aggregate reports:

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

These reports are XML files that show every server sending mail as your domain and whether it passed authentication. Raw, they’re miserable to read, so use a free report processor (Postmark’s DMARC tool, or any of the freemium dashboards) unless you enjoy XML the way some people enjoy crosswords.

Step 2: Wait, and actually read them

Give it two to four weeks. You’re building an inventory: every source that shows up in the reports, sorted into three buckets.

  1. Legit and passing. Great. No action.
  2. Legit but failing. This is the bucket that matters. Usually it’s a real service that was never set up properly: missing SPF include, DKIM not enabled, or DKIM signing with the vendor’s domain instead of yours (which fails alignment even though it “has DKIM”). Fix these one by one.
  3. Not yours. Spoofers and spammers. This is who enforcement is for. No fix needed. They lose when you tighten the policy.

If a sender in bucket 2 surprises you (“wait, what is sending as us?”), that’s the system working. Better to find out now than after reject.

Step 3: Quarantine, partially

Once bucket 2 is empty (or you’ve consciously decided what’s left doesn’t matter), move to quarantine. But ease in:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

pct=25 applies the policy to a quarter of failing mail. If you missed a legitimate sender, you find out from a trickle of complaints instead of a flood. Watch the reports for another week or two, then ramp: 50, 100.

Step 4: Reject, eventually

p=quarantine at 100% is genuinely fine to live at for a while. Failing mail goes to spam, which is recoverable. p=reject is the endgame: failing mail is refused outright. Move there once your reports have been boring for a month. Boring is the goal.

The short version

Reports on, read them for a few weeks, fix every legitimate sender that’s failing, quarantine at 25%, ramp to 100, reject when the reports get boring. Each step is small. The only real failure mode is skipping the reading part.

That middle part, figuring out which mystery senders are legitimate and untangling their alignment, is where this gets genuinely fiddly. Especially with more than a couple of sending services in the mix. But the path itself is simple, and skipping the reading is the only way to get it wrong.