DMARC Reports Explained: How to Read Them and Fix Auth Failures

You enabled DMARC monitoring, and now your inbox is flooded with zipped XML attachments from Google, Microsoft, and Yahoo. These are DMARC Aggregate Reports (RUA). They look like gibberish to the human eye, but they contain the only definitive data about who is sending email as your domain—and whether they are passing authentication.

Ignoring these reports is the #1 reason DMARC projects stall. Without reading them, you cannot move to a "reject" policy because you don’t know which legitimate senders (like your CRM, support desk, or invoicing tool) you would block. This guide explains how to read these reports, what the data means, and exactly how to fix the "Auth Fail" errors you find.

What is a DMARC Aggregate Report?

A DMARC aggregate report is a daily summary sent by an email receiver (like Gmail or Office 365) to the email address specified in your DMARC record's rua= tag. It does not contain the actual emails or sensitive content. Instead, it is a statistical list of every IP address that claimed to be your domain yesterday.

Each report answers three critical questions for a specific 24-hour period:

• Who sent mail? The IP addresses and hostnames of the senders.
• Did they pass SPF and DKIM? The raw authentication results.
• Did they align? Whether the authenticated domain matched your visible "From" domain (the key to passing DMARC).

How to Read the XML (Without Going Crazy)

While you should use a tool to visualize this data (see "Tools" below), understanding the raw XML helps you debug tricky edge cases. Here is the anatomy of a record inside the report:

<record>
  <row>
    <source_ip>192.0.2.1</source_ip>
    <count>50</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>thirdparty.com</domain>
      <result>pass</result>
    </spf>
    <dkim>
      <domain></domain>
      <result>none</result>
    </dkim>
  </auth_results>
</record>

This single record tells a complete story:

1. The Sender: IP 192.0.2.1 sent 50 emails.
2. The Problem: SPF passed (technically), but DMARC likely failed or relied purely on SPF alignment. Notice the <domain>thirdparty.com</domain> in the SPF section? The server was authorized by thirdparty.com, not yourdomain.com.
3. The Alignment Gap: The visible sender (header_from) is yourdomain.com, but the SPF return-path (domain) is thirdparty.com. If they don't match, SPF Alignment fails.

The Core Concept: Alignment vs. Authentication

This is where 90% of admins get stuck. You might see "SPF Pass" in your report but "DMARC Fail." Why? Because of Alignment.

DMARC requires that the domain doing the authenticating matches the domain in the "From:" header.

Check	Requirement	Common Failure Scenario
SPF Authentication	Is IP allowed to send?	IP is allowed, but for the wrong domain (e.g., SendGrid's domain, not yours).
SPF Alignment	Does Return-Path match From?	Using a third-party tool that handles bounces (Return-Path) on their own domain.
DKIM Authentication	Is the signature valid?	Message body modified in transit; key rotation failure.
DKIM Alignment	Does d= tag match From?	Signing with the vendor's generic key (d=sendgrid.net) instead of your custom domain key.

Fixing Common Auth Failures

Scenario 1: The "Unaligned SPF" (Mailchimp, SendGrid, Zendesk)

The Symptom: SPF says "Pass", but the domain listed is mcsv.net or sendgrid.net, while your header from is yourcompany.com. DMARC fails SPF alignment.

The Fix: You cannot fix SPF alignment for many hosted services because they need to handle bounces (Return-Path) on their own servers. Instead, you must set up DKIM. DMARC passes if either SPF or DKIM aligns. Log in to your email provider, find "Domain Authentication" settings, and generate CNAME records to enable DKIM signing for your specific domain.

Scenario 2: The "Forwarding Breaker"

The Symptom: You see DMARC failures from random IPs you don't recognize, but the DKIM result says "pass" (if present) or "fail" (if body changed). The IPs often belong to universities or ISPs.

The Reality: This is auto-forwarding. Someone at a university forwarded their alumni email to Gmail. The university's server sent the mail, breaking SPF (because the university IP isn't in your record). If you have a valid, aligned DKIM signature, the email survives forwarding. If you rely only on SPF, the email fails DMARC.

The Fix: Ensure 100% of your legitimate mail is DKIM-signed. You cannot "fix" the forwarding servers, but DKIM allows your mail to survive the hop.

Scenario 3: The "Subdomain Mismatch"

The Symptom: You send mail from marketing.yourdomain.com. Your SPF record covers yourdomain.com. DMARC fails.

The Fix: SPF does not inherit permissions. You need a separate TXT record for marketing.yourdomain.com. Alternatively, check your DMARC alignment mode. If your policy says aspf=s (strict), subdomains fail. The default is aspf=r (relaxed), which allows marketing.yourdomain.com to align with yourdomain.com.

Tools to Visualize RUA Reports

Do not try to read XML files manually every day. Use a tool to aggregate them into dashboards.

• Free/Open Source: Parsedmarc (self-hosted), Postmark DMARC (weekly digests only).
• Commercial (SaaS): Valimail, Dmarcian, Uriports. These provide detailed forensics and sender categorization.
• Quick Check: MXToolbox DMARC Report Analyzer (upload a single XML file for instant visualization).

When to Ignore Failures

Not every "Fail" in a report needs fixing. You will consistently see failures from:

• Spammers/Spoofers: IPs in Russia or China sending as your domain with no authentication. This is good. Your DMARC policy is identifying them. Once you move to p=reject, these get blocked.
• Calendar Invites (sometimes): Auto-generated invites forwarded between systems can sometimes break alignment.

Your goal is not 0% failure rate; it is 0% failure rate for your legitimate infrastructure.