How to Roll Out DMARC to p=reject Without Losing Legitimate Mail
The Goal: Full Enforcement, Zero Collateral Damage
DMARC at p=reject is the gold standard for domain protection. It tells every receiving mail server to outright reject messages that fail authentication under your domain—closing the door on spoofing and phishing attacks that impersonate your brand. But moving too fast causes legitimate mail to vanish without a trace. The path from no DMARC to p=reject takes most organizations three to six weeks, and skipping steps is how mail teams end up in crisis at 2 a.m.
This guide walks through the process methodically: start with visibility, then enforce incrementally, and only reach for full rejection after the reports confirm you're ready.
Phase 1: Publish p=none and Start Receiving Reports
The first DMARC record you publish should do nothing to mail flow. Its only purpose is to start generating aggregate reports (RUA) and forensic reports (RUF) that show you every source sending mail that claims to be your domain.
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1"Key fields explained:
p=none— monitor only, no enforcementrua=— address for aggregate XML reports (sent daily by most providers)ruf=— address for forensic (per-failure) reportsfo=1— send a forensic report when either SPF or DKIM fails (not just when both fail)
Leave this in place for at least one full week—two is better. You're waiting for aggregate data from all the providers your recipients use, and some send reports only once every 24 hours.
Phase 2: Read the Reports and Map Your Sending Sources
Aggregate DMARC reports arrive as gzip-compressed XML files. They're not easy to read raw, so use a report processing service or tool to parse them. What you're looking for in each report:
- Which IPs are sending mail from your domain?
- Are those IPs passing SPF and/or DKIM?
- Are there sources you don't recognize?
Build a list of every legitimate sending source: your ESP, transactional mail service, CRM, support ticketing tool, billing system, and any internal servers. For each one, confirm that it passes either SPF alignment or DKIM alignment. DMARC requires aligned authentication—an SPF pass on a subdomain doesn't satisfy DMARC unless the domain in the From header matches the SPF-authenticated domain.
Any sending source that currently fails alignment needs to be fixed before you move to enforcement. Common fixes:
- Add the source's IP to your SPF record
- Enable DKIM signing for that source and publish the key
- Switch the source to send via a subdomain with its own SPF/DKIM configuration
Phase 3: Move to p=quarantine at a Low Percentage
Once your reports show all known legitimate sources passing DMARC consistently, add a percentage policy to start soft-enforcement:
_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com"The pct=10 tag applies the quarantine policy to only 10% of failing messages. The other 90% are still treated as p=none. This gives you a safety net while you validate that real mail isn't getting swept up.
Watch your aggregate reports for the next several days. If legitimate mail starts failing, you'll see it in the reports before a full rollout affects your entire domain. When the 10% window looks clean, step up to pct=25, then pct=50, then pct=100. Some teams move through these steps weekly; others spend two weeks at each stage.
Phase 4: Harden to p=reject
When you've been at p=quarantine; pct=100 for a full week with no legitimate mail failures in your reports, you're ready for the final step:
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"Drop the pct tag entirely (it defaults to 100). At this point, receiving servers will reject—not quarantine, not deliver to spam—any message claiming to be from your domain that fails DMARC. Spoofed phishing emails using your domain are stopped at the receiving server before they even hit a user's inbox.
What to Watch After Reaching p=reject
Keep monitoring your RUA reports even after enforcement. Common post-enforcement surprises:
- A forgotten internal system that started sending mail after your audit
- A new SaaS integration added by another team without telling you
- A third-party vendor that sends on behalf of your domain (invoice software, e-signature tools)
New failing sources will appear in aggregate reports before users start complaining about missing mail. A weekly report review takes five minutes and catches these issues early.
Subdomain Policy
The sp= tag controls DMARC policy for subdomains not covered by their own DMARC record. If you don't set it, subdomains inherit the root domain policy. For most organizations, sp=reject alongside p=reject is the right final state. If you have subdomains that send mail without authentication, address those first.
The Connection to SPF and DKIM
DMARC enforcement is only as solid as the authentication records behind it. A DMARC rollout is the right time to also audit your SPF record for the 10-lookup limit and verify that DKIM keys are published correctly for every sending source. The MailDog DNS security checker validates all three records together, making it easy to spot gaps before you tighten your policy. If you need a sending infrastructure that handles DMARC-aligned signing out of the box, MailDog's mail service takes care of DKIM configuration automatically.
