Email Forwarding Breaks SPF and DKIM

When you forward email through Microsoft 365, SPF and DKIM can fail even when both the original sender and your M365 tenant are configured correctly. The issue is not a misconfiguration on either end. It is a structural problem with how email forwarding works in SMTP.

This guide explains exactly why forwarding breaks authentication after an M365 migration, what your options are for fixing it, and how to monitor for forwarding-related failures before they become a support problem.

Why email forwarding breaks SPF and DKIM after migrating to Microsoft 365

Email forwarding changes the SMTP conversation in a way that breaks the assumptions SPF and DKIM rely on.

Here is the forwarding chain as SMTP sees it:

1. The original sender publishes SPF and DKIM for their domain (example.com)
2. M365 receives the message and delivers it to the mailbox
3. An auto-forward rule or a user redirect sends the message to a new destination (external.com)
4. M365 becomes the new sending server for the forwarded message

SPF validates the connecting server's IP address against the domain in the envelope sender (the Return-Path header). When M365 forwards the message, it is M365's IP address that SPF checks, not the original sender's. If example.com's SPF record does not include M365's IPs, SPF fails.

DKIM works by the original sending server cryptographically signing message headers with a private key. The recipient domain extracts the DKIM signature from the headers, looks up the public key in DNS under the_selector._domainkey.example.com record, and verifies the signature. When M365 forwards the message, it often modifies headers or the message body during transport. This breaks the DKIM signature because DKIM signatures are fragile: any alteration to signed headers invalidates them.

The forwarding server then re-injects the message into SMTP using its own envelope. The original SPF and DKIM results no longer apply to this new SMTP transaction.

This is not a Microsoft 365 bug. It is how email forwarding has always worked. The problem becomes more visible after an M365 migration because organizations that previously used on-premises Exchange with more permissive relay settings are now running fully cloud-based, and forwarding configurations that worked before no longer do.

The first sign of this problem is usually users reporting that forwarded messages are not arriving, or that authentication failures appear in DMARC aggregate reports for IPs that are not your own. DMARCFlow surfaces these forwarding-related alignment failures as a distinct incident type in your aggregate report dashboard, so you can identify which forwarding paths are breaking authentication before users start filing support tickets.

What is SRS and how does it fix email forwarding

SRS (Sender Rewriting Scheme) is a technique specifically designed to fix this problem. It was introduced to solve the forwarded bounce problem but it also preserves SPF validity for forwarded messages.

SRS works by rewriting the envelope sender address when a message is forwarded. Instead of the forwarded message carrying the original sender's address in the Return-Path (which SPF would then validate against the forwarder's IPs), SRS stamps a rewritten address that routes bounces back through the original forwarder while preserving the original sender information.

The rewritten address looks something like this:


original@example.com@forwarder.srs.example.com

When a bounce occurs, the SRS wrapper routes it back to the original forwarder, which reverses the rewrite and sends the bounce to the actual original sender. Meanwhile, SPF validates against the forwarder's domain, which now correctly includes the SRS wrapper domain.

SRS is not built into Exchange Online or Microsoft 365. You need an SRS-capable mail relay or gateway in front of M365 to use it.

How to configure SRS for Microsoft 365

There are two main approaches.

Option 1: SRS-aware email gateway

Route your inbound email through a third-party email gateway that supports SRS before it reaches Exchange Online. Several DMARC and email security vendors offer this:

PowerDMARC offers a hosted email gateway with built-in SRS support
EasyDMARC has similar hosted SMTP relay options
Valimail's hosted platform includes forwarding-aware authentication handling

The setup typically involves pointing your MX records to the vendor's relay instead of directly to M365, letting the relay handle SRS rewriting and then forward clean-authenticated messages to Exchange Online.

This is the most practical option for organizations that do not want to run their own mail proxy.

Option 2: Exchange Online mail flow rules (limited fix)

Exchange Online mail flow rules (also called Transport Rules) can modify message headers and the envelope sender, but they cannot fully implement SRS. The SRS wrapper requires cryptographic mapping between the original sender and the rewritten address, which mail flow rules cannot generate or reverse.

