DMARC Failures But Email Going Through? What It Means

The Scenario That Confuses Every DMARC Practitioner

You set up DMARC. You are now receiving aggregate reports - XML files from Gmail, Microsoft, and other major receivers - that list every message sent from your domain. You open the report and something looks alarming.

Thousands of failures. But your email is arriving fine.

This is one of the most common reactions to first DMARC reports, and it causes a lot of unnecessary panic. The numbers in your report are not what they seem at first glance.

Here is what is actually happening.

What Your DMARC Aggregate Report Actually Measures

A DMARC aggregate report does not tell you whether email was delivered or rejected. It tells you what happened when receiving servers tried to authenticate email sent from your domain.

Every time a receiver gets a message purporting to be from your domain, it runs SPF and DKIM checks. It then applies your DMARC policy - p=none, p=quarantine, or p=reject - to decide what to do with that message. The receiver then sends you an aggregate report summarizing all of this activity.

The report records every attempt. That includes messages from legitimate senders, forwarding chains, mailing lists, and anything else that touches your domain. The failures you see in the report are auth check failures, not necessarily rejection events.

Authentication vs. Alignment - The Two Axes That Matter

To read a DMARC report correctly, you need to understand two independent checks that receivers run.

Authentication is whether the sending server is authorized to send for your domain. SPF authenticates by checking if the sending server's IP is listed in your domain's SPF record. DKIM authenticates by verifying a cryptographic signature on the message that proves the message was signed by a key you published.

Alignment is whether the domain in the message's From header matches the domain that passed SPF or DKIM. A message can pass SPF or DKIM authentication but still fail DMARC if the From domain does not align. For example, a marketing platform might pass DKIM authentication for its own domain, but the From header shows your domain - that is a misalignment, even though the message authenticated.

DMARC requires at least one of SPF or DKIM to pass AND the alignment to match. Both conditions must be satisfied for a DMARC pass.

Why Failures in Your Report Do Not Mean Rejections

This is the critical part.

A DMARC failure in the report means a receiving server attempted to authenticate the message and one or both of the checks failed, or alignment was not satisfied. Whether the message was actually rejected depends entirely on your DMARC policy.

If your policy is p=none, the receiver accepts the message regardless of the authentication result. Your report will show failures, but the email was delivered anyway.

If your policy is p=quarantine, suspicious messages are quarantined - potentially flagged as spam or held for review.

If your policy is p=reject, messages that fail DMARC are rejected outright.

Most practitioners start at p=none because it is a monitoring-only mode. You see all the traffic without enforcing anything. That is why a report showing 12,650 failures and 179 messages arriving normally is not a contradiction - it is exactly what p=none looks like.

Reading the Counts - A Real Scenario

Consider a practical example. A company sends email through multiple channels: their internal mail server, a marketing platform, a CRM system, and a customer support tool. They publish p=none and review their aggregate report.

They see 12,650 SPF or DKIM failures. They see 179 messages that appear to have passed DMARC. At first, this looks like a catastrophe. Investigation reveals:

The 12,650 failures come from forwarding chains. Alumni forwarding their university newsletter to personal accounts, customers forwarding order confirmations to colleagues. Forwarding breaks SPF because the forwarded message is now being resent from the forwarder's server, not the original sender's. DKIM may also break depending on how the forwarder handles headers.
The 179 messages that went through are direct deliveries from their internal server and their CRM - systems that pass both authentication and alignment cleanly.

This is not a crisis. It is normal mail flow. The failures are known forwarding behavior, not an attack.

Now consider a different scenario: 12,650 failures and zero messages arriving. That would indicate either a policy mismatch or a problem with how your legitimate senders are configured.

The count alone does not tell you whether there is a problem. You have to look at the source of the failures.

A Practical Triage Checklist for DMARC Failures

When you open your DMARC report, work through this checklist in order.

1. Which source IPs are generating the failures?
Look at the source IP field in your report. Are the failing IPs your own servers, or are they external? Your own servers with high failure counts mean a configuration problem. External IPs with your domain in the From header mean someone is sending email pretending to be you - a spoofing attempt, not a configuration error.

2. Are the failures consistent over time or do they spike suddenly?
A sudden spike in failures often means someone added a new sending tool, a platform changed their infrastructure, or a forwarding rule changed. A consistent baseline with occasional noise is usually forwarding-related and expected.

3. Are the failures authentication failures or alignment failures?
This distinction matters. Authentication failures (SPF or DKIM not passing) usually mean the sender is not authorized or the DNS records are wrong. Alignment failures (authentication passes but alignment fails) usually mean a third-party tool is sending on behalf of your domain but the From header is set to your domain - a common setup with marketing CRMs and support platforms.

