Why Forwarding Breaks DMARC — and How ARC Fixes It

Why does forwarding break DMARC? Because forwarding changes two things email authentication depends on: the server the message arrives from, and the exact content that was signed. A message that passed SPF, DKIM and DMARC at its origin can reach the final mailbox failing all three — not because anyone tampered with it, but because the forwarder relayed it from a new IP and, often, edited it on the way.

This post explains both halves of the problem — why SPF and DKIM break when mail is forwarded or sent through a mailing list — and how the Authenticated Received Chain (ARC) lets a receiver honour the original result. It also covers how a receiving organisation configures trusted ARC sealers for its own gateway, using Microsoft 365 as the worked example.

The two things forwarding changes#

DMARC only passes when a message has at least one method — SPF or DKIM — that both passes and aligns with the domain shown in the visible From address. The current DMARC standard, RFC 9989 (2026, which replaced RFC 7489), keeps that core rule. Forwarding undermines both methods at once.

SPF checks the IP that connected against the list of servers the From domain authorized. A forwarder connects from its own IP, which that list never included. So SPF either fails outright, or — if the forwarder rewrites the return-path to its own domain — passes for the wrong domain and no longer aligns. Either way, DMARC gets no aligned SPF pass.

DKIM signs a hash of the body plus selected headers. Plain forwarding that changes nothing can leave that signature intact, which is why some forwarded mail still passes. But mailing lists and many gateways add a footer, prepend a subject tag, or rewrite MIME parts — and any change to the signed content voids the signature. RFC 7960 documents exactly these indirect-mail-flow failures.

What ARC actually does#

ARC — the Authenticated Received Chain, defined in RFC 8617 (July 2019) — preserves the authentication result from before the message was forwarded. It is published as an Experimental standard, but it is widely deployed by major receivers including Google and Microsoft. Each ARC-participating hop records what it saw and signs that record, so the chain of custody survives the parts of the message that don't.

Every hop adds a set of three headers, tied together by an instance number (i=1, i=2, and so on). A single message can carry up to 50 sets, processed in order.

• ARC-Authentication-Results (AAR): records the SPF, DKIM and DMARC results the hop observed when it received the message.
• ARC-Message-Signature (AMS): signs the message as that hop received it, much like a DKIM signature, so later modification is detectable.
• ARC-Seal (AS): signs the AAR and AMS of the chain so far, binding the whole record together. Its cv= value tells a later receiver whether the chain is still valid.

Before you start#

ARC only helps when two things are true: the intermediary breaking your mail actually adds ARC seals, and the receiver is configured to trust that sealer. On the receiving side, Microsoft 365 exposes an explicit trusted-sealer list; the steps below use it as the example.

• Identify the intermediary — the forwarder, mailing list or security gateway that sits between the sender and the mailbox.
• Confirm it seals — open a delivered message's headers and search for an ARC-Seal line. No ARC-Seal means ARC cannot help; ask the vendor to enable ARC signing.
• Find the sealer's domain — read the d= value in the ARC-Seal and ARC-Message-Signature headers. This is the vendor's signing domain, not your own.
• Check your admin role — in Microsoft 365 you need Organization Management, or the Defender email-authentication permission.

Steps: trust an ARC sealer in Microsoft 365#

1. 1

   Reproduce the failure

   Send a test message through the service to a Microsoft 365 mailbox, open the internet headers, and confirm SPF, DKIM and DMARC are failing while an ARC-Seal header is present.

2. 2

   Read the d= value

   In the ARC-Seal and ARC-Message-Signature headers, note the d= domain (for example, pphosted.com). The Message Header Analyzer at mha.azurewebsites.net makes this easier.

3. 3

   Add it in the Defender portal

   Go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > the ARC tab, select Add, enter the signing domain, and Save. The direct link is security.microsoft.com/authentication.

4. 4

   Or use PowerShell

   Run Set-ArcConfig -Identity Default -ArcTrustedSealers 'vendor.com'. The parameter replaces the whole list, so include any sealers you already trust in the same command.

5. 5

   Verify

   Wait up to 30 minutes, then send a fresh test. In the last ARC-Authentication-Results header look for arc=pass and oda=1; in Authentication-Results, compauth=pass reason=130 confirms ARC overrode the DMARC failure.

Platform differences#

Not every receiver gives you a knob to turn. The trusted-sealer control below is Microsoft's; other receivers evaluate ARC differently. All of this is accurate as of August 2026 — verify against each vendor's live documentation before you rely on it.

Reading the flow#

The routing itself is the whole story. A message leaves the origin passing SPF and DKIM; the forwarder relays it from a new IP and edits it, so both fail; and if that forwarder sealed the message with ARC and the receiver trusts the seal, the original passing result is carried across the hop and honoured.

What to do when it doesn't work#

Most ARC problems show up in the message headers. Read the last ARC-Authentication-Results and Authentication-Results lines, then match the symptom below.

The last row is the one that trips people up. A trusted ARC seal can override an authentication failure, but it does nothing about a message a content check judges to be junk on its own merits. Those are two separate decisions, and ARC only touches the first.

A faster way to handle mail that authentication mishandles#

Configuring trusted ARC sealers fixes the authentication verdict, but it lives on the receiving organisation's gateway and does nothing for you as an individual reader. The everyday symptom of forwarding breakage is different: a genuine mailing-list message or a forwarded alias that failed DMARC gets quietly dropped into a junk folder, and you never see it.

That reader-side problem is where a mail client can help. AI Emaily judges incoming mail on its content and sender behaviour across Gmail, Outlook and IMAP accounts — not on a single authentication verdict — so a real list message that failed DMARC because a forwarder edited it is less likely to be buried. Its spam protection is one signal among several, and you can correct it. It does not change what your sending domain or the receiver's gateway does with SPF, DKIM, DMARC or ARC — that stays with your mail provider. We build AI Emaily.