Email authentication
Email Forwarding and DMARC: Why SPF Breaks and DKIM Usually Survives
TL;DR: email forwarding can break DMARC because SPF checks the IP that connects to the receiver, not the IP that originally sent the message. DKIM is the safer alignment path because it survives simple forwarding, but it fails if a forwarder or mailing list modifies the signed message. SRS and ARC help in specific places; they do not make SPF at the forward hop a strategy you should chase.
Why does forwarding break DMARC?
Email forwarding breaks DMARC when the next receiver checks SPF against the forwarder's IP instead of the original sending IP. The original Return-Path usually stays in place, so SPF evaluates the original domain but sees a server that domain never authorized.
In a direct delivery, SPF has a clean question to answer: did the domain in the Return-Path authorize this sending IP? In a forwarded delivery, the next hop is the forwarder. Unless the original domain also listed that forwarder, SPF fails. If the message had no aligned DKIM signature, DMARC fails too.
That is why the durable sender-side fix is not “add every possible forwarder to SPF.” It is to make sure your mail has aligned DKIM before it leaves your platform. For the protocol base, see SPF, DKIM, and DMARC.
Does forwarding break DKIM?
Forwarding does not break DKIM by itself. DKIM survives as long as the signed headers and body stay intact; it fails when the forwarder adds a footer, rewrites the subject, changes MIME boundaries, or otherwise changes signed content.
That is the useful asymmetry: SPF is path-based, while DKIM is content-based. A simple alias or server-side forward changes the connecting IP but not the signed content, so DKIM can still give DMARC an aligned pass. A mailing list footer, subject tag, or security appliance that rewrites the body can invalidate the signature.
If your DMARC reports show forwarding-related failures, look for senders that depend on SPF alignment only. Move those senders to custom-domain DKIM where possible, then monitor the aggregate reports in DMARC monitoring.
What is SRS and does it fix forwarding?
SRS can make SPF pass after forwarding by rewriting the Return-Path to a domain controlled by the forwarder. The honest catch is that SPF then aligns with the forwarder's rewritten domain, not necessarily the visible From: domain you are trying to protect.
Microsoft 365 and Exchange Online use Sender Rewriting Scheme on forwarded mail. Plain aliasing and many on-premise forwarding paths do not. SRS is useful operationally because it helps the forwarder pass SPF for its own rewritten bounce address, but it is not the same as preserving the original sender's SPF alignment.
For platform-specific behavior, see Exchange Online forwarding and SRS and Exchange hybrid forwarding behavior.
Mailing lists, ARC, and the honest mitigation
ARC helps receivers trust authentication results from earlier hops when a mailing list or forwarder changes the message later. It is a mitigation, not a sender-side DMARC pass: receivers still choose whether to trust the ARC chain.
Mailing lists are harder than simple forwarding because they commonly change the message: they add footers, prepend subject tags, rewrite Reply-To, or resend under the list domain. Those changes can break DKIM even when ordinary forwarding would not.
Google Workspace validates ARC on inbound mail, which can reduce false failures through trusted intermediaries. It does not remove your responsibility to sign your own outbound mail with aligned DKIM before it reaches the list or forwarder. See the Google Workspace DMARC guide for the Gmail-specific forwarding notes.
What to actually do
- Enable custom-domain DKIM for every legitimate sender that supports it.
- Keep SPF clean for direct mail, but do not try to authorize the internet's forwarders.
- Use SRS when you operate the forwarding service; understand that it changes the alignment domain.
- Treat mailing-list failures as a DKIM/ARC/receiver-trust problem, not an SPF include problem.
- Use aggregate reports to separate real unauthorized senders from forwarding noise.
Do not add the forwarder's IP to your SPF record just because a recipient forwarded your mail. You do not control every forwarding hop, and authorizing random forwarders expands your SPF record without restoring reliable DMARC alignment.
Check whether your domain is ready for forwarded mail
Run a free DMARC check, then use reports to confirm which senders already have aligned DKIM and which ones still depend on SPF-only alignment.
Forwarded-email DMARC FAQ
Why does forwarding break DMARC?
Email forwarding breaks DMARC when the next receiver checks SPF against the forwarder's IP instead of the original sending IP. The original Return-Path usually stays in place, so SPF evaluates the original domain but sees a server that domain never authorized.
Does forwarding break DKIM?
Forwarding does not break DKIM by itself. DKIM survives as long as the signed headers and body stay intact; it fails when the forwarder adds a footer, rewrites the subject, changes MIME boundaries, or otherwise changes signed content.
What is SRS and does it fix forwarding?
SRS can make SPF pass after forwarding by rewriting the Return-Path to a domain controlled by the forwarder. The honest catch is that SPF then aligns with the forwarder's rewritten domain, not necessarily the visible From: domain you are trying to protect.
Should I add the forwarder's IP to my SPF record?
Do not add the forwarder's IP to your SPF record just because a recipient forwarded your mail. You do not control every forwarding hop, and authorizing random forwarders expands your SPF record without restoring reliable DMARC alignment.
Does ARC solve forwarding for mailing lists?
ARC helps receivers trust authentication results from earlier hops when a mailing list or forwarder changes the message later. It is a mitigation, not a sender-side DMARC pass: receivers still choose whether to trust the ARC chain.