How to Diagnose DMARC Failures from Aggregate Reports

When you first open a DMARC aggregate report and see thousands of failures, the instinct is to panic. Most of the time, the situation is recoverable. The problem is that DMARC failures are not all the same kind of problem, and treating them as if they are leads to wasted time and wrong fixes.

This guide walks through what actually causes DMARC failures, how to read your aggregate reports to identify the specific cause, and what to do about each one. Tools like DMARCFlow automate the report parsing and surface the highest-volume failures first, so you spend time on fixes rather than on manual XML inspection.

The most common confusion: SPF pass, DMARC fail

Before getting into the failure types, one pattern needs to be addressed immediately because it comes up more than any other.

SPF can pass and DMARC can still fail. This catches people off guard because they assume DMARC is just an extension of SPF. It is not. DMARC adds a layer called alignment, and that is where most legitimate email fails.

Understanding this distinction is the key to reading aggregate reports correctly. When you get an aggregate report with failures, your first job is not to fix the failure. Your first job is to figure out which of the four failure types you are looking at.

The four failure types

p=fail means the message failed DMARC policy enforcement. This is the outcome, not the cause. It tells you DMARC rejected or quarantined a message. It does not tell you why. You need to look at the SPF and DKIM results to find the reason.

SPF fail means the sending mail server IP was not authorized by your SPF record. The IP sending the email is not in your SPF record.

DKIM fail means the message was signed with a DKIM key that does not match your domain, or the signature was missing entirely.

Alignment failure surprises people. A message can pass SPF or DKIM but still fail DMARC because the domain that was authenticated does not match the From domain. There are two alignment modes: relaxed (subdomains can align) and strict (only exact domain matches pass). Relaxed is the default.

The most common real-world failure is alignment failure on forwarded email. A message is sent from your domain, passes SPF and DKIM for your domain, then gets forwarded by a mailing list or auto-forwarder. The forwarding server becomes the new sender, SPF fails for the forwarding server IP, and the forwarded message fails DMARC.

Reading aggregate reports

DMARC aggregate reports arrive as XML files. The file contains a record for every message attempt from your domain that a participating receiver processed.

Here is a simplified view of what a failure record contains:



  
    203.0.113.42
    47
    
      none
      fail
      pass
    
  
  
    example.com
    example.com
  
  
    
      example.com
      fail
    
    
      example.com
      pass

In this record, SPF passed but DKIM failed. The message was not rejected (disposition: none) because the domain policy was p=none. The count of 47 means this failure happened 47 times from the same source.

The key fields to check for every failure:

source_ip - which server sent the message
dkim result - did the DKIM signature verify
spf result - did SPF authorize the sending IP
disposition - what the receiver did (none, quarantine, reject)
reason - if present, gives additional context from the receiver

Reading raw XML does not scale if you receive thousands of messages per day. This is where automated tools help. DMARCFlow parses aggregate reports automatically, groups failures by source IP and failure type, and shows you which ones are worth acting on first based on volume and whether the sender is expected. Without that, you end up manually scanning XML for every failure, which is time-consuming and error-prone.

Common failure patterns

Third-party senders failing DMARC

Marketing automation platforms, CRM systems, support desk tools, and billing platforms often send email from their own infrastructure using your domain in the From address. When they do this without proper DKIM signing or SPF alignment, you see DMARC failures.

The fix depends on the vendor. Some vendors provide DKIM keys you add to your DNS, which lets them sign mail on your behalf. Some require you to add their sending IPs to your SPF record. A few do neither, and you have to either live with the failures or find an alternative.

Before assuming a vendor is broken, check whether they have documentation for DMARC compliance. High-volume senders like Mailchimp, SendGrid, and HubSpot all have setup guides for this.

Forwarded email showing alignment failure

Forwarding breaks DMARC because the forwarding server becomes the new sender. SPF then fails for the forwarding server IP, and the original DKIM signature may no longer be valid after the forward.

