DMARC Policy Configuration Guide

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving mail servers what to do when an email fails both SPF and DKIM authentication. Your DMARC policy is published as a DNS TXT record at _dmarc.yourdomain.com. The three DMARC policy levels: p=none — Monitor only. Emails that fail authentication are still delivered. You receive reports showing who is sending email as your domain. This is the starting point for every DMARC deployment. p=quarantine — Failed emails are sent to the recipient's spam/junk folder. This provides protection while allowing recipients to review quarantined messages. An intermediate step toward full enforcement. p=reject — Failed emails are blocked entirely and never reach the recipient. This is the strongest protection and the ultimate goal. At p=reject, no one can successfully spoof your domain. Cyber Defense Agent checks your DMARC policy level. While p=none is a valid starting configuration, p=quarantine or p=reject demonstrates mature email security and is preferred by cyber insurance carriers.

DMARC's reporting capability is what makes the gradual enforcement path possible. There are two types of DMARC reports: Aggregate reports (rua) — XML reports sent daily (by default) showing authentication results for all emails sent as your domain. These reports reveal: - Which servers are sending email as your domain - Whether messages passed or failed SPF and DKIM - The volume of email from each source - Which messages would be affected by stricter policies Forensic reports (ruf) — Individual failure reports sent for each authentication failure. These contain more detail but can be voluminous and are not supported by all receiving servers. A complete DMARC record with reporting: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1 Use a dedicated mailbox or a DMARC reporting service (like Postmark, dmarcian, or Valimail) to process aggregate reports. Raw XML reports are difficult to read manually.

Moving from p=none to p=reject safely requires a methodical approach: Weeks 1-4: Deploy DMARC with p=none - Publish your DMARC record with p=none and rua reporting - Monitor aggregate reports to identify all legitimate email senders - Ensure SPF and DKIM are correctly configured for every authorized sender Weeks 5-8: Move to p=quarantine with pct=25 - Change policy to p=quarantine; pct=25 (only 25% of failing emails are quarantined) - Monitor for legitimate email being quarantined - Fix any remaining SPF/DKIM issues for legitimate senders - Gradually increase pct to 50, then 100 Weeks 9-12: Move to p=reject - Change policy to p=reject; pct=25 - Monitor closely for any impact on legitimate email - Gradually increase pct to 100 - At p=reject; pct=100, your domain is fully protected Common pitfalls: - Rushing to p=reject without monitoring (blocks legitimate email) - Forgetting to authorize third-party senders before enforcement - Not using the pct tag for gradual rollout - Ignoring DMARC reports during the monitoring phase