How to Read and Act on Your DMARC Failure Reports

Why Most Domains Never Read Their DMARC Reports

DMARC reports are the most underused data source in email security. Most domains that publish a DMARC record set it to p=none and never look at what comes back.

The reports arrive as gzip-compressed XML attachments from every receiver that processes mail from your domain. Gmail sends them. Yahoo sends them. Microsoft sends them. A spam gateway in a law firm in Nebraska sends them. Most of those reports land in an unmonitored inbox and sit there.

The reason is not indifference. The reports are genuinely hard to parse. They arrive in machine format from dozens of sources, each with its own quirks, and they require domain knowledge to act on. The p=none policy means nothing is being blocked, so there is no immediate pain driving someone to investigate.

That changes the moment you move to p=quarantine or p=reject. Then every failure in your reports becomes a real email that did not reach the recipient. Before that move, reading your reports is how you find out what you do not yet know about who is sending as your domain.

What a DMARC Aggregate Report Contains

A DMARC aggregate report covers a time period and contains two main sections: report metadata and individual message records.

Report metadata:

The domain and org_name of the sender generating the report

The DMARC record policy (p=none, p=quarantine, or p=reject) in effect at that receiver

The reporting receiver contact info (from the DMARC/rua tag)

The date range the report covers

Message records (one per sending source IP observed):

source_ip: the IP address that sent the mail

count: how many messages from that IP were processed

policy_evaluated: what the receiver decided to do with those messages (disposition: none, quarantine, or reject)

SPF result: pass or fail for SPF check

DKIM result: pass or fail for DKIM check

aligned_domain: the domain used for alignment checking

The policy_evaluated field is the one that matters most. It shows the receiver's disposition decision for each batch of messages, not just whether the authentication checks passed.

The "disposition: none" value means the receiver delivered the message normally. "disposition: quarantine" means it was junked. "disposition: reject" means it was blocked. If you see "disposition: reject" for a batch of messages that should have been delivered, that is your signal to investigate.

Reports arrive at the address specified in your DMARC record's rua tag. If you have not set an rua address, you are not receiving reports at all.

SPF Alignment Failure vs. DKIM Alignment Failure

These are two different checks and they fail for different reasons.

SPF checks whether the RFC 5321 MAIL FROM domain (also called the bounce address or Return-Path domain) is authorized by your SPF record. If you send mail from your own mail server, your MAIL FROM domain matches your From domain and SPF passes. If you send through a third-party sender whose servers are listed in your SPF record, it also passes. If a third-party sender is not in your SPF record, SPF fails.

DKIM checks whether the domain in the DKIM-Signature header is aligned with your From domain. A valid DKIM signature means the message was signed by a server authorized to use that domain's DKIM selector. If the signing domain matches your From domain, DKIM alignment passes. If a marketing platform signs mail using its own domain instead of yours, DKIM passes but DKIM alignment fails.

A DMARC pass requires at least one of SPF or DKIM to pass alignment. A DKIM pass with alignment beats an SPF pass without alignment. That ordering matters when a third-party sender causes failures.

Here is a concrete example. You use Brevo to send your marketing mail. Brevo's servers sign the mail with Brevo's own DKIM selector, not yours. From your recipient's perspective: DKIM result is pass (the DKIM signature is valid), but the aligned_domain is Brevo's domain, not your From domain. DKIM passes but DKIM alignment fails. If you have not added Brevo's servers to your SPF record, SPF also fails. Both SPF and DKIM fail alignment. Your aggregate report shows a failure from Brevo's IPs, but your mail was delivered because at least one check passed. This is normal behavior, not a compromise.

The reason both can fail even when your own DNS records are correct is that third parties are sending mail using your From domain but their own infrastructure. Your SPF record covers your servers, not theirs. Your DKIM selectors are on your domain, not theirs. Neither check was designed for multi-vendor email sending by default.

The Three Failure Categories in DMARC Reports

Missing or misconfigured SPF

You see SPF alignment failures in your report for IPs that are not your own mail servers. The third-party sender you use for transactional mail, marketing, or support tickets is sending as your domain but its IPs are not in your SPF record. This is the most common DMARC failure. It shows up as SPF result: fail with aligned_domain not matching your From domain. Fix: add the sender's include mechanism to your SPF record, or switch to a sender that uses your domain for its MAIL FROM.

Missing or misconfigured DKIM

DKIM failures from sending platforms that sign mail with their own domain rather than yours. Many bulk senders (Brevo, Mailgun, SendGrid) use their own DKIM keys by default. This appears in your report as DKIM result: pass (the signature is cryptographically valid), but DKIM alignment: fail because the signing domain does not match your From domain. For DMARC alignment to pass, you need those senders to use custom DKIM selectors on your domain, or you need to set up DKIM signing through your own infrastructure. Check: does your sending platform offer custom DKIM setup, and have you completed it?

Aligned identity mismatch: the spoofing signal

