How to Read and Act on DMARC Failure Notifications

What Is a DMARC Failure Notification?

A DMARC failure notification is an email report sent to you when an email receiver checks your DMARC record and the message fails authentication. The failure could mean the message was spoofed - someone faked your domain in the From address. Or it could mean a legitimate message failed alignment even though it passed SPF or DKIM.

The notification you receive is usually a compressed XML file attached to an email, or a ZIP file containing XML. Most email administrators who implement DMARC have never opened one of these reports. Many who have opened them closed them immediately because the format is not user-friendly.

That is a mistake. These reports tell you exactly what is happening with email that claims to be from your domain. If you ignore them, you miss real problems and real attacks.

The challenge is that reading these reports manually takes time. Aggregating them across multiple receivers and tracking failure trends over time requires tooling. That is where DMARCFlow fits in - it collects these reports automatically and turns them into actionable summaries instead of raw XML.

Breaking Down the DMARC Report: SPF, DKIM, and Alignment

A DMARC failure report contains three layers of information.

Authentication results show whether SPF and DKIM passed or failed. SPF checks whether the sending mail server is authorized for your domain. DKIM adds a cryptographic signature to the email header that proves the message was not altered in transit. Neither of these alone grants permission to use your domain in the From address.

Alignment checks are what DMARC adds on top. Even if SPF and DKIM both pass, DMARC also verifies that the domain in the From address matches the domain authorized by SPF or signed by DKIM. This is where most legitimate email fails. A message can pass SPF and DKIM but still fail DMARC alignment if the From address domain does not match the Return-Path or DKIM-signing domain.

The DMARC result combines both. It shows whether the message passed both authentication and alignment, or failed one or both checks.

Here is what the failure types actually mean in practice:

• SPF alignment failure: The message was sent from a server that is authorized to send for the domain in the Return-Path, but the From address domain is different. This commonly happens with mailing lists, forwarded email, and some marketing automation tools.
• DKIM alignment failure: The message was signed by DKIM for a domain that does not match the From address. This happens when email passes through a third-party service that signs with its own domain instead of yours.
• Both SPF and DKIM alignment failures: The message failed both checks. This is the pattern most likely to indicate an impersonation attempt, but it can also occur with misconfigured third-party senders.

Why You Might See Failures Even When Legitimate Email Is Being Sent

Most sysadmins panic the first time they see a DMARC failure notification because they assume it means something is broken. In practice, some failures are normal and expected.

Third-party email services are the most common source of unexpected failures. When you send email through Salesforce, Mailchimp, SendGrid, or any other ESP, those services send from their own infrastructure with their own domains in the Return-Path. If the ESP does not configure DKIM signing for your domain, or does not align their sending domain with your From address, DMARC fails even though the message is legitimate.

Forwarded email is another major source of failures. When someone forwards your message to another person, the forwarding server becomes the new sender from DMARC's perspective. The SPF check passes for the forwarder's server, but the DKIM signature breaks when the message is modified in transit. DMARC sees the mismatch and reports a failure.

Mailing lists present the same problem. Most mailing list software rewrites the From address or the message body, which breaks DKIM signatures. The mailing list might send your message to hundreds of recipients and generate hundreds of failure reports in a single batch.

Internal email crossing multiple gateways can also generate failures. If your company uses an email security proxy, an archiving solution, or a internal mail relay, each hop can modify headers or routing in ways that cause alignment failures.

How to Tell If a Failure Is a Real Problem

Not every DMARC failure means you are under attack. The key is to look at the failure pattern and the source IP.

A few scattered failures per day from known third-party senders is normal. If you use Salesforce, Office 365, and Google Workspace, you should expect failures for those services unless they are properly configured for DMARC alignment.

A sudden spike in failures is different. If your daily failure count doubles or triples overnight, something changed. A new vendor might have been added, a configuration might have been updated, or an attacker might be testing your domain.

When you see a spike, check the source IPs in the failure report. If the IPs belong to your known vendors or internal servers, the spike is likely a configuration issue. If the IPs belong to unknown servers in unrelated countries, it could be an impersonation attempt.

Here is a practical triage checklist:

1. Small daily failures, consistent sources = normal, no action needed
2. Failures from known third-party senders = check their DMARC configuration
3. Sudden spike in failures = investigate immediately
4. Failures from IPs you do not recognize in countries you do not operate in = possible impersonation attack, investigate
5. Failures for your own subdomains = check subdomain policy and forwarding rules

When to Ignore DMARC Failures

You can safely ignore failures when:

• The source is a known third-party sender with a documented DMARC alignment gap
• The failures are from your own internal mail relays that are being phased out
• The failures are from a mailing list you control that is being migrated to proper DMARC handling
• The volume is low, consistent, and not increasing

You should not ignore failures when:

• The sending infrastructure belongs to a competitor, unknown party, or suspicious IP range
• The failures coincide with a phishing campaign targeting your customers or employees
• Your DMARC policy is set to reject and you are still seeing failures (the reject policy is not being enforced)
• The failures show your domain being used in email header From fields you do not recognize

What to Do When Failures Spike Suddenly

When you see a sudden increase in DMARC failures, work through this sequence:

First, check whether you added any new email sending tools in the past 24 to 48 hours. New marketing tools, CRM integrations, or IT changes often explain sudden changes.

Second, look at the failure sources by IP address. If the failures come from a small number of IPs, you can often identify them by doing a reverse DNS lookup. If they belong to a vendor, contact that vendor about their DMARC configuration.

Third, check your own domain’s DNS records. Did someone accidentally delete or modify your DKIM record? Did your email platform change its DKIM signing domain? Did you migrate to a new email platform and forget to update DMARC?

Fourth, if you cannot explain the spike and the source IPs are unknown, treat it as a potential security incident. Check whether phishing emails claiming to be from your domain have been reported in the past 24 to 48 hours. If they have, your domain is being used in attacks and you may need to tighten your DMARC policy.

How Aggregate Reports Give You the Full Picture

Failure reports are real-time but noisy. Aggregate reports are the opposite. They give you a daily or hourly summary of all DMARC results for your domain across all receivers, without the noise of individual message details.

Aggregate reports tell you:

• What percentage of email claiming to be from your domain passes DMARC
• Which third-party senders are sending the most mail on your behalf
• Which senders are generating the most failures
• How your DMARC policy affects mail delivery over time
• Whether your policy is actually being enforced by receivers

You receive aggregate reports at the rua address specified in your DMARC record. Setting up a dedicated email address or forwarder for aggregate reports is essential. Many organizations have DMARC configured correctly but never receive aggregate reports because the rua address was set to an inbox that no longer exists.

For organizations that receive high volumes of email, tracking these patterns manually becomes unsustainable. A domain sending thousands of messages per day across multiple receivers can accumulate hundreds of failure events in a single hour. Reviewing that data manually means either ignoring most of it or spending significant time parsing reports that were never designed to be human-readable.

DMARCFlow handles this by collecting your aggregate reports and surfacing the information in a structured dashboard. Instead of opening a ZIP file and parsing XML, you see which senders are generating the most failures, which IPs correspond to known vendors versus unknown sources, and when failure volumes spike beyond your normal baseline. This makes the triage process take minutes instead of hours.

For organizations moving from p=none to p=quarantine or p=reject, this visibility is essential. You need to identify which legitimate senders are not yet DMARC-aligned before you enforce a policy that would block their mail. Without that baseline, enforcing DMARC blindly breaks legitimate email.

The practical alternative is to set up a dedicated inbox for aggregate reports and review it weekly. If you have the bandwidth to parse XML manually and track failure trends in a spreadsheet, you can operate without a dedicated tool. For most organizations, that time is better spent elsewhere.

FAQ

Why do I receive DMARC failure notifications for my own domain?

You receive them because your DMARC record requests them. The “rua” parameter in your DMARC record specifies where aggregate reports should be sent. If you see failures in these reports, it means some email claiming to be from your domain failed DMARC checks. This could be legitimate email from misconfigured third-party senders or it could be impersonation attempts.

Should I act on every DMARC failure I see?

No. Not all failures indicate a problem. Third-party senders, mailing lists, and internal relays commonly generate failures that are expected. Pay attention to sudden spikes and failures from IPs you do not recognize. Small, consistent failure volumes from known sources are normal.

Why do legitimate emails fail DMARC even when SPF and DKIM pass?

This happens because of DMARC alignment. SPF and DKIM can both pass for a message, but if the domain in the From address does not match the domain in the Return-Path (SPF) or the DKIM-signing domain, DMARC alignment fails. This is intentional. It prevents attackers from sending email that appears to be from your domain even when they have access to a server authorized to send for a related domain.

How do I stop DMARC failures from legitimate third-party senders?

The fix depends on the sender. Some senders support DKIM signing for your custom domain. If yours does, enable it in your sender’s settings and verify that the DKIM signature uses your domain, not theirs. For senders that do not support custom DKIM signing, you may need to add their sending infrastructure to an SPF include or move to a sender that supports proper DMARC alignment.