How to stop secure email gateways from breaking DMARC: ARC, re-signing, and Enhanced Filtering in the right order

Secure email gateways sit in an awkward place in mail flow. They inspect, rewrite, wrap, detonate, banner, and sometimes re-route messages for good security reasons. But those same changes are exactly what can make SPF fail, DKIM fail, and then DMARC fail at the final receiver.

That is why admins often end up staring at a message that was legitimate at the source and broken by the time it reached the mailbox platform.

The fix is usually not just "turn on ARC" or "enable Enhanced Filtering" in isolation. The real fix is getting the order of trust right.

Short answer

If mail reaches Microsoft 365 after passing through a secure email gateway or filtering service, the preferred order is usually:

1. Preserve the original message as much as possible.
2. If the gateway must modify mail, have the gateway add a valid ARC set after its modifications.
3. In Microsoft 365, trust only the required ARC sealer domains.
4. If the intermediary does not support usable ARC, configure Enhanced Filtering for Connectors so Microsoft 365 can recover the original source context.
5. Only rely on gateway re-signing when it fits your architecture and downstream receivers will evaluate the new aligned signature the way you expect.

In plain terms: first try to avoid breakage, then preserve evidence of the original authentication, then teach the final receiver how to trust that evidence.

Why secure email gateways break DMARC in the first place

DMARC depends on aligned SPF or aligned DKIM. A gateway commonly disrupts one or both:

• SPF breaks because the final receiver sees the gateway's IP address, not the original sender's IP.
• DKIM breaks when the gateway modifies protected headers, MIME structure, attachments, or the body.
• DMARC then fails because the visible From: domain no longer has an aligned SPF or DKIM pass at the final hop.

Google says this plainly in its forwarding guidance: forwarding and message changes often cause SPF or DKIM failures, so admins should minimize content changes and preserve forwarding context. ARC exists for exactly that kind of indirect flow.

If you want the protocol background first, What is ARC and how does it work? and Why forwarding breaks SPF/DKIM and affects DMARC are the right companion reads.

The order that works in practice

The easiest way to reason about this is to treat every intermediary step as a decision tree.

1. Do not modify the message unless you really need to

This sounds obvious, but it is the highest-value fix.

If the gateway can scan without rewriting the body, changing MIME boundaries, replacing attachments, or prepending banners, do that first. A message that keeps its original DKIM signature intact usually does not need ARC to survive DMARC.

Google's sender documentation explicitly warns that changing body content, MIME boundaries, Subject, or other DKIM-covered headers can break DKIM for forwarded mail.

2. If you must modify, modify first and ARC-seal after

RFC 8617 is very clear on sealing order: message modifications must happen before the intermediary adds its ARC set.

That matters because ARC is not a magic repair tool for a message that was changed after sealing. ARC is the intermediary's signed testimony about what it saw and what happened at that hop.

The healthy sequence is:

1. gateway receives the message
2. gateway checks SPF, DKIM, and DMARC at that point
3. gateway performs any security-driven modifications
4. gateway adds ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal
5. gateway sends the message onward

If the gateway seals too early and then rewrites the message afterward, the ARC chain can fail and you lose the exact evidence you were trying to preserve.

3. Let the final receiver validate ARC in a controlled way

ARC only becomes operationally useful when the next receiver validates the chain and decides that the sealer is trustworthy.

For Microsoft 365, that usually means adding the gateway vendor's ARC sealing domain as a trusted ARC sealer, based on the d= value actually present in ARC-Seal. Microsoft documents that trusted sealers can allow ARC evidence to influence composite authentication, including the familiar compauth=pass reason=130 outcome when ARC overrides a DMARC failure.

That is the part many teams miss: you do not usually add your own domain there. You add the domain that actually seals the ARC set.

For more detail on that trust model, see Trusted ARC sealers in Microsoft 365 and Gmail.

4. Use Enhanced Filtering when the intermediary path hides the real sender

Some gateways do not provide usable ARC. Others are deployed in front of Microsoft 365 in a way that causes Microsoft to see only the gateway as the source of all inbound mail.

That is the scenario for Enhanced Filtering for Connectors in Exchange Online.

Microsoft says Enhanced Filtering preserves original source IP and sender context for supported connector-based routing paths, and can also help Microsoft recover from authentication confusion introduced by the intermediary. In other words, it helps Microsoft look past the connector-facing hop and evaluate the real upstream sender more accurately.

This is especially relevant when:

• your MX points to a non-Microsoft filtering service first
• mail then arrives in Microsoft 365 through an inbound connector
• the gateway changes the message and does not provide trustworthy ARC evidence

Important boundary: Enhanced Filtering is not a universal substitute for ARC. It is Microsoft's receiver-side correction for connector scenarios, not a standards-based chain-of-custody signal for every downstream mailbox provider.

5. Think carefully before depending on gateway re-signing

Re-signing can mean two different things in practice:

