Why email forwarding breaks SPF and DMARC, and how ARC helps

Forwarding is one of the most common reasons legitimate mail fails authentication. A message that passed SPF, DKIM and DMARC when it left the sender can fail all three after one hop through an alias, a mailing list or a security service. This guide explains why, what DMARC does with the result, and which fixes work.

Why does forwarding break SPF?

SPF (RFC 7208) checks one thing: is the server connecting to me listed in the SPF record of the envelope sender's domain? The envelope sender is the MAIL FROM address, sometimes called the Return-Path.

Forwarding changes the connecting server but not, by default, the envelope sender:

1. alice@sender.example sends to bob@alias.example. Sender's server is in sender.example's SPF. SPF passes.
2. alias.example forwards the message to bob@mailbox.example, keeping MAIL FROM as alice@sender.example.
3. mailbox.example sees a connection from alias.example's server and checks sender.example's SPF. That server isn't listed. SPF fails.

Nothing is wrong with anyone's records. SPF simply can't describe "mail relayed by someone I've never heard of". RFC 7208 Appendix D lists options at each stage, including the forwarder rewriting MAIL FROM to its own domain, or the receiver choosing to trust known forwarders.

Why do mailing lists break DKIM too?

DKIM signs the message body and selected headers. Any change to those parts invalidates the signature. Plain forwarding usually leaves the message alone, so DKIM often survives. RFC 9989 says DKIM signatures "will generally remain valid in these relay situations".

Mailing lists and some intermediaries do change the message. RFC 7960, which documents DMARC's problems with indirect mail, lists typical edits:

• Adding a tag such as [club-list] to the subject.
• Adding a footer with unsubscribe or list details.
• Re-encoding or converting the body.
• Security services adding warning text or rewriting links.

Google's forwarding guidance gives a similar list of changes that cause forwarded mail to fail DKIM, including modifying the subject, the body, the MIME boundaries, and DKIM-signed headers such as To, Cc, Date and Message-ID.

How does DMARC treat forwarded mail?

DMARC passes when either SPF or DKIM passes for a domain that aligns with the visible From address. Forwarding almost always loses SPF alignment, so DMARC then depends entirely on DKIM. If the sender didn't sign, or a list broke the signature, DMARC fails, and a sender's p=reject policy can get the message rejected. Forwarding is only one cause; why DMARC fails covers the others.

RFC 9989 is direct about this. In section 7.4 it says domains that publish p=reject "MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages". It also says domains whose users post to mailing lists should not publish p=reject without first checking the impact in their reports.

It tells receivers to be careful too: they "MUST NOT reject incoming messages solely on the basis of a 'p=reject' policy", and must weigh the policy alongside other knowledge and analysis. But the RFC admits that in practice few receivers do this, and list mail with an unmodified From line "is frequently rejected".

That's why most mailing list software now rewrites the From address to the list's own domain, or to a form like bob=example.com@list.example, so the message aligns with the list's domain instead of yours.

What is SRS and does it fix DMARC?

The Sender Rewriting Scheme (SRS) is the "rewrite MAIL FROM" option from RFC 7208. The forwarder replaces the envelope sender with an address in its own domain, which encodes the original sender so bounces can still be routed back.

Microsoft 365 does this automatically. Microsoft Learn says SRS rewrites the MAIL FROM of messages autoforwarded to external recipients through mailbox forwarding, inbox rules, mail flow rule redirects, groups with external members, and mail contact or mail user forwarding. A forwarded message gets an envelope sender like:

john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com

SPF is now checked against the forwarder's domain and can pass. But the visible From address is unchanged, so SPF no longer aligns. Microsoft is explicit: SRS "doesn't resolve the issue of forwarded messages not passing DMARC checks". The only reliable route, it says, is a DKIM signature using the From domain that stays intact until final delivery.

Google gives the same advice to anyone forwarding into Gmail: change the envelope sender to reference your forwarding domain, and always set up DKIM alongside SPF (Gmail Help).

What is ARC and how do receivers use it?

ARC, the Authenticated Received Chain (RFC 8617), lets each intermediary record what authentication results it saw and seal that record with its own signature. It adds three headers:

• ARC-Authentication-Results: the SPF, DKIM and DMARC results the intermediary saw.
• ARC-Message-Signature: a DKIM-style signature over the message as the intermediary passed it on.
• ARC-Seal: a signature over the ARC headers, with a chain status cv=none, pass or fail.

