DMARC Analyzer

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) builds on SPF and DKIM to provide comprehensive email authentication. A DMARC policy record is a DNS TXT record published at _dmarc.example.com. The policy specifies: p=none (monitor only, collect reports), p=quarantine (route to spam folder), or p=reject (refuse the email entirely). DMARC alignment requires that either the SPF-authenticated domain or the DKIM signing domain aligns with the From: header domain — this prevents display name spoofing that SPF and DKIM alone cannot stop.

DMARC reporting provides two feedback types: aggregate reports (rua=) delivered daily as XML files summarizing all email traffic, and forensic reports (ruf=) providing per-message details for authentication failures. Organizations analyze aggregate reports using tools like DMARC Analyzer, Dmarcian, Valimail, or Google Postmaster Tools to identify unauthorized senders, discover legitimate services that need SPF/DKIM configuration, and track policy enforcement progress.

Best practice follows staged deployment: start with p=none to collect reports without affecting mail flow, analyze reports for 2-4 weeks to identify all legitimate senders, configure SPF and DKIM for all legitimate sending sources, move to p=quarantine at pct=10 (10% of failing mail) and gradually increase, then advance to p=reject for maximum protection. Common pitfalls include forgotten mail services (newsletters, CRM, support systems) not yet authenticated, and subsidiary domains lacking DMARC records. DMARC at p=reject is required by Google and Yahoo for bulk senders sending over 5,000 messages per day.

Forensic DMARC reports (ruf=) provide rich data for security incident investigation: they reveal the IP address that sent the unauthorized email, the From: and Return-Path: headers, the DKIM signature (or lack thereof), SPF result, and the receiving mail server. Privacy regulations in some jurisdictions restrict ruf= usage because forensic reports contain actual email header data. Aggregate reports (rua=) are privacy-safe and should always be configured. DMARC policy inheritance: a policy at example.com applies to subdomains, but explicit subdomain policies (sp= tag) can override. Attackers frequently exploit domains that have DMARC at p=none or no DMARC record at all — moving to p=reject is the strongest defense against domain impersonation.