4. Do the failing sources represent legitimate senders?
List your legitimate senders: your mail server, your marketing platform, your CRM, any internal relays, your internal fax system, your calendar server. If a failing source appears on this list, that is a configuration fix to address. If it does not appear, investigate whether it is spoofing.

5. Are failures concentrated in a specific receiver?
If Gmail shows failures but Microsoft does not, the issue may be Gmail-specific forwarding behavior or differences in how Gmail handles certain sending patterns. Check whether the receiver's filtering rules are creating the discrepancy.

Common Causes of DMARC Auth Failures and How to Fix Them

Third-party senders not authorized in SPF

If you use SendGrid, Mailgun, Amazon SES, or any other platform to send email from your domain, you must add that platform's sending IPs to your SPF record. If you do not, receivers will see SPF failures for those messages.

Fix: Update your SPF record to include the platform's include statement. For example: v=spf1 include:sendgrid.net ~all

Mailing list forwarders breaking alignment

Forwarding is the most common source of DMARC failures that are not actually problems. When a mailing list forwards a message, it typically re-injects it from its own server. SPF fails because the forwarding server is not in the original sender's SPF record. DKIM may also break if the forwarder removes or modifies signed headers.

This is a known limitation of DMARC. Solutions include ARC (Authenticated Received Chain), which preserves the original authentication result through forwarding chains, or moving to a mailing list service that signs with the original domain.

Subdomain misalignment

If your marketing platform sends from marketing.example.com but your From header shows example.com, that is a subdomain alignment issue under relaxed alignment. Under strict alignment, it will always fail. Make sure your sending platform either sends from a subdomain you control and aligned, or signs with your root domain.

Cross-origin sending

A platform sending as sales@example.com when your SPF record only covers smtp.example.com will fail. If you want a third party to send on your behalf with your From domain, you need both SPF authorization and DKIM signing from that domain.

When to Move From p=none to p=reject (And How)

Moving to p=reject is the goal of most DMARC deployments. It means receivers reject any message that fails DMARC - the strongest protection against spoofing. But jumping straight to p=reject from p=none will break legitimate email if you have not audited your senders first.

The process:

Run at p=none long enough to capture all legitimate senders. Two to four weeks is usually sufficient for most organizations with regular sending patterns.
Identify every legitimate source and ensure it is authorized in SPF or DKIM-signed with your domain.
Add any missing senders to your SPF record or require your vendors to DKIM-sign with your domain.
When failures drop to near-zero for your legitimate sources, move to p=quarantine.
Run at p=quarantine long enough to confirm no false positives.
Move to p=reject.

For a detailed walkthrough of this process, see our guide: How to Move From DMARC p=none to p=reject Without Breaking Email.

How to Monitor DMARC Reports Without Manually Reading XML

DMARC aggregate reports arrive as XML. Reading them manually is tedious and error-prone - especially when you are trying to spot patterns across thousands of lines of structured data. Most practitioners who attempt manual review give up within a week and run at p=none indefinitely, which means they never actually enforce DMARC protection.

The alternative is automated parsing and alerting. DMARCFlow processes your aggregate reports as they arrive, normalizes the data, and flags what needs attention. Rather than scrolling through XML trying to spot spikes, you get a structured summary that tells you which source IPs failed, whether the failures are new or expected, and whether any of your legitimate senders have started failing alignment. That turns the report from a document you dread opening into a monitoring feed you can act on.

If you have been staring at your own DMARC reports wondering what the numbers mean, that is a reliable signal you are past the point of manual review.

FAQ

Does a high DMARC failure count mean my email is being rejected?

Not necessarily. If your policy is p=none, receivers accept all mail regardless of authentication result. The failure count tells you what is failing authentication, not what was blocked. A high failure count at p=none is normal and expected - it means your policy is in monitoring mode.

Why does my report show failures but email still arrives?

Because p=none does not enforce anything. The report records what failed authentication. Whether mail was delivered depends on the receiving server's own rules and your DMARC policy. At p=none, everything arrives regardless.

What is the difference between SPF failure and alignment failure?

SPF failure means the sending server is not authorized for the domain per your SPF record. Alignment failure means the From domain does not match the domain that passed SPF or DKIM. Both must pass for DMARC to succeed. A message can have SPF pass but alignment fail, and that counts as a DMARC failure.

How do I stop DMARC failures from my email marketing platform?

Add the platform's sending IPs to your SPF record, and ensure the platform signs email with DKIM keys matching your From domain. Test with a DMARC checker before sending at scale. If the platform cannot DKIM-sign with your domain, you may need to use a dedicated sending subdomain instead.

Should I move to p=reject if I am seeing failures?

Only after auditing and authorizing all legitimate senders. Moving to p=reject prematurely will break legitimate email. Work through the checklist above first. See our guide on moving from p=none to p=reject safely for a step-by-step process.