DMARC is the anti-spoofing record that ties SPF and DKIM together with an enforcement policy. Published correctly at p=reject, it makes it impossible for attackers to send mail claiming to be your domain to compliant receivers (Gmail, Outlook, Yahoo, most enterprise filters).
But DMARC is also the email auth record most likely to break your mail flow if rolled out wrong. Most teams either stop at p=none (no actual enforcement) or jump to p=reject and accidentally block legitimate transactional mail from a forgotten internal service.
This is the 90-day rollout we run when customers ask 'how do I implement DMARC without breaking everything?'. Day-by-day actions, exact tag values, what to watch in aggregate reports, and the 5 mistakes that derail it.
Why 90 Days (and Not Faster)
DMARC enforcement breaks legitimate mail when one of your senders is:
- Not in your SPF record (sends from an IP your SPF doesn't authorize)
- Not DKIM-signing with your domain (signs with their own d= instead)
- Forwarded through systems that break SPF (mailing lists, individual user forwards)
Most mid-size companies have dozens of legitimate sending sources they don't immediately remember: marketing ESP, transactional service, support desk, payment notifications, calendar invites, vendor 'invoice sent' emails, recruiting tools, monitoring alerts, internal scripts. Every one of these needs SPF and DKIM aligned to your domain or DMARC will block them.
The 30 days at p=none gives you time to see all of them in your aggregate (rua) reports. The 30 days at p=quarantine catches the ones you missed before they fully break. The 30 days at p=reject is the final cutover.
Faster rollouts work for small operations (only 2-3 sending sources). For most, 90 days is the minimum that doesn't break mail.
Pre-Flight Checklist (Before You Even Publish p=none)
1. Inventory all your sending sources.
List every service that sends mail from your domain. Common ones to forget: Calendly, Loom, Asana notifications, GitHub, GitLab, AWS SES (transactional), Stripe (receipt emails), Intercom, HelpScout, internal cron-job mailers.
2. Confirm SPF is published and correct.
Use [our SPF Checker](/spf-checker) - must be 1 record, ≤10 DNS lookups, ends in ~all (will move to -all later). Every sending source from step 1 should be reachable via the SPF chain.
3. Confirm DKIM is set up for every major sender.
Most ESPs (SendGrid, Mailgun, Postmark, Mailchimp) require you to set up 'custom DKIM' using your domain (d=yourdomain.com) rather than their default. Use [our DKIM Checker](/dkim-checker) to verify selectors exist for each.
4. Choose a DMARC report parser.
Receivers send raw XML to your rua= address. You need a parser to read them. Free options: Postmark DMARC Weekly Digest, dmarcian free tier, EasyDMARC free, Valimail Monitor. Sign up to one BEFORE publishing DMARC - having the dashboard ready makes the rollout much easier.
5. Pick a reporting email address.
Use a dedicated address (e.g., [email protected]). Reports can be voluminous; don't dump them in your main inbox.
Day 0 - Publish p=none
Generate your initial DMARC record. Use [our DMARC Generator](/dmarc-generator) or manually:
``
_dmarc.yourdomain.com IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"
`
What each tag does:
- v=DMARC1
- protocol version (required) - p=none
- monitor only, no enforcement - rua=mailto:...
- where to send daily aggregate reports - pct=100
- apply policy to 100% of mail (only matters when p≠none) - Run [DMARC Checker](/dmarc-checker) on your domain
- Confirm it shows the record correctly
- Send a test email to a Gmail address, check 'Show Original' for dmarc=pass`
Publish via your DNS provider. TTL of 3600 (1 hour) is fine.
Verify within an hour:
From this point, daily aggregate reports start arriving at your rua= address from every major receiver (Google, Microsoft, Yahoo, etc.).
Days 1-30 - Monitor & Identify Sending Sources
Daily routine during this phase:
Open your DMARC report dashboard. Look at:
- SPF passes + aligned + DKIM passes + aligned = good, no action needed
- One passes, one fails = still good (DMARC needs only one), but worth fixing the failing one
- Both fail = legitimate sender that DMARC will block when you ramp
- Forgotten legitimate sender (Calendly, GitHub, etc.) - add to SPF or set up DKIM
- Spoofing attempt - investigate, but DMARC will block these at quarantine/reject
- Forwarder (a recipient forwarded your mail; the new IP shows as sender) - accept these will fail SPF; rely on DKIM alignment
By day 14: you should have a clear list of every legitimate sending source. Fix any with broken alignment.
By day 30: pass rate should be >95% for legitimate sending sources. Spoofing-attempt rows should be visible and clearly different from legitimate ones.
If pass rate is still below 95% at day 30, DON'T move to quarantine yet. Extend the monitoring phase by 2 weeks and fix the remaining issues.
Days 30-60 - Ramp to p=quarantine
When you're confident every legitimate sender passes alignment, move to quarantine. Start at 25% to minimize impact:
``
_dmarc.yourdomain.com IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"
``
Now 25% of unauthenticated mail goes to spam folders. Watch your aggregate reports for:
- Spike in 'quarantined' actions for legitimate sources. If any legitimate sender starts failing, drop back to p=none and fix before re-ramping.
- Customer reports of missing mail. Internal users or customers may notice transactional mail going to spam. Each report = one sending source you missed.
- Day 30: p=quarantine; pct=25
- Day 37: p=quarantine; pct=50 (if no issues)
- Day 45: p=quarantine; pct=75
- Day 52: p=quarantine; pct=100
Ramp schedule:
At pct=100 quarantine, all unauthenticated mail goes to spam folders at compliant receivers. Spoofing attempts now land in spam folders, not inboxes - significant protection improvement.
Watch for a full week at pct=100 before moving to reject.
Days 60-90 - Ramp to p=reject
After 30 days at p=quarantine pct=100 with no broken legitimate mail, move to reject. Again, start at 25%:
``
_dmarc.yourdomain.com IN TXT "v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]"
`
Now 25% of unauthenticated mail is REJECTED outright by receivers (returned as bounces to the spoofer's MTA). Spoofers see your domain as 'blocked' and may give up; legitimate forwarded mail bounces.
Critical: forwarded mail is the most common collateral damage at p=reject. If a user has a Gmail filter that forwards to a personal Hotmail address, the forwarded mail will fail SPF (different IP) and DKIM may also fail if the forwarder modifies headers. The forwarded mail bounces.
Mitigation: most legitimate forwarders preserve DKIM, so DKIM alignment usually saves the day. But ~5-15% of forwarded mail still bounces at p=reject.
Ramp schedule:
- Day 60: p=reject; pct=25
- Day 70: p=reject; pct=50
- Day 80: p=reject; pct=75
- Day 90: p=reject; pct=100
At pct=100 reject, your DMARC is fully enforced. Spoofers can no longer reach compliant receivers claiming to be your domain.
After day 90, you can remove the pct= tag entirely (defaults to 100):
`
_dmarc.yourdomain.com IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
``
What to Watch in Aggregate Reports Forever
Even after the rollout completes, keep watching aggregate reports. Patterns to look for:
Sudden volume spike from unknown IPs. Could be a new spoofing campaign. With p=reject in place, they'll mostly be blocked - but a sustained campaign may indicate someone targeting your brand.
Legitimate sender dropping alignment pass rate. ESPs sometimes change their infrastructure (new IPs, new DKIM selectors) and stop aligning. You'll see pass rate fall from 99% to 70%. Catch this within days, not weeks, to avoid bouncing your own transactional mail.
Forwarded-mail bounce patterns. Specific users (often those at older companies) may forward mail through systems that break alignment. These users will report missing mail. Add their forwarder IP to SPF (if controllable) or accept the small percentage of bounces.
Quarterly review: confirm every sending source is still aligned. ESPs change DKIM selectors annually; SPF chains evolve. Re-audit your DMARC reports quarterly.
5 Mistakes That Derail DMARC Rollouts
Mistake 1: Skipping p=none and jumping to p=quarantine on day 1.
Result: you don't know what's misaligned. Legitimate transactional mail gets quarantined immediately. Customer complaints flood in. You roll back, lose confidence, never try again.
Mistake 2: Not setting up a report parser.
Raw XML reports are unreadable. Within a week of publishing rua=, your inbox is full of XML files you can't process. You stop checking. The rollout stalls at p=none forever.
Mistake 3: Forgetting about transactional mail from non-ESP services.
GitHub, GitLab, Calendly, Loom, AWS billing - all send mail. None are in your initial SPF inventory. They start failing alignment when you ramp to quarantine. Customer-facing apps break.
Mistake 4: Using a shared mailbox for rua= reports.
Aggregate reports come in as XML attachments at the rate of 5-50 per day. Your team's shared inbox quickly fills, real customer email gets buried. Use a dedicated mailbox or service.
Mistake 5: Treating subdomain DMARC as automatic.
DMARC at the apex (yourdomain.com) doesn't automatically protect subdomains. If you send mail from mail.yourdomain.com or noreply.yourdomain.com, those need their own DMARC record OR the apex DMARC needs sp= (subdomain policy) set explicitly.
For most senders: add sp=reject (or sp=quarantine during rollout) to the apex DMARC record. Receivers will then apply the policy to all subdomain mail by default.
Special Cases
Mailing lists (Google Groups, Mailman, etc.) - these often modify mail headers and break DKIM alignment. The mailing-list operator should publish their own DMARC-compliant forwarding (use of From rewriting to the list's domain). If you have customers on your mailing lists, expect some breakage.
Internal forwarders (alice@yourdomain forwards to [email protected]) - these usually preserve DKIM correctly. Modern forwarders are DMARC-aware.
Subdomains used for marketing (marketing.yourdomain.com) - publish DMARC on the apex with sp=reject. Receivers will inherit the policy. Or publish per-subdomain DMARC records for finer control.
B2B customers using your-from-address relay - some B2B integrations send 'from' your domain via their infrastructure. Either add them to your SPF and set up DKIM for them, or have them send from their own domain on your behalf.
M&A scenarios - when you acquire a company, their domain's DMARC posture is now your problem. Plan for a 60-90 day audit of any acquired domain before integrating its sending into yours.
Frequently Asked Questions
Can I skip the rollout and go straight to p=reject?
Only if you have 1-2 sending sources and full confidence in their alignment. For everyone else, no - jumping to p=reject is the #1 way to break legitimate transactional mail and lose customer trust. The 90 days exist to find every legitimate sender you forgot.
Do I need both rua= and ruf= reports?
rua= (aggregate) is essential - it's the daily summary you need to verify the rollout. ruf= (forensic) is optional - most major receivers (Google, Microsoft) don't send ruf reports anymore for privacy reasons. Skip ruf= unless you have a specific compliance need.
What happens to mail forwarded by recipients to other inboxes?
Forwarded mail loses SPF alignment (the forwarder's IP isn't in your SPF). DKIM usually survives forwarding because the signature is in the message headers, not based on IP. As long as DKIM aligns, DMARC passes. Expect ~5-15% of forwarded mail to fail alignment and bounce at p=reject. This is acceptable collateral damage in most cases.
How do I know which sending source an alignment failure belongs to?
Your aggregate report shows the source IP that sent the mail. Cross-reference that IP against known ESP ranges (most ESPs publish their IP ranges) or run a reverse-DNS lookup to identify the host. Free DMARC parsers (Postmark, dmarcian, EasyDMARC) auto-identify common senders by IP pattern.
Generate Your DMARC Record
Our DMARC Record Generator builds the exact TXT record for each rollout phase (p=none / quarantine / reject) - free, no signup. Plus our DMARC Checker verifies it after you publish.
Build My DMARC Record