What is a DMARC Report and Why You Should Read Them

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a critical email authentication protocol designed to protect your domain from impersonation, phishing, and spoofing. While setting up a DMARC record with p=none is a good first step, the real power of DMARC lies in its reporting mechanism. These reports are the feedback loop that tells you exactly what's happening with emails claiming to be from your domain, whether they're legitimate or malicious.

If you've deployed DMARC and aren't regularly analyzing your reports, you're essentially flying blind. You're missing out on vital intelligence about your email ecosystem and the efficacy of your DMARC policy. This article will demystify DMARC reports, explain their structure, dive into why alignment failures occur, and arm you with practical steps to leverage this data.

The Basics: How DMARC Reports Work

At its core, DMARC builds upon two older email authentication standards: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). * SPF allows a domain owner to specify which IP addresses are authorized to send email on behalf of their domain. * DKIM provides a cryptographic signature that verifies the sender's identity and ensures the email hasn't been tampered with in transit.

DMARC adds a crucial layer: it dictates what receiving mail servers should do with emails that fail SPF or DKIM, and it introduces an "alignment" requirement. For an email to pass DMARC, at least one of SPF or DKIM must pass and align with the From: domain.

The "Reporting" part of DMARC is handled by DMARC reports. When you publish a DMARC record in your DNS, you typically include two optional tags: rua and ruf. * rua (Reporting URI for Aggregate Reports): This specifies an email address where aggregate reports should be sent. These are XML files, usually sent daily, that summarize all email traffic seen by a receiving mail server claiming to be from your domain. They provide high-level statistics without revealing message content. This is where you get the most actionable data. * ruf (Reporting URI for Forensic Reports): This specifies an email address for forensic reports. These are individual copies of messages that failed DMARC, often including headers and sometimes truncated body content. While potentially useful for deep dives, ruf reports raise significant privacy concerns and are often disabled by receiving mail servers, making rua reports the primary focus for DMARC analysis.

Receiving Mail Transfer Agents (MTAs) – like Gmail, Microsoft Outlook, Yahoo, and countless others – generate these aggregate reports. They parse their incoming email logs, compile the data for domains with DMARC records, and send the resulting XML files to the rua address you've specified. This means you'll receive reports from many different organizations, each detailing their perspective on your domain's email traffic.

What's Inside a DMARC Aggregate Report? (The Gory Details)

DMARC aggregate reports are XML files, and if you've ever tried to read one raw, you know they can be dense. They're designed for machine parsing, not human readability. However, understanding their structure is key to appreciating what tools like Aligned do.

A typical DMARC aggregate report contains several main sections:

  1. report_metadata: Information about the report itself, including the reporting organization (e.g., Google, Microsoft), the report's ID, and the date range it covers.
  2. policy_published: This section reflects the DMARC policy you've published in your DNS at the time the report was generated. It includes your p (policy), sp (subdomain policy), adkim (DKIM alignment mode), aspf (SPF alignment mode), pct (percentage of messages to apply policy to), and fo (failure options). This is crucial for confirming that receiving servers are seeing your intended policy.

  3. record: This is the most important and repetitive section. Each record element represents a unique combination of sending IP address, authentication results, and policy evaluation for a set of emails.

    • row: Contains source_ip (the IP address of the sending server) and count (how many emails from this IP address during the reporting period matched this specific set of authentication results).
    • policy_evaluated: This is where you see the DMARC verdict.
      • disposition: What the receiving server would have done based on your DMARC policy (e.g., none, quarantine, reject). If your policy is p=none, this will always be none.
      • dkim: Result of the DKIM check (pass, fail).
      • spf: Result of the SPF check (pass, fail).
      • reason: Sometimes provides additional context for a failure (e.g., local_policy).

  4. auth_results: Within each record -> row, this section details the raw SPF and DKIM authentication results:

    • dkim:
      • domain: The domain found in the d= tag of the DKIM signature.
      • result: The raw DKIM authentication result (pass, fail, neutral, etc.).
    • spf:
      • domain: The domain found in the Return-Path (or Mail From) header.
      • result: The raw SPF authentication result (pass, fail, softfail, neutral).

The Crux: DMARC Alignment

This is where many engineers new to DMARC get tripped up. SPF and DKIM can pass independently, but DMARC requires alignment with your From: domain.

  • SPF Alignment: The domain in the Return-Path header (used for SPF checking) must match or be a subdomain of the domain in the From: header.
  • DKIM Alignment: The domain specified in the d= tag of the DKIM signature must match or