Why DMARC passes at one provider and fails at another (receiver-local filtering, composite auth, and policy interpretation)

Yes, this really happens.

A message can leave the sender with one clean-looking authentication story, then land at Provider A with a DMARC pass and at Provider B with a DMARC fail, or with the same DMARC result but a very different final disposition. That is not necessarily evidence that one receiver is broken.

It usually means one of three things:

• the message changed in transit and different receivers evaluated different evidence
• the receivers used different local policy after evaluating DMARC
• one receiver combined DMARC with other signals such as ARC, spoofing heuristics, or composite authentication

The important point is that DMARC is not a universal promise of identical outcomes across mailbox providers. It is an input into receiver decision-making.

Start with the part DMARC standardizes

In RFC 7489, a message passes DMARC when at least one aligned authentication path succeeds:

• SPF passes and the authenticated 5321.MailFrom aligns with 5322.From
• DKIM passes and the signing d= domain aligns with 5322.From

That core rule is shared.

So if the exact same message, with the exact same headers and body, reached two receivers and both implemented DMARC strictly from first principles, the raw DMARC result should normally match.

What varies is everything around that narrow statement.

The first source of variation: receivers are allowed to apply local policy

This is not a loophole. It is built into the design.

RFC 7489 says receivers should make a best-effort attempt to follow the domain owner's published policy, but they may deviate from it because real mail flows are messy. Forwarding, mailing lists, security gateways, and other indirect paths can all interfere with the neat sender-to-recipient model.

That means:

• a sender publishing p=reject is making a request to receivers
• receivers often honor that request
• receivers are still free to apply additional local logic before deciding whether to reject, junk, or accept the message

If this part feels surprising, DMARC policy modes explained is the companion refresher.

The second source of variation: the message may not arrive in the same state

This is the most common reason admins think DMARC is "inconsistent."

DMARC depends on SPF and DKIM outcomes at the receiving side. If an intermediary changes the message path or contents, one receiver may see a still-valid DKIM signature while another sees a broken one. Or one receiver may be evaluating the original delivery path while another is evaluating a forward.

Typical examples:

• a forwarding service changes the envelope path, breaking SPF alignment
• a mailing list adds a footer or subject tag, breaking DKIM
• a security gateway sits in front of the final mailbox provider and rewrites content or alters routing
• one receiver gets direct mail, while another gets the same mail after a forward or alias hop

This is why DMARC and forwarding/mailing lists remains one of the most important "why does this fail there but not here?" topics.

A concrete example

Suppose a message starts like this:

• From: billing@example.com
• SPF passes for bounce.example.com
• DKIM passes with d=example.com

At Receiver A, the message arrives directly. DKIM is intact, so DMARC passes.

At Receiver B, the message arrives through an intermediary that appends a footer and rewraps MIME structure. DKIM no longer verifies. The forwarder also changed the SMTP path, so SPF is no longer aligned. Now DMARC fails.

The sender did not change.

The published DMARC record did not change.

What changed was the message's journey.

The third source of variation: ARC can influence receiver behavior

This is where many side-by-side provider tests get confusing.

In RFC 8617, ARC lets an intermediary preserve its earlier authentication assessment for downstream receivers. That does not mean ARC replaces DMARC, SPF, or DKIM. It means a receiver can use trusted ARC evidence as part of local policy when a legitimate message was modified in transit.

In other words:

• DMARC may fail at final receipt
• ARC may still tell the receiver that an upstream trusted handler saw the message authenticate correctly before the modification
• the receiver may then choose a more lenient local outcome

That is one reason a forwarded message can appear to be "saved" at one provider and still fail harshly at another.

Not all receivers trust the same sealers, and not all receivers give ARC the same operational weight. For background, see Trusted ARC sealers at mailbox providers and ARC security model for admins.

Composite authentication makes this even more visible in Microsoft 365

Microsoft 365 is a good example of why admins should not look at DMARC in isolation.

Microsoft's current documentation explains that inbound decisions can depend on anti-phishing settings, whether Microsoft honors the sender's DMARC policy, spoof intelligence, and composite authentication signals in addition to the raw DMARC result. In practice, you can see headers where dmarc=fail is present but the overall handling reflects a broader assessment rather than a simple yes/no DMARC gate.

That does not mean DMARC passed secretly. It means Microsoft used more than DMARC to decide what to do next.

This distinction matters a lot in troubleshooting:

• dmarc=fail tells you the RFC 7489 alignment test failed
• the final delivery outcome tells you what the receiver decided to do with that failure
• those are related, but they are not identical pieces of information

Gmail also applies broader receiver-side filtering

