Blog · Dmarc
How to Read and Investigate DMARC Failure Reports
What Is a DMARC Failure Report
When a DMARC policy fails and your domain receives RUA (reporting URI aggregate) or UFproto (forensic) reports, you get a message that tells you which specific messages failed and exactly why. Most mailbox providers send these as plain-text emails with an attached XML file.
Most administrators receive these reports and immediately close them. The XML is not designed for human reading. But every field exists for a reason, and once you know what to look for, you can extract useful signal from noise.
This guide walks through a real anonymized DMARC failure report, explains every field, and shows how DMARCFlow turns the raw output into something you can actually act on without opening XML files by hand.
Reading a Real Failure Report
A DMARC forensic report arrives as an email from the receiving provider. The body is typically empty or contains brief instructions. The payload is an XML file attached to the message. When you open the XML, you see something structured like this (simplified and anonymized):
<feedback><report-metadata> <org-name>mail-provider-example.com</org-name> <date-range> <begin>1692403200</begin> <end>1692489599</end> </date-range></report-metadata><records> <record> <row> <source-ip>203.0.113.42</source-ip> <count>1</count> <policy-published> <domain>example.com</domain> <adkim>r</adkim> <aspf>r</aspf> <p>quarantine</p> <sp>none</sp> </policy-published> </row> <auth-results> <spf> <domain>example.com</domain> <result>pass</result> <smtp-c-to>forwarder.example.net</smtp-c-to> </spf> <dkim> <domain>example.com</domain> <result>fail</result> </dkim> </auth-results> </record></records></feedback>
Here is what every field means.
Field-by-Field Breakdown
org-name The company that generated the report. This tells you which mailbox provider rejected or flagged the message. Google, Microsoft, and Valimail are common sources.
date-range begin / end Unix timestamps covering the reporting window. Convert with: date -d @1692403200 on Linux or Mac.
source-ip The IP address of the mail server that sent the failing message. This is the primary field for investigation. Look up the IP in a blacklist checker or your own send log to identify the sending system. DMARCFlow surfaces this field automatically and cross-references it against your known sending infrastructure so you can immediately tell authorized sends from unauthorized ones.
count How many matching messages were seen from this IP during the reporting window. A count of 1 means a single message. Growing counts across multiple reports indicate a sustained problem that needs attention before your DMARC policy causes legitimate mail to be quarantined.
domain (under policy-published) The domain that published the DMARC record. This should match your sending domain.
adkim (alignment mode for DKIM) r means relaxed, s means strict. Relaxed allows subdomains to align. If your DMARC record says s (strict), a message from mail.example.com sending for example.com fails even if DKIM is valid. DMARCFlow shows you your current alignment mode alongside each failure so you know whether strict mode is the cause.
aspf (alignment mode for SPF) Same logic as adkim but for SPF. Relaxed alignment is the default.
p (policy) Your DMARC policy at the time of the message: none, quarantine, or reject. This is what you published, not what the receiver did with the message.
sp (subdomain policy) The policy applied to subdomains of your domain. Often none even when the main domain uses quarantine or reject. Check this before assuming a subdomain failure is a problem.
SPF result The result of SPF authentication for this IP and domain. pass means the sending IP is authorized for the envelope-from domain. fail means the IP is not in the SPF record.
smtp-c-to (SPF scope) The envelope-from domain used in the SMTP conversation. This can differ from the header-from domain, which is what DMARC actually checks. A mismatch here causes alignment failures that look like auth failures if you only glance at the SPF result.
dkim result The result of DKIM validation. pass means the message had a valid DKIM signature from this domain. fail means no valid signature was found, or the signature was tampered with. When DKIM fails but SPF passes, you have an alignment problem, not an authentication problem. DMARCFlow highlights exactly this combination in its incident view so you do not waste time investigating SPF.
Why Authentication Passes but Alignment Fails
The most common pattern in failure reports looks like this:
- SPF: pass - DKIM: fail - DMARC: fail
This happens when a message passes SPF (the sending IP is authorized) but the DKIM signature is missing or invalid. DMARC requires at least one of SPF or DKIM to pass AND align with the header-from domain. Two passing signals do not override one failing alignment.
The reverse is also common:
- SPF: fail - DKIM: pass - DMARC: fail
In this case, DKIM passes but alignment fails. The DKIM signature exists but is signed by a different domain than the header-from address.
Alignment means the domain in the DKIM signature (the d= tag) or the SPF check (the envelope-from domain) must match the domain shown in the From: header of the email. If they do not match, DMARC fails regardless of individual auth results.
Top 5 Failure Patterns and How to Fix Each
1. Forwarded mail A message is forwarded through a third-party server that does not apply your DKIM signature. The original SPF passes for the original IP, but the forwarding server's IP is not in your SPF record and the DKIM signature is lost. Fix: Use ARC (Authenticated Received Chain) headers if forwarding is expected, or set aspf=r for relaxed SPF alignment.
2. Marketing automation tools Your CRM or marketing platform sends from a subdomain like mail.crmplatform.com but claims to send on behalf of example.com. SPF passes because the CRM's IP is in their SPF record. DKIM fails because the d= tag is crmplatform.com, not example.com. Fix: Set up custom DKIM signing with your own domain on the sending platform.
3. Legacy third-party relays Internal mail systems that relay on behalf of your domain without applying your DKIM key. SPF may pass for the relay IP but the From: header shows your domain. Fix: Ensure the relay rewrites the From: header to a subdomain covered by your DMARC policy, or implement SMF (SMTP-FROM) alignment.
4. Subdomain misalignment You have p=s (strict) in your DMARC record and a message comes from support@example.com but your SPF or DKIM is set up for example.com only. Strict mode requires exact domain match. Fix: Set aspf=r and adkim=r (relaxed) unless strict enforcement is specifically required.
5. Spoofed submission Someone is sending email that claims to be from your domain but is not using your mail servers at all. The SPF fails (IP not authorized) and DKIM fails (no signature from your domain). Fix: This is the failure mode DMARC is designed to catch. When p=reject is deployed, spoofed mail is blocked at the receiver.
What DMARCFlow Does With Failure Reports
Manual XML parsing works for one-off investigation. When you are receiving DMARC reports from multiple providers across dozens of sending systems, the volume becomes unmanageable. DMARCFlow parses incoming RUA aggregate reports and UFproto forensic reports automatically, normalizes the data, and surfaces the highest-risk failures first.
Instead of opening XML files, you see a ranked list of failing IPs, the authentication results that caused each failure, and the message volume attached to each incident. You can filter by date range, source IP, or failure type. Each incident links back to the relevant section of the failure report so you can verify the data without opening raw XML.
For ongoing monitoring, DMARCFlow alerts on new sources of failure before they accumulate into a deliverability problem.
FAQ
Can I opt out of receiving DMARC failure reports? Yes. Your DMARC record can specify ruf= (forensic URI) to point at a specific endpoint. If you remove ruf=, you stop receiving forensic reports. Aggregate reports via rua= continue regardless.
Why do I sometimes receive failure reports for my own sending? Your own mail servers may occasionally generate failures if DKIM signing is not applied consistently, or if a secondary system sends without going through your main mail infrastructure. A small number of self-referrals is normal during transitions. Large volumes indicate a configuration problem.
Should I act on every failure in the report? No. A single failure from a known and trusted source (like an internal relay that is being phased out) does not require action. Focus on failures from unknown IPs with growing message volume.
DMARC failure reports are dense but informative. Learning to read them takes less time than you might expect, and the signal is worth the effort.