How to Read DMARC Failure Reports: A Field Guide to Authentication Debugging

What DMARC Failure Reports Are and When You See Them

A DMARC failure report arrives when a receiving mail server rejects or quarantines a message because it failed DMARC authentication. Unlike aggregate reports (RUA), which summarize authentication results over a 24-hour period, failure reports fire immediately after a single message fails.

Failure reports use the Abuse Reporting Format (ARF), defined in RFC 6591. They contain the actual message headers from the failing email: the From address, Return-Path, source IP of the sending server, and the specific reason the message failed.

If you are running p=none monitoring and only using aggregate reports, you may not have seen a failure report yet. Once you move to p=quarantine or p=reject, failure reports start arriving for every message that fails. That is when administrators often get a shock: the volume can be high, and the format is not friendly.

This guide explains what the reports contain, what each auth-failure type means, and how to use the data to diagnose actual problems instead of just collecting noise.

Aggregate Reports vs Forensic Reports: The Difference

Most DMARC documentation focuses on aggregate reports (RUA). Failure reports (RUF) are less discussed but just as important.

Aggregate reports arrive on a daily schedule (or whatever interval your receiving domain specifies). They are XML files, usually delivered as ZIP attachments, containing a summary of how many messages passed and failed, broken down by source IP and sending domain. They tell you what happened overall.

Forensic/failure reports (RUF) arrive immediately after a single message fails authentication. They contain the actual headers of the failing message. They tell you exactly what happened with one specific email.

RUF reports are more granular and more noisy. Many organizations disable them because the volume is high and the format is complex. The tradeoff is real: you lose immediate visibility into individual failures, but you reduce noise and avoid the privacy risk of forwarding full message headers.

If you are running p=none, you are probably only seeing aggregate reports. Once you move to p=quarantine or p=reject, start paying attention to RUF data. The failure reports tell you things aggregate reports cannot.

The ARF Format: Key Fields Decoded

DMARC failure reports use ARF (RFC 6591), an extension of the Abuse Reporting Format originally designed for abuse complaints. An ARF message has a multipart structure: the first part is a human-readable explanation, the second part is the original message headers, and a third optional part may contain the message body.

The fields you care about most are in the report metadata and the original message headers:

Feedback-Type tells you what kind of report this is. For DMARC failures it is "auth-failure".

Auth-Failure is the core field. It tells you which authentication check failed. The main values are:

• DKIM: the DKIM signature did not verify


• SPF: the sending server IP was not in the SPF record

Reported-Domain is the domain that triggered the report (the domain in the From header).

The message headers inside the report give you the rest. The Return-Path header tells you the actual envelope-from address. The From header tells you what the recipient's mail client displayed. The Received headers trace the path the message took.

The most actionable fields are usually found by reading the original headers, not the ARF metadata alone.

DKIM Auth-Failure Types: What Each Code Means

When the Auth-Failure field shows "DKIM", the DKIM signature on the message did not verify. That means the message was either modified in transit or signed with a key that does not match the domain's published DKIM record.

The most common reasons for DKIM failure:

The message was modified in transit. Some relay servers add or remove headers, change the From address formatting, or rewrap the message in ways that break the DKIM signature. This is common with mailing lists, forwarders, and some forwarding services. The signature was valid when the message left, but it was not valid when it arrived.

The DKIM selector has no matching record in DNS. If the sending domain publishes a DKIM key at selector "s1" but the sender is using selector "s2", verification fails with no match. This happens when sending infrastructure changes and DNS records are not updated.

The private key was rotated without updating DNS. Key rotation is a routine maintenance task. If the new private key is active but the DNS TXT record still points to the old public key, every message fails DKIM until DNS propagates.

The signing domain does not match the From header domain. DMARC requires alignment: the domain used to sign (the "d=" tag in the DKIM signature) must match the domain in the From header. If your CRM sends from "crm.example.com" but the From header shows "example.com", the DKIM signature is valid but fails alignment under DMARC.

SPF Auth-Failure Types: What Each Code Means

When the Auth-Failure field shows "SPF", the sending server's IP address was not authorized by the domain's SPF record. The message came from a server that is not allowed to send mail for that domain.

The most common reasons for SPF failure:

Third-party sender not in SPF. Services like marketing automation platforms, legacy relay systems, or internal applications that send email claiming to be from your domain often do this. They send from their own infrastructure, which is not in your SPF record. This is the single most common cause of legitimate mail breaking when you move to a strict DMARC policy.

Forwarding broke SPF. When a forwarder receives a message and resends it from their server, the original SPF check no longer applies. Their server IP is not in your SPF record, so the message fails SPF after forwarding. This is why forwarding and SPF do not work together without DKIM alignment.

Subdomain has no SPF record. If your organizational domain has p=reject and a subdomain sends mail without its own SPF record, every message from that subdomain fails SPF at receiving servers. The subdomain inherits the parent domain's DMARC policy but has no authentication of its own.

Alignment Failures: The Check Most People Miss

DMARC does something SPF and DKIM do not require: it checks alignment. A message can pass both SPF and DKIM and still fail DMARC if the authenticated domain does not match the From header domain.

Relaxed alignment allows the signing domain (for DKIM) or the envelope-from domain (for SPF) to be a subdomain of the From header domain. A message signed with "example.com" passes alignment for From "subdomain.example.com".

Strict alignment requires an exact match. The signing domain or envelope-from must be identical to the From header domain.

Most organizations use relaxed alignment. The DMARC record "rua" tag points to where aggregate reports go, and "ruf" points to where failure reports go. The "p" tag sets the policy: none, quarantine, or reject.

When you see a failure report with both SPF and DKIM showing pass, but the report still generated, look at the alignment field. The domain that authenticated did not match the From header domain. That is an alignment failure.

Extracting the Source IP: What to Do With It

The source IP in the failure report tells you which server tried to send the message. This is the most actionable field in the report.

If the source IP is one you do not recognize, it is worth investigating. A quick lookup against your own sending infrastructure and known vendor IPs will tell you whether it is a trusted sender that needs configuration fixes, or an unknown party that may be spoofing your domain.

If the source IP belongs to a legitimate third-party sender (a CRM, a marketing platform, an internal relay), you have two options: add them to your SPF record if they send from a fixed IP range, or configure them to sign with DKIM keys that carry your domain in the signature alignment.

If the source IP is not associated with any known sender, it may be a spoofing attempt. Blocking that IP at your mail gateway is a reasonable response, though spoofing attacks are often distributed across many IPs.

How to Tell Spoofing Attempts From Legitimate Misconfigurations

This is the most common question failure report reviewers ask: is this someone spoofing my domain, or is it a legitimate sender I need to fix?

A few indicators:

High volume from many different source IPs across different networks is more consistent with spoofing. Attackers send from distributed bot networks. Legitimate senders usually have a more stable IP footprint.

Known third-party service domains in the Return-Path indicate a legitimate misconfiguration, not spoofing. If the Return-Path shows " bounces@esp-domain.com" and the ESP is a service you use, the sender is legitimate but not aligned.

Source IPs in geographic regions you do not send to can indicate spoofing but can also indicate legitimate forwarding. Correlate with your own sending data.

Repeated failures from the same IP with the same From address over time suggests a misconfiguration that has not been addressed rather than an active spoofing campaign.

The Return-Path header (also called the envelope-from) is the most reliable field for distinguishing spoofing from misconfiguration. If the Return-Path domain is one you recognize and control, the sender is legitimate. If the Return-Path is blank or from an unknown domain, it is more likely spoofing.

Why Forwarding Breaks DMARC: A Specific Failure Mode

Forwarding deserves special attention because it generates DMARC failures in a very specific way that confuses many administrators.

When a message is forwarded, the forwarding server becomes the new sending server. It may rewrite the Return-Path to its own address (for bounce handling), and it may modify headers in ways that break DKIM. The original SPF check was run against the first sending server's IP, not the forwarder's IP. After forwarding, the forwarder's IP fails SPF for the original domain.

DKIM is more resilient to forwarding than SPF, but not immune. Some forwarding services modify the message in transit, which invalidates the DKIM signature even if the content was not changed intentionally.

If you see DMARC failures from IPs that belong to forwarding services (Gmail, Outlook.com, Yahoo are common forwarders), and the failures are for legitimate expected mail, the options are limited. The forwarding service would need to implement ARC (Authenticated Received Chain) to preserve authentication results across forwards. Not all forwarding services do this.

Reading Failure Reports With DMARCFlow: Structured Parsing vs Raw ARF

Here is what a DMARC failure report looks like in raw ARF format, and what DMARCFlow does with it.

A raw failure report arrives as a multipart email message. The second part contains the original message headers. Extracting the relevant fields manually means reading across nested header blocks, identifying the source IP from Received headers, and matching auth-failure types to the original message. For a single failure, this takes five to ten minutes. For a domain receiving hundreds of failures per day, it does not scale.

DMARCFlow connects to your RUF endpoint and parses incoming failure reports into structured records: timestamp, source IP, auth-failure type (SPF, DKIM, or alignment), sending domain, and From address. You see the same data in a filterable list instead of nested email headers.

The practical difference matters when you are debugging: instead of opening individual ARF messages to find the source IP of a DKIM failure, you query for all DKIM failures in the last 24 hours and see source IPs grouped by sending domain. Instead of manually reading Received headers to trace the forwarding path, you see the failure type and alignment result in each record.

For administrators running p=quarantine or p=reject, structured failure data turns a high-volume firehose into something manageable. You can filter out known forwarders, focus on unaligned sources from unknown IPs, and track whether your legitimate senders are improving their DKIM alignment over time.

This guide covers how to read the raw format so you understand what structured output is doing for you. If you want to skip manual parsing entirely, DMARCFlow is the practical path.

What to Do When You Get a Failure Report: A Decision Framework

Not every failure report demands action. Here is how to prioritize:

If the source IP is a known legitimate sender with misconfigured authentication, open a ticket with that vendor. Ask them to either add their sending IPs to your SPF record or configure DKIM signing with your domain. This is the most common fixable failure type.

If the source IP is a forwarding service handling mail you sent, assess whether the volume is acceptable and whether the recipients are receiving the mail. If forwarding is causing important mail to be quarantined, you may need to adjust your policy until forwarding services implement better ARC handling.

If the source IP is not recognizable and the failure is DKIM or SPF, the domain may be spoofed. These reports confirm your DMARC policy is working. Consider whether you have sufficient evidence to block or investigate further.

If you see alignment failures for your own infrastructure, audit your DKIM signing configuration. Make sure your mail servers are signing with the correct domain, not a parent or sibling domain that fails alignment.

FAQ

What is the difference between aggregate and forensic/failure reports?

Aggregate reports (RUA) are daily summaries in XML format. Failure reports (RUF) arrive immediately for each individual message that fails. Aggregate reports tell you the trend. Failure reports tell you exactly what happened with a specific message.

What does "auth-failure: SPF" mean in my failure report?

It means the sending server's IP address was not listed in the domain's SPF record. The message was not authorized to send for that domain by SPF.

What does "auth-failure: DKIM" with result "fail" mean?

It means the DKIM signature on the message did not verify against the domain's published DKIM public key. The message was likely modified in transit, or the sending infrastructure is using a DKIM key that does not match DNS.

Why am I getting failure reports for emails I did not send?

You are likely being spoofed. Attackers send email that appears to come from your domain to recipients whose mail servers then check DMARC and report the failure back to you. These reports confirm your DMARC policy is active. If the volume is high from many different source IPs, this is a distributed spoofing campaign, not a configuration problem on your side.

Why do forwarding services generate DMARC failures?

Forwarding services become the new sending server when they forward mail. The original sending server's IP, which is in your SPF record, is no longer the sending IP. SPF fails at the receiving server because the forwarder's IP is not in your SPF record. DKIM may also fail if the forwarder modifies headers. This is a known limitation of SPF and DKIM that only ARC can solve.

Can I disable forensic/failure reports and just use aggregate reports?

Yes, remove the "ruf" tag from your DMARC record. You will continue receiving aggregate reports via the "rua" tag. Disabling RUF reduces noise and avoids the privacy complexity of forwarding full message headers. The tradeoff is losing immediate per-message visibility.

What is the arrival-time field in a failure report?

It is the date and time when the receiving server generated the failure report, not when the original message was sent. Failure reports are generated by the receiving server, not the sending server.

How do I extract the source IP from a failure report to identify the sending server?

The source IP appears in the ARF metadata as the reporting-mta field, and also in the message headers as the connecting server IP in the Received headers. Both are useful: the ARF field tells you which MTA generated the report, and the Received headers trace the full delivery path.