Google's sender guidance makes the same general point from the other direction: authenticated mail is required, but successful authentication alone does not guarantee inbox placement or identical treatment. Gmail also evaluates spam rate, domain and IP reputation, RFC 5322 formatting, and other sender quality signals.

So even when two receivers agree that DMARC passed, one may still junk or throttle the message while another accepts it normally.

That is not a DMARC disagreement. It is a filtering-policy difference.

A subtle but important distinction: DMARC result versus message disposition

People often say "Provider A passed DMARC and Provider B failed DMARC" when the evidence actually shows something narrower:

• Provider A accepted the message into the inbox
• Provider B sent it to spam or rejected it

Those are delivery outcomes, not automatically DMARC outcomes.

Always separate these questions:

1. Did SPF pass?
2. Did DKIM pass?
3. Did one of them align with the From domain?
4. What DMARC result was recorded?
5. What final action did the receiver take?

Only after that should you ask why the action differed.

What to look for in headers

The fastest way to debug this class of issue is to compare the Authentication-Results headers from both destinations.

Check for differences in:

• spf= result
• smtp.mailfrom= domain
• dkim= result
• header.d= domain
• dmarc= result and action
• ARC-related fields such as arc=, cv=, i=, d=, and s=
• composite-auth or anti-spoof indicators if the receiver adds them

If one provider shows DKIM pass and the other shows DKIM fail, that is usually the whole story.

If both show dmarc=fail, but one still delivers, then you are looking at a local-policy or composite-auth difference rather than a disagreement about the DMARC calculation.

For a line-by-line walkthrough, use DMARC troubleshooting with real headers and ARC headers in practice.

A realistic comparison pattern

Here is a pattern admins see often:

Provider A

• spf=fail
• dkim=fail
• dmarc=fail
• ARC chain from a trusted intermediary validates
• receiver accepts or junks the message instead of rejecting it outright

Provider B

• spf=fail
• dkim=fail
• dmarc=fail
• ARC absent, invalid, or not trusted
• receiver follows the sender's p=reject request more strictly

From the sender's point of view, this looks like DMARC passed at one provider and failed at another.

From the receiver's point of view, both saw DMARC fail. They simply made different decisions after that failure.

Another realistic pattern: one receiver got direct mail, the other got forwarded mail

This is even simpler.

Provider A

• mail received directly from the sender
• DKIM still valid
• DMARC passes

Provider B

• recipient mailbox forwards through another system first
• SPF alignment breaks on forward
• DKIM breaks due to message modification
• DMARC fails

In this case the receivers are not disagreeing at all. They are evaluating different final messages.

What domain owners should take from this

Do not build a mental model where DMARC is a single universal verdict that every mailbox provider must implement the same way.

The safer model is:

• DMARC defines an aligned-authentication test
• the domain owner publishes a requested policy
• receivers combine that with their own trust, anti-abuse, and delivery logic
• intermediaries can change the evidence seen by downstream receivers

That model explains most apparent contradictions.

How to reduce cross-provider surprises

You cannot force identical receiver behavior, but you can reduce the reasons for divergence.

Focus on these:

1. Make aligned DKIM the default for every important sender.
2. Keep SPF accurate, but do not rely on SPF alone for mail that might be forwarded.
3. Move third-party or higher-risk traffic to dedicated subdomains.
4. Review DMARC aggregate reports for sources that only fail at certain receivers or paths.
5. Test direct delivery and forwarded delivery separately.
6. If a trusted intermediary is part of the path, understand whether the destination provider uses ARC meaningfully.

This is one reason Transactional vs marketing email separation and Return-Path vs From: practical implications matter in real operations, not just theory.

The shortest troubleshooting checklist

When someone says, "It passes at Google but fails at Microsoft," or the reverse, verify these in order:

1. Was the message delivered directly in both cases, or was one path forwarded?
2. Do both copies show the same From domain?
3. Do both copies show the same smtp.mailfrom= and header.d= values?
4. Did DKIM survive at both destinations?
5. Is ARC present, valid, and from a sealer that the receiver is likely to trust?
6. Is the difference in the DMARC result itself, or only in the receiver's action after DMARC?

That checklist prevents a lot of wasted time.

Bottom line

When DMARC seems to pass at one provider and fail at another, the real explanation is usually not that DMARC is random.

It is usually one of these:

• the messages were not actually identical by the time each receiver evaluated them
• both receivers saw the same DMARC failure but applied different local policy
• one receiver used ARC, spoof intelligence, or composite authentication to soften the final outcome

Treat DMARC as a standards-based authentication decision inside a larger receiver policy engine, and these cross-provider results become much easier to explain.