What DMARC Failure Reports Tell You About Email Security

You enabled DMARC. Your reports are arriving. They show thousands of failures. Before you panic, understand what you are actually looking at.

A DMARC failure report is your email infrastructure telling you something did not authenticate correctly. It is a diagnostic signal, not an emergency. In most environments, a large proportion of failures turns out to be misconfigured third-party senders, internal forwarding, or mailing list relays - all of which are fixable.

Here is how to read the reports and decide what actually needs your attention.

What Is a DMARC Aggregate Report?

When you publish a DMARC record, participating email receivers send you periodic reports summarizing what they saw from your domain. These are called aggregate reports. They arrive in XML format, typically daily, to the email address or endpoint you specified in your DMARC record's rua tag.

Google, Microsoft, Yahoo, and most other major receivers send these reports. If you are not receiving them, your DMARC record may be missing the rua directive.

If parsing XML manually sounds tedious - it is. This is exactly why most administrators set up DMARCFlow to ingest these reports automatically and present the data as a searchable dashboard. You see what failed, from which IP, and why, without opening raw files. The alternative is downloading XML reports that almost no one opens.

Anatomy of a DMARC Report

A DMARC aggregate report contains one or more records. Each record represents a single sending source's interaction with a receiver. The fields that matter most:

| Field | What it tells you |
|---|---|
| orginal_domain | The domain being authenticated |
| source_ip | The IP address that sent the message |
| count | How many messages from this IP passed through this receiver |
| spf_result | pass or fail |
| dkim_result | pass or fail |
| dmarc_result | pass, fail, or "none" |

The dmarc_result is the final verdict. It can be pass even when SPF or DKIM individually failed, as long as one of them passes and the alignment is correct.

What trips up most administrators: the failure is not always what you think. A DKIM pass does not mean your sending infrastructure is healthy if a third-party vendor is using your From header with their own DKIM key. Understanding which specific mechanism failed - SPF, DKIM, or alignment - is what lets you route the fix to the right team.

The Three Ways Email Fails DMARC

DMARC authentication is layered on top of SPF and DKIM. An email fails DMARC when neither SPF nor DKIM produces a passing result that is aligned with the sender domain. There are three distinct failure patterns:

SPF alignment failure. The message was sent from an IP that is not in your SPF record, or the sender domain (the MailFrom envelope domain) does not match your From header domain. This is the most common DMARC failure pattern in complex email environments.

DKIM alignment failure. The message was signed with a DKIM key that uses a different domain than your From header. This happens frequently when third-party platforms send on your behalf but sign with their own domain.

Both alignment failure. Neither SPF nor DKIM authenticated correctly, and neither is aligned with your From domain. This is the pattern most likely to indicate a spoofing attempt - but it can also mean your own sending infrastructure is misconfigured.

Which Failures Are Normal?

Not every failure means something is broken. Some failures are expected:

Mailing list forwarders. When a mailing list server forwards your message, it often changes headers or sends from its own relay. This commonly produces DKIM alignment failures. The forwarding server is not spoofing you - it is just not preserving your DKIM signature correctly. This is why spf-softfail and some DKIM failures are routine for high-volume senders.

Third-party senders using their own infrastructure. Your marketing platform, billing system, or support desk may send from its own servers. If they are not using your domain in their DKIM signature, you will see failures. The fix is to configure a custom sending domain for that service.

Internal relay servers. Some internal mail systems rewrite headers or relay internally without authenticating. These produce failures in aggregate reports but do not affect external delivery.

The pattern to look for: failures from IPs that belong to known legitimate senders are config problems. Failures from IPs you do not recognize require investigation.

Which Failures Signal a Real Problem?

Real problems tend to show a specific pattern: sudden spikes in failure volume from IPs you do not recognize, for domains that should not be sending through your infrastructure.

Specific warning signs:

A new sending IP appears in your report and produces consistent DKIM failures. This can mean someone is sending email that claims to be from your domain.
Your failure rate jumps from 5 percent to 40 percent overnight. Something in your sending infrastructure changed.
You see failures from your own domain name in the source IP field from third-party receivers. This often means a vendor is using your domain incorrectly.
Failures from IPs in geographic regions where you have no sending infrastructure.

The third scenario - a vendor using your domain without proper authentication - is more common than spoofing. But it still needs fixing, because it damages your deliverability and can trigger rejections from strict receivers.

What to Do When You Find a Real Problem

Step 1: Identify the source IP. Look it up in your sending infrastructure logs or a reverse DNS lookup. If it belongs to a known vendor, that narrows the fix to a configuration change on their side.

Step 2: For third-party senders. Configure them to send from a subdomain you control (like marketing.example.com) with its own DMARC record set to p=none. This isolates their authentication from your primary domain's policy. Many platforms call this "custom domain sending."

Step 3: For forwarding-related failures. There is no fully reliable fix for all forwarding scenarios. Setting rf=failure in your DMARC record requests forensic reports on alignment failures specifically, which helps you distinguish forwarding from spoofing.

Step 4: If you suspect spoofing. Check whether the messages are reaching inboxes or being blocked. If receivers are accepting and delivering spoofed messages, your DMARC policy may need to move from p=none to p=quarantine or p=reject sooner than planned.

How DMARCFlow Makes This Easier

The problem with DMARC reports is not understanding them in theory - it is keeping up with them in practice. Most administrators receive them and never look at them because the data is too dense to review manually.

DMARCFlow is built for this. It parses aggregate reports automatically and turns them into actionable signals:

It displays failure trends over time, so you spot a spike before it becomes a crisis.
It tags each failure with the specific reason code - SPF fail, DKIM fail, or alignment fail - so you know which mechanism broke without cross-referencing the DMARC spec.
It alerts on new sending IPs and sudden volume changes, the two patterns most likely to indicate a real problem rather than routine noise.
For MSPs managing multiple clients, it aggregates reports by domain so each client's report is isolated and readable.

The practical result: instead of reviewing reports manually, you get a notification when something actually changes. Routine forwarding failures stay quiet while real problems surface immediately.

FAQ

Why does my report show SPF pass but DKIM fail?
SPF passed because the sending IP is in your SPF record. DKIM failed because the message was not signed with a key matching your From domain. This happens often with third-party platforms that send from their own infrastructure but use your domain in the From header. The email may still deliver if the receiver only checks one of the two mechanisms.

Why do I see failures for my own domain's IP addresses?
If the sending IP is yours but DMARC still fails, check the alignment. SPF alignment requires the MailFrom domain to match your From domain. If you send from a subdomain and your From header shows your root domain, the alignment check fails even though SPF passes.

What is a "mailfrom alignment" failure?
MailFrom alignment means the envelope sender domain (the domain used in the SMTP MAIL FROM command) does not match the domain in the message's From header. This is the most common alignment failure for organizations that use different domains for sending and receiving.

How often should I check my DMARC reports?
At minimum weekly, but only if you have a reason to look. If you have DMARCFlow monitoring them, you do not need to check proactively - you wait for an alert. The goal is to notice problems before they become reputation damage.

Can DMARC reports tell me if someone is spoofing my domain?
Yes, partially. If you see sending IPs in your DMARC report that you do not recognize, someone may be sending email that claims to be from your domain. DMARC reports do not show message content, only that a receiver processed something with your domain in the From field from an unauthenticated source. Forensic reports (RUF) give you message-level detail, but most receivers no longer send them due to abuse concerns.

Conclusion

DMARC failure reports are an early warning system. When you receive them and actually read them, you catch config problems before they cause deliverability damage and you catch spoofing attempts before they damage your domain's reputation.

Most failures are not attacks. They are configuration problems - third-party senders that need custom domain setup, forwarding chains that are outside your control, or internal relays that rewrite headers.

Review your reports. Fix what you can fix. Ignore what is noise. Use a monitoring tool if parsing XML manually is the reason you never look at them.