What mail flow rules can do: stamp the Received-SPF header to reflect the original SPF check result, and add custom headers that downstream servers can use for authentication context. This does not fix SPF failures for the forwarding leg, but it can help with DMARC alignment by making the authentication results visible to receiving servers that support header-based alignment.

For most organizations, Option 1 is the correct solution. Option 2 is a partial workaround at best.

Alternative approaches for mailing list forwarding

Mailing lists have a different forwarding problem. When a mailing list server (like Mailman, Google Groups, or ListServe) forwards messages to subscribers, it re-sends them from its own infrastructure, which breaks both SPF and DKIM for the original sender domain.

The modern replacement for mailing list forwarding is List-Unsubscribe. Instead of forwarding messages, the mailing list server sends the message directly to each subscriber using the original sender's domain in the From header, while providing an Unsubscribe header that lets recipients opt out without the list needing to forward anything.

List-Unsolve-Post is a related mechanism that allows mailing lists to receive unsubscribe requests via email rather than only via HTTP. Both are documented in RFC 8058 and are supported by major email providers including Gmail and Microsoft.

If you run a mailing list and are seeing authentication failures, switching to List-Unsubscribe is more reliable than trying to make forwarding work with SRS.

How to monitor for forwarding issues with DMARCFlow

Even after you implement SRS or migrate to List-Unsubscribe, forwarding can still fail in edge cases: misconfigured forwarding rules, vendor SMTP relaying that does not support SRS, or internal auto-forwarding set up by users that bypasses your gateway.

DMARCFlow can detect forwarding-related authentication failures through its aggregate report monitoring. When a forwarded message fails DMARC alignment, the failure appears in your aggregate reports with an indication that the message originated from a forwarding chain. DMARCFlow parses these reports and surfaces forwarding failures as a distinct incident type, so you can identify which forwarding paths are breaking authentication without manually parsing raw report data.

This is useful for catching forwarding problems that your users report rather than discovering them through support tickets.

For Microsoft 365 specifically, you can also use Microsoft Purview Message Center notifications and Exchange Online admin center mail flow reports to monitor for forwarding-related issues, but these do not give you the per-destination authentication breakdown that DMARC aggregate reports provide. DMARCFlow processes your aggregate reports automatically and flags forwarding failures with the source IP and destination domain, so you can trace which forwarding paths are causing problems without parsing raw XML report files.

FAQ

Does Microsoft 365 rewrite SPF and DKIM when forwarding?

No. Exchange Online does not rewrite SPF or DKIM signatures when forwarding messages. The original SPF check result is recorded in headers, but when the message is re-injected for forwarding, SPF validates against the forwarder's IPs. There is no automatic SRS implementation in Exchange Online.

Can I use a mail flow rule to fix SPF for forwarded messages?

Not fully. Mail flow rules can add SPF-related headers and modify the Return-Path address, but they cannot generate the SRS wrapper that makes forwarded SPF validation work correctly. A proper SRS implementation requires a gateway or relay in front of Exchange Online.

What happens to DMARC alignment when a message is forwarded?

DMARC alignment requires the From header domain to match either the SPF domain (SPF alignment) or the DKIM signature domain (DKIM alignment). When M365 forwards a message, the From header still shows the original sender, but the new SMTP transaction has a different envelope sender and connecting IP. If neither the original SPF domain nor DKIM domain aligns with the From header in the new transaction, DMARC alignment fails.

Does enabling forward or redirect rules in Exchange Online fix this?

No. Exchange Online's forward and redirect rules operate at the mailbox level and do not modify the SMTP envelope or provide SRS rewriting. They are the same forwarding mechanism, just exposed through the admin UI rather than through traditional SMTP forwarding.

How do I know if forwarding is breaking authentication for my users?

The clearest signal is a DMARC failure in your aggregate reports where the source IP belongs to a known forwarder or cloud provider that was not authorized in your domain's SPF record. DMARCFlow can surface these automatically. You can also check your Exchange Online admin center mail flow reports for forwarding rule usage.