If a later hop breaks DKIM, the final receiver can still see that the message passed when the list or forwarder received it, and who vouches for that.

ARC doesn't force anyone to accept anything. RFC 8617 is an Experimental RFC, and it states plainly that "ARC is not a trust framework". Each receiver decides which sealers to believe. Google's ARC page adds that ARC doesn't evaluate reputation and can't stop a forwarder from adding harmful content or stripping ARC headers. RFC 9989 also notes that as of its publication in May 2026, none of the proposed fixes for mailing lists, ARC included, had become widely used.

Trusted ARC sealers in Microsoft 365

Microsoft 365 lets you tell it which sealers to trust. Microsoft says to use this only when a legitimate service regularly modifies inbound mail and causes authentication failures (Microsoft Learn). To set it up:

1. Send a test message through the intermediary to a Microsoft 365 mailbox.
2. Open the headers, find ARC-Seal: and note the d= value. That's the sealer's domain, not yours.
3. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings > ARC, select Add, and enter that domain.
4. Or, in Exchange Online PowerShell, run Get-ArcConfig, then Set-ArcConfig -Identity Default -ArcTrustedSealers "sealer1.example","sealer2.example". This replaces the list, so include existing entries.
5. Allow up to 30 minutes, then check a new message. In the last ARC-Authentication-Results header, look for arc=pass and oda=1. In Authentication-Results, compauth=pass reason=130 means ARC overrode a DMARC failure.

Microsoft warns that each trusted sealer widens your attack surface, and that ARC overrides DMARC failures only. Spam filtering, bulk filtering and your own rules still apply.

Gmail and ARC

Google documents ARC in its Workspace help, but we found no admin setting for trusted sealers and no public description of which sealers Gmail trusts. Don't plan on configuring ARC trust in Google Workspace. Focus on DKIM and on Google's forwarding practices instead.

How do you fix forwarding failures?

Your fix depends on which side you're on.

If you send mail:

1. Sign everything with DKIM using your own domain. This is the fix that survives simple forwarding. See DKIM setup for Microsoft 365 and Google Workspace, and verify with the DKIM Checker.
2. Check your aggregate reports for forwarders. Rows where SPF fails but DKIM passes are usually forwarding, and they're fine. Rows where both fail from list servers show where p=reject will hurt.
3. Roll out enforcement in stages. RFC 9989 suggests at least a month at p=none, then an equal period at p=quarantine, before p=reject on domains whose users post to lists. Our p=none to p=reject guide covers the steps.

If you forward or run a list:

1. Don't modify messages you forward. Leave the subject, body and signed headers alone.
2. Rewrite the envelope sender (SRS), and make sure your SPF covers your forwarding servers.
3. Rewrite From on list posts from domains with p=quarantine or p=reject, if your list software supports it.
4. Add ARC seals if your software supports them.

If you receive mail through a gateway or forwarder:

1. If a filtering service sits in front of Microsoft 365, configure Enhanced Filtering for Connectors so Microsoft sees the original sending IP. Microsoft lists this as an option when a service doesn't ARC-seal.
2. If the service does ARC-seal, add its sealing domain as a trusted ARC sealer.
3. Avoid broad allow lists. An allow entry for a whole forwarding service lets spoofed mail through too.

How to tell if forwarding caused a failure

Open the message headers in the Email Header Analyzer and look for:

• spf=fail or spf=softfail with a connecting IP that belongs to a forwarder or list, not the sender.
• dkim=fail (body hash did not verify), which points to body changes such as a footer.
• ARC-Seal headers, with cv= values showing where the chain broke.
• An envelope sender containing +SRS=, which shows Microsoft 365 applied SRS.

Our guide on how to read email headers explains each field.

Next steps

1. Confirm DKIM is set up for every service that sends as your domain.
2. Check your DMARC record with the DMARC Checker and look at a week of reports for forwarded traffic.
3. If you run Microsoft 365 behind a filtering service, check whether it ARC-seals, and add it as a trusted sealer or use Enhanced Filtering.
4. Read how DMARC applies to subdomains before you enforce, so you know which policy covers which mail.

If you use iBlockSpam for inbound filtering in front of Microsoft 365, the guided setup walks you through the inbound connector and Enhanced Filtering for Connectors.

Browse our other SPF, DKIM and DMARC guides.