Blog · Dmarc
Why DMARC Fails for Legitimate Mail Even When SPF and DKIM Both Pass
You enabled DMARC. You set it to p=reject. Your SPF record passes. Your DKIM signature verifies. And legitimate mail is still being rejected.
This is one of the most common DMARC problems administrators run into, and the root cause is almost always the same: alignment failure. SPF and DKIM can both pass authentication, but DMARC requires more than that. It requires that the domains used in SPF and DKIM alignment match the domain in the From header that recipients see.
This article explains what alignment actually means, why it causes legitimate mail to fail, and how to diagnose the specific cause using your DMARC aggregate reports.
The alignment problem: why SPF pass and DKIM pass are not enough
DMARC has two distinct checks running at the same time. The first is authentication: your mail server runs SPF and DKIM checks against the sending infrastructure. The second is alignment: those authentication results are then checked against the From header domain that appears in the message.
The From header is what recipients see in their email client. It is what matters to humans. DMARC exists to make sure the domain that authenticated the message also matches the domain that recipients see.
For SPF, alignment means the domain in the RFC5321 Mail From (the envelope sender) must match the domain in the RFC5322 From header. For DKIM, alignment means the domain that signed the message must match the From header domain. DMARC passes if either SPF or DKIM passes and aligns with the From domain. If neither aligns, DMARC fails regardless of individual authentication results.
This distinction is the missing piece in most DMARC troubleshooting.
Why forwarded mail fails DMARC even when SPF and DKIM pass
The clearest example is forwarded mail. Consider a message sent from a Gmail account to an external recipient. The original message has a From header showing a Gmail address. If that message is forwarded through an intermediate server, the forwarding server becomes the new RFC5321 Mail From. The From header still shows the original Gmail address, but the envelope sender now points to the forwarding infrastructure.
SPF passes because the forwarding server's IP is authorized by its own SPF record. DKIM may also pass if the forwarding server does not modify the message body. But DMARC alignment fails: the Mail From domain belongs to the forwarding service, not the original Gmail address in the From header.
This is the scenario that generates the "12,650 rejected, 179 went through" pattern that administrators sometimes see in their logs. The messages pass individual authentication checks but fail alignment, and the reject notices flood back to the envelope sender, which is often the forwarding service.
Other common causes of alignment failure
Forwarding is the most common cause, but it is not the only one.
Internal mail relays and transport agents often set their own Mail From domain for delivery, which breaks SPF alignment. The From header shows the user's address, but the envelope is stamped with the relay's internal domain. SPF passes against the relay, but the domain mismatch causes DMARC to fail.
Mailing list servers frequently rewrite the From header or use their own envelope sender, which breaks both SPF and DKIM alignment simultaneously. Many mailing lists still do not support ARC (Authenticated Received Chain), which was designed specifically to handle this.
Safe sender lists and transport rules in Exchange or Outlook can also bypass authentication checks entirely, which means those messages may not receive DMARC evaluation at all, leading to inconsistent behavior where the same message passes sometimes and fails other times depending on which server processes it.
Why you get reject notifications for mail you did not send
When DMARC rejects a message, the reject notification goes to the RFC5321 Mail From address, not the From header address. This is by design in the SMTP protocol, but it confuses administrators who see bounce messages for email they never sent.
The reject notice goes to the Mail From address, not the From header. SMTP bounces follow the envelope, not the visible From address. That is why administrators see reject reports for messages they never sent -- the bounce travels to the monitoring inbox or forwarding service that owns the envelope, not the user whose address appears in the From header.
This is also visible in aggregate reports as a spike in failure volume from specific source IPs, often in patterns that do not match normal user sending behavior.
How to read your DMARC aggregate reports to find the real cause
The aggregate report (ruf=mailto) is where the actual diagnosis happens. The report contains an
For each authentication result, you will see a
If SPF alignment fails, check whether your mail is being relayed through a third party or forwarded. If DKIM alignment fails, check whether your email is being modified in transit by a middleware that strips or changes the DKIM signature.
The specific fields to look for in the report are
Fixing the specific alignment failure
Once the cause is identified from aggregate reports, the fix depends on the scenario.
For forwarded mail, the options include using ARC (Authenticated Received Chain) to preserve the original authentication chain through forwarding hops, adjusting the DMARC policy to apply only to the organizational domain rather than subdomains, or working with the forwarding service to ensure their relay infrastructure preserves authentication results.
For mailing lists, the recommended path is enabling ARC on the mailing list server, adding a List-ID header to help receiving servers identify legitimate mailing list traffic, and avoiding From header rewriting where possible.
For internal relay scenarios, the fix is aligning the Mail From domain used by the relay with the From header domain, either by configuring the relay to use the corporate domain in the envelope or by ensuring the relay's SPF record covers the organizational domain properly.
For safe sender list overrides in Exchange, the practical next step is auditing which transport rules and safe sender entries bypass authentication entirely, since those create gaps in DMARC enforcement that are hard to diagnose without looking at the rule set directly.
A practical tool for ongoing alignment monitoring
Aggregate reports are generated by the receiving side, which means you only get data about messages that reached a DMARC-enabled receiver. For ongoing monitoring of your own outbound alignment, the practical option is using a service that collects and parses your own DMARC reports.
DMARCFlow automates the collection and parsing of DMARC aggregate reports and presents alignment failure patterns in a domain-by-domain view. This makes it faster to identify which domains are generating alignment failures, which source IPs are involved, and whether the pattern matches forwarding, relay, or mailing list behavior.
For administrators managing multiple domains or a high volume of email traffic, automated report collection turns the raw XML data into something you can review regularly rather than only when something breaks.
DMARCFlow automates aggregate report collection across all your domains and flags alignment failures with per-domain, per-source-IP breakdowns. Rather than parsing XML from individual receivers, you get a structured view of which domains are generating alignment failures, which source IPs are involved, and whether the pattern matches forwarding, relay, or mailing list behavior.
Summary
The "SPF pass, DKIM pass, DMARC fail" problem is almost always an alignment issue. DMARC checks not just whether SPF and DKIM pass, but whether the domains used in those checks match the From header domain. When they do not match, messages fail DMARC even though authentication itself succeeded.
Forwarding, internal relays, and mailing lists are the most common sources of alignment failure. The bounce notifications that follow go to the envelope sender, which is why administrators often see reject reports for mail they did not send.
Aggregate reports show which authentication and alignment checks are passing or failing for each message source. Once you know whether the failure is in SPF alignment, DKIM alignment, or both, the fix follows from the cause.
Alignment failures are a structural feature of how DMARC works, not a sign your authentication is broken. The right response is diagnosing the cause from aggregate reports and applying the fix that matches the scenario: ARC for forwarding, List-ID for mailing lists, Mail From alignment for internal relay, or transport rule review for safe-sender overrides. Ongoing automated collection makes that diagnostic cycle fast enough to run regularly instead of only in response to a spike in reject notices.