This is the failure that means someone is sending mail as your domain from outside your known infrastructure. SPF fails, DKIM fails, neither aligned domain matches your From domain. The sending IP is not in your SPF record and not signing with your DKIM selector. This is the signal that requires immediate investigation. Is it a vendor you forgot to account for, or is it a spoofing attempt?

A DKIM pass with alignment failure is annoying but fixable. The same with SPF misalignment. The red flag is when both fail together, from an IP you do not recognize. That is the spoofing signal.

How to Separate Spoofing From Legitimate Third-Party Senders

The most important column in your DMARC report is source_ip. Cross-reference each IP in your report against your known sending infrastructure.

If an unknown IP appears in your report with From addresses matching your domain, that is a failure to investigate. The question is whether it is a forgotten vendor or an attacker.

Red flags for spoofing rather than legitimate sending:

The failure count spikes suddenly for a specific IP

The failure count is high but the IP has no reverse DNS matching your domain

The messages are being sent outside normal business hours

The receiving domain reporting the failure is one you do not recognize

You can check an IP manually using its reverse DNS (PTR record) and forward-confirmed reverse DNS. If the forward and reverse DNS agree, the IP has a verifiable identity. If they do not, treat it as less trusted.

The practical rule: every new source of mail from your domain that you did not deliberately set up is a gap until proven otherwise.

That is where DMARCFlow fits directly. Instead of manually cross-referencing each new source_ip against your known infrastructure, DMARCFlow monitors your aggregate reports continuously and flags any new sending IP that appears without SPF and DKIM alignment. The moment a vendor you forgot to add appears in your reports, you see it before it causes a production incident. The goal is to turn a manual forensic process into an automated alert.

When Your Failure Rate Means You Are Not Ready for p=reject

Moving to p=reject is the goal of most DMARC deployments. When a receiving server gets a message that fails DMARC and your policy is reject, it drops the message silently. No bounce to the sender. No notification to you. The mail simply disappears.

That sounds clean until you realize how many sources you have not accounted for. A moving company that handles appointment reminders for your sales team. A legacy SaaS tool that sends invoices using your domain from a server nobody documented. A new marketing platform that went live without updating your DNS.

Your failure rate tells you how many unknown sources are still sending as your domain. If that rate is above zero and it is not stable, you are not ready for p=reject. Moving early means those mailstreams break silently and you lose the messages without knowing they were sent.

The readiness signal: your failure rate is stable at or near zero for a consecutive measurement period (at least one full report cycle, ideally two weeks), and every new sending source you discover during monitoring is either added to your SPF/DKIM configuration or is confirmed as a spoofing attempt to be blocked.

How DMARCFlow Makes Report Interpretation Automatic

DMARC reports arrive in XML format from dozens of receivers. Parsing them manually means opening gzip attachments, decoding XML, normalizing field names that differ between receivers, and tracking which sending IPs appeared in which report and when.

DMARCFlow connects to your rua endpoint, pulls aggregate reports as they arrive, normalizes the data across all receivers, and presents it in a dashboard that shows:

which sending IPs appeared in your reports and when

which IPs are new since your last measurement period

your SPF and DKIM alignment failure rates over time

which receivers are sending you reports (so you know your visibility coverage)

alerts when a new source starts sending as your domain without SPF or DKIM coverage

This turns a manual investigation task into an automated monitoring process. The failure rate you need to track before moving to p=reject becomes something you can see at a glance, with a record of every change.

FAQ

What is a DMARC aggregate report?
An aggregate report is a regular digest from each email receiver, sent to the address specified in your DMARC record's rua tag. It covers a time period and lists every sending source that sent mail as your domain, along with the SPF, DKIM, and DMARC evaluation result for each batch.

How do I read the XML format of a DMARC report?
Most receivers send the report as a gzip-compressed XML file attached to an email. Open the attachment, decompress it, and look for the record/row elements inside the feedback tag. Each row represents a sending source IP and its evaluation results. Many tools (including DMARCFlow) can parse these files automatically so you do not need to read the XML directly.

What is the difference between SPF alignment failure and DKIM alignment failure?
SPF alignment failure means the MAIL FROM domain used by the sending server is not aligned with your From domain. DKIM alignment failure means the domain in the DKIM-Signature header is not aligned with your From domain. Both require the aligned domain to match your From domain for DMARC to pass. A message can SPF-pass but still fail DMARC if the aligned domain does not match.

Why does my DMARC report show failures from my own mail server?
If your own mail server appears with SPF or DKIM failures, the most common cause is a mismatch between your MAIL FROM domain (or DKIM signing domain) and your From domain. This can happen with certain mail relay configurations, after DNS changes, or when mail is forwarded. Check your mail server's bounce address configuration and your DKIM selector setup.

When should a high DMARC failure rate stop me from moving to p=reject?
If your failure rate is above zero and includes sources you have not identified, moving to p=reject will silently drop legitimate mail from those sources. Move to p=reject only when your failure rate is stable at zero for all known sending sources, and when every new source discovered through monitoring is either authorized or blocked.