The solution is usually ARC (Authenticated Received Chain), described in RFC 8617. ARC adds a chain of signatures that preserves the original authentication results through the forwarding chain. Many modern mail providers support ARC. If you run your own mail server, enabling ARC can reduce false positives on forwarded mail.

Subdomain misalignment

If your organizational domain is example.com and a team spins up a sending subdomain like updates.product.example.com, that subdomain needs its own SPF and DKIM records. If it only has an SPF record but no DKIM, you see failures.

The fix: either add DKIM keys to the subdomain, adjust your DMARC policy to be more permissive for subdomains using the sp (subdomain policy) tag, or ensure the subdomain has both authentication methods configured.

Mailing lists that rewrite From address

Some mailing list software rewrites the From header to show the original sender but sends from the mailing list server. This almost always causes alignment failures because the authenticated envelope domain does not match the header From domain.

This is a known problem with no clean universal fix. Some mailing lists support DMARC-compatible modes. For others, you either accept the failures or switch to a different platform.

Diagnosis decision tree

Use this in order when you see failures in your aggregate report:

Step 1: Is SPF passing for the failing source IP?

If SPF fail: check whether that IP should be in your SPF record. If it is a legitimate sender (third-party vendor, internal relay), add it to SPF.

If SPF pass: proceed to step 2.

Step 2: Is DKIM passing for your domain?

If DKIM fail: check whether the sending system is signing with your DKIM key. If it is a third-party sender, they need to sign with your domain or you need to configure DKIM for them.

If DKIM pass: proceed to step 3.

Step 3: Does alignment pass?

If alignment fail: the authenticated domain does not match your header From domain. Check whether the sender is using a different subdomain or a third-party system that is not properly configured for your domain.

If alignment pass: check the disposition and reason fields. You may be seeing failures from a prior state before you fixed the underlying issue.

Most failures fall into one of those six branches. Working through them systematically will find the cause every time.

What to do after diagnosis

Each cause has its own fix path:

Missing SPF for a legitimate vendor: add their IPs or include to your SPF record
Third-party sender not DKIM-signing for your domain: configure DKIM with the vendor or move to a vendor that supports it
Forwarding causing failures: consider enabling ARC, or adjust the forwarding chain if possible
Subdomain sending without SPF/DKIM: add the required records for the subdomain
Mailing list From rewriting: switch to a DMARC-compatible mailing list platform, or accept the failures if the volume is low
Legacy system that cannot be fixed: consider moving that system to a subdomain with its own looser DMARC policy

For ongoing monitoring, aggregate reports are only useful if someone actually reviews them. Setting up p=none with an rua address when you first deploy DMARC lets you see what is happening before you tighten the policy. Ramping from p=none to p=quarantine to p=reject over weeks or months is the safe path to full enforcement.

FAQ

My SPF passes but DMARC fails. Why?

This is alignment failure. SPF authenticated the sending IP, but the domain that was authenticated does not match your From domain. This commonly happens with forwarded mail, third-party senders, or mailing lists. Check the DKIM result and alignment in your aggregate report to confirm.

What is the difference between p=fail and SPF fail?

p=fail is the outcome (DMARC rejected the message). SPF fail is one possible cause of that outcome. You can have DMARC fail without SPF failing, and you can have SPF fail without DMARC failing (if your policy is p=none).

How often do aggregate reports arrive?

There is no standard schedule. Receivers decide when and whether to send them. Some send daily, some weekly. Google, Yahoo, and Microsoft all send aggregate reports, but only if you have an rua tag in your DMARC record and a valid email address to receive them.

Should I move to p=reject immediately?

No. Start with p=none and review aggregate reports for at least two to four weeks. Identify all legitimate senders and make sure they are properly configured before tightening policy. Moving to p=reject prematurely will break legitimate email with no warning.

Can I monitor DMARC without changing my policy?

Yes. Set v=DMARC1; p=none; rua=mailto:your@email.com and you will receive aggregate reports without any enforcement. This is the right first step for any domain that has not yet deployed DMARC.