DMARC Analyzer

• What This Tool Does

DMARC (Domain-based Message Authentication, Reporting & Conformance) Check analyzes your domain's DMARC policy, which tells receiving servers what to do with emails that fail SPF or DKIM checks.

• Why It Matters

• → Policy Enforcement: Controls how unauthorized emails are handled
• → Reporting: Receives feedback about email authentication failures
• → Brand Protection: Prevents domain impersonation attacks
• → Visibility: Monitors who is sending emails using your domain

• How to Read the Results

• ✓ p=policy: none (monitor), quarantine (spam), or reject (block) — start with none and progress to reject
• ✓ pct=percentage: Controls what percentage of failing mail the policy applies to (default 100)
• ✓ rua=: Aggregate report email address — receives daily XML summaries of all authentication results
• ✓ ruf=: Forensic report email address — receives per-message details for authentication failures
• ✓ sp=: Subdomain policy — overrides the p= policy for subdomains of the main domain
• ✓ adkim= / aspf=: Alignment mode — r (relaxed) allows subdomain match, s (strict) requires exact match

• Technical Background

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.