DMARC rollout: from p=none to p=reject without breaking mail flow

DMARC tells receiving servers what to do when an email fails SPF and DKIM checks. Done right, it stops spoofing of your domain. Done hastily, it can block your own legitimate mail. Here's the safe path.

Where the record lives

DMARC is a TXT record at the _dmarc host of your domain — for example, _dmarc.example.com. A finished record looks like this:

The three policies

• p=none — monitor only. Receivers take no action on failures, but (if you've set rua) they send you aggregate reports. Always start here.
• p=quarantine — failing mail is treated suspiciously, typically sent to spam.
• p=reject — failing mail is rejected outright. Maximum protection, and the goal for most domains.

Alignment: the part people skip

DMARC doesn't just ask "did SPF or DKIM pass?" — it asks "did it pass for my domain?" That's alignment. aspf and adkim control how strict the match must be: r (relaxed, the default) allows organizational-domain matches, while s (strict) requires an exact domain match. Start relaxed; tighten only if you have a reason.

The safe rollout sequence

1. Publish p=none with rua. Add an aggregate report inbox (e.g. rua=mailto:dmarc@yourdomain.com) so receivers tell you who's sending as you.
2. Watch the reports for 1–2 weeks. Identify every legitimate sender — your Google Workspace, Instantly, CRM, invoicing tool — and make sure each passes SPF or DKIM with proper alignment.
3. Move to p=quarantine, optionally with pct=50 first. The pct tag applies the policy to only a percentage of failing mail, letting you ramp up gradually.
4. Go to p=reject; pct=100. Once reports show no legitimate failures, enforce fully.

Jumping straight to p=reject on day one is the most common DMARC mistake — one forgotten sending service and its mail starts bouncing.

Check your own record

Paste your DMARC value into the free DMARC audit tool to review policy strength, reporting setup and alignment — or build a correctly formatted record with the DMARC builder.