• the gateway adds its own DKIM signature with a domain you control
• the gateway re-signs using a vendor-managed or delegated DKIM setup on your behalf

This can help if the original DKIM signature is going to break anyway and the gateway can add a new aligned DKIM signature that survives the rest of the route.

But re-signing is not always the first or best fix.

Why:

• it changes which system becomes responsible for the surviving DKIM pass
• it may complicate troubleshooting when multiple DKIM signatures are present
• it does nothing for SPF alignment by itself
• it helps only if the new signature remains aligned with the visible From: domain and survives later processing

If a gateway re-signs with a domain that is not DMARC-aligned, the message can still fail DMARC. If it re-signs correctly, that can be a valid design, but it should be an intentional architecture choice, not an accidental side effect.

If multiple signatures are already confusing the incident, Multiple DKIM signatures: how receivers evaluate them is a useful refresher.

Recommended order by scenario

Scenario A: gateway in front of Microsoft 365, gateway supports ARC

Recommended order:

1. reduce or eliminate message rewriting where possible
2. ensure the gateway modifies first and ARC-seals after
3. verify the ARC chain is valid in delivered headers
4. add only the required ARC sealer domain to Microsoft 365 trusted sealers
5. test whether the final result shows ARC being used as intended

Typical signs of success in Microsoft 365 headers:

• arc=pass
• oda=1 in ARC-Authentication-Results
• compauth=pass reason=130 in Authentication-Results when DMARC would otherwise have failed

Scenario B: gateway in front of Microsoft 365, gateway does not support ARC

Recommended order:

1. minimize message changes
2. configure the inbound connector correctly
3. enable Enhanced Filtering for that connector
4. test on a small recipient scope first
5. remove any old assumptions that the connector IP alone proves sender legitimacy

This is the classic skip-listing use case Microsoft documents.

Scenario C: gateway rewrites mail and also re-signs with your domain

Recommended order:

1. confirm whether the gateway-generated DKIM signature is aligned with From:
2. confirm whether later hops preserve that new signature
3. still prefer ARC for preserving earlier authentication context when mail is indirect
4. in Microsoft 365 connector scenarios, still evaluate whether Enhanced Filtering is needed for source attribution

Re-signing can coexist with ARC. It does not replace the need to preserve hop-by-hop trust information.

The most common ordering mistakes

Turning on trusted ARC sealers before checking who actually seals

Admins often trust the wrong domain. Microsoft says to use the domain in the ARC d= value from real headers. If you trust the wrong domain, ARC will validate but not become trusted in the way you expected.

Expecting ARC to save a message that was modified after sealing

Per RFC 8617, modifications are supposed to happen before sealing. If the chain breaks later, receivers treat failed ARC as effectively unusable.

Using Enhanced Filtering for the wrong topology

Microsoft documents Enhanced Filtering for cases where mail is routed through a non-Microsoft service or device before Microsoft 365. It is not meant as a blanket fix for every mail path, and Microsoft explicitly warns about unsupported routing patterns that can distort filtering.

Assuming re-signing automatically fixes DMARC

Only an aligned SPF or aligned DKIM result helps DMARC. A replacement DKIM signature from the wrong domain, or one that later breaks again, does not solve the problem.

A quick header-reading workflow

When a gateway seems to be breaking DMARC, check headers in this order:

1. read final Authentication-Results
2. note spf=, dkim=, dmarc=, and in Microsoft 365 also compauth= and reason=
3. inspect ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal
4. verify whether the latest ARC chain status is cv=pass or cv=none/pass in the expected order
5. identify the ARC sealing domain from d=
6. compare the visible From: domain with any surviving DKIM header.d= values
7. if mail enters Microsoft 365 through a connector, verify whether Enhanced Filtering is configured for the actual intermediary IP path

That workflow usually tells you whether the real problem is:

• unnecessary message modification
• invalid or untrusted ARC
• missing Enhanced Filtering in a connector topology
• misaligned gateway re-signing

Practical rollout advice

Use a small, controlled test set before changing the full production path.

1. Capture a known-good direct message.
2. Send the same kind of traffic through the gateway path.
3. Compare headers before and after the gateway hop.
4. Turn on one corrective control at a time: reduced rewriting, ARC trust, or Enhanced Filtering.
5. Re-test and keep the header evidence.

That sequence keeps teams from enabling three overlapping fixes at once and then not knowing which one actually solved the issue.

Bottom line

Secure email gateways break DMARC when they change the message or obscure the original sending path without preserving trustworthy context.

The right order is usually simple:

• avoid rewriting when possible
• if rewriting is necessary, rewrite first and ARC-seal after
• make the final receiver trust only the specific ARC sealer you actually use
• use Enhanced Filtering for Microsoft 365 connector topologies that hide the true upstream sender
• use re-signing deliberately, not as a guess

When those pieces are applied in the right order, the gateway can keep doing its security job without making legitimate mail look spoofed.