Advanced DMARC policies: edge cases, scale, and monitoring

This guide assumes DMARC policies is already deployed and passing. It covers what breaks at scale and how mature teams operate it.

Edge cases that break a working setup#

• Jumping straight to p=reject and blocking your own invoicing or HR system.
• Sending RUA reports to a mailbox nobody reads; use a report processor.
• Leaving subdomains uncovered because sp= was never set.
• Assuming p=none provides protection; it is monitoring only.
• Mail forwarded through mailing lists or personal forwarders, which alters headers and content.
• Acquisitions and rebrands that introduce domains nobody audited.
• Vendors silently changing their sending infrastructure.

Operating it as infrastructure#

1. Assign an owner for each sending domain and each vendor relationship.
2. Put DNS records under version control or a change-review process.
3. Alert on authentication pass rate drops and reputation changes, not just outages.
4. Run a quarterly audit against the setup steps below.
5. Document runbooks for the three most common failures.

Reference: the baseline setup#

1. Confirm SPF and DKIM are deployed and aligned for every legitimate sender.
2. Publish _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com to begin collecting reports.
3. Analyze aggregate (RUA) reports for 2 to 4 weeks to identify unauthenticated legitimate sources.
4. Fix each source, then move to p=quarantine with pct=25, ramping to 100.
5. Move to p=reject and add sp=reject to cover subdomains.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-rua@example.com; adkim=s; aspf=s; pct=100"

Frequently asked questions#