Why Your DMARC Report Shows Both Passes and Failures for the Same Domain

If you manage email for a domain that uses DMARC, you have probably opened your first aggregate report and felt a moment of panic. The report says hundreds of emails failed authentication. But your team is not reporting delivery problems. How can both things be true at the same time?

The answer is simpler than it first appears. DMARC does not just check whether email is authenticated. It checks whether the authenticated identity matches the sender domain shown in the email. When those two things do not line up, DMARC fails, even if the underlying authentication checks pass.

Here is a real example from a practitioner who posted their DMARC numbers: out of roughly 13,000 messages, only 179 passed DMARC. The rest failed. The domain was not under attack. The failures came from a combination of forwarding, third-party sending services, and normal mail routing quirks. The passes came from email that happened to use the right From header.

Authentication vs Alignment: The Distinction That Matters

DMARC relies on two separate checks. The first is authentication: SPF verifies that the sending mail server is authorized, and DKIM verifies that the message was signed by the domain's mail system. Both can pass. But DMARC requires a second check called alignment, which asks: does the domain used in authentication match the domain in the email's From header?

When you send an email, there are actually two sender domains at play. The Return-Path (also called the envelope from) tells mail servers where to send bounces and is used for SPF. The From header is what the recipient sees as the sender. For DMARC to pass, the domain in the Return-Path must match the domain in the From header, not just for SPF but for at least one of the authenticated identities.

This distinction matters more than it first seems. Many things can cause alignment to fail even when authentication succeeds.

Why the Same Domain Produces Both Results

There are three broad reasons you might see both passes and failures for the same domain in one report.

Third-party sending services are the most common cause. Marketing email platforms, transactional services like Stripe or Shopify, and customer support tools often send from their own infrastructure. They may pass SPF or DKIM on their own domain, but the From header shows your domain. The domains do not align, so DMARC fails. The email arrives at the recipient, but it did not come from your mail servers.

Forwarded mail breaks alignment. When a message is forwarded, the forwarder's mail server becomes the new Return-Path sender. The original From header stays the same, but the envelope domain now belongs to the forwarder. SPF passes for the forwarder. DKIM may still pass if the original signer used a domain that matches the From header. But because the Return-Path no longer matches the From header, DMARC alignment fails.

Spoofing produces a distinctive pattern. An attacker sending email with your domain in the From header, but using their own mail servers for authentication, will fail DMARC alignment. Their SPF may pass on their own domain, but it will not match your From header. Their DKIM will not be signed with your domain either. The result is authentication passing in isolation but DMARC failing because the identities do not align.

This is exactly why DMARC exists. It catches the gap that SPF and DKIM alone cannot close.

Is a High Failure Rate a Sign of an Attack?

Not necessarily. The composition of failures matters more than the ratio.

Start by checking whether those failures come from your own infrastructure. Log into your mail servers, check your CRM, review any platforms that send email on your behalf. Most legitimate DMARC failures trace back to a short list of sources: a marketing platform you use, a billing service, an internal tool.

If you do not recognize the failing source IPs, that is a stronger signal of spoofing. External IPs with From-header domains that do not match are almost certainly spoofing attempts, not your infrastructure.

Look at the pattern over time. A spike in failures from many different external IPs over a short period is a common signature of a bulk spoofing campaign against your domain. A consistent, low-volume failure rate from a known set of IPs is more likely to be normal mail flow.

How to Investigate DMARC Failures Step by Step

When you see failures in your DMARC report, work through these steps in order.

First, identify the failing source IPs. Your aggregate report breaks down results by source IP. Make a list of the IPs with the most failures.

Second, check each IP against your known sending infrastructure. Your own mail servers, any approved third-party platforms, your CRM or marketing tools. If the IP belongs to a service you use, the failure is expected and can be addressed by improving that service's authentication setup.

Third, for IPs you do not recognize, check the From domains associated with those sources. If the From domain is your domain and the sending IP is external, that is a spoofing attempt.

Fourth, review the pattern over time. One day of unusual failures may be a short campaign. A persistent pattern over weeks suggests an ongoing issue.

To make this practical: DMARCFlow processes your DMARC reports automatically and presents the pass/fail breakdown by source IP alongside the From domains those sources are using. This makes it faster to see whether the IPs sending your domain are services you recognize or unknown addresses running a spoofing campaign. You still do the analysis yourself, but the data is organized for you instead of sitting in raw XML from each receiver.

When to Move from p=none to Enforcement

Moving to p=quarantine or p=reject is safe only after you have resolved your legitimate failure sources. If you enforce DMARC while third-party services are still failing alignment, you may block email you actually want to receive.

The prerequisite is simple: you should understand where your failures come from, and the sources you cannot control should either be fixed or acceptably small in volume.

If forwarding is a major source of failures, be aware that moving to enforcement will affect forwarded mail. Standard forwarding via SMTP does not preserve the original authentication context, so forwarded messages will fail alignment after enforcement is enabled.

FAQ

Can legitimate email fail DMARC?
Yes. Legitimate email fails DMARC when it does not meet alignment requirements, even if SPF and DKIM both pass. This happens with forwarding, third-party sending services, and some internal mail routing configurations.

Should I be worried if failures outnumber passes?
Not necessarily. The composition of failures matters more than the ratio. Check whether the failing IPs belong to services you use or infrastructure you control. Unexpected external IPs with your domain in the From header are a real problem. Known third-party senders causing alignment failures are usually manageable.

How often should I review DMARC reports?
At minimum, review them monthly. Weekly is better if your domain sends high volumes or you are in a security-sensitive sector. The goal is to notice changes in your pass-fail ratio before they become incidents.

Does DMARC failure mean the email was not delivered?
Not necessarily. DMARC failure is a signal, not a guarantee. Receivers decide whether to accept, quarantine, or reject based on their own policies and the DMARC result. Some receivers accept failing mail to spam. Others reject it silently. The failure rate in your report is not a delivery rate.

Why do forwarded emails fail DMARC?
Forwarded emails fail DMARC because the forwarder rewrites the Return-Path to its own domain while keeping the original From header. The domains no longer align, so DMARC fails even though the original message may have been properly authenticated.

Does using a third-party email service mean I will always have DMARC failures?
Not if the service sets up proper authentication. Some third-party platforms can send DKIM-signed email using your domain, which satisfies alignment. Others require configuration changes or may not support it at all. Check with your provider before assuming their sending is aligned by default.