Email forwarding breaks SPF authentication because the forwarding server is not in the original sender's SPF record. Sender Rewriting Scheme (SRS) rewrites the envelope sender to the forwarder's domain so SPF passes, but this breaks DMARC alignment because the From header still shows the original sender. ARC (Authenticated Received Chain) solves the remaining problem by letting trusted forwarders cryptographically vouch for the original authentication result. In production, you need SRS plus ARC plus intact DKIM to reliably deliver forwarded mail in 2026.
If you have ever watched legitimate mail get rejected after being forwarded, sent a perfectly authenticated message to a mailing list and seen it bounce, or set up email forwarding on a hosting provider only to find Gmail puts every forwarded message in spam, the cause is the same: forwarding breaks SPF by design, and the fixes (SRS, ARC, intact DKIM) are subtle enough that most setups get them partially wrong.
This guide explains the underlying mechanics. Once you understand why forwarding breaks authentication, the fixes are easier to evaluate and the production-grade configuration becomes clear.
Why Forwarding Breaks SPF by Design
SPF works by asking: "Is the sending IP address authorized to send mail from this domain?" The receiving server looks up the SPF record for the envelope sender's domain and checks whether the connecting IP is listed.
This model works perfectly for direct sends. Server A at IP 203.0.113.50, listed in example.com's SPF record, sends mail with envelope sender alice@example.com. The receiver looks up example.com's SPF, sees 203.0.113.50, and SPF passes.
Now insert a forwarder. Alice sends a message to bob@university.edu. The university's mail system has a forwarding rule that redirects all of Bob's mail to bob@gmail.com. The university's server at IP 192.0.2.10 re-sends the message to Gmail, preserving the original envelope sender alice@example.com. Gmail looks up example.com's SPF, does not find 192.0.2.10 in the record, and SPF fails.
The university did nothing wrong. Alice did nothing wrong. The mail is entirely legitimate. SPF still fails because the protocol fundamentally cannot accommodate a re-sending hop that is not in the original sender's authorized list. RFC 7208 acknowledges this limitation explicitly: SPF is not designed to survive forwarding.
DMARC Makes the Problem Worse, Not Better
Before DMARC, a failed SPF on a forwarded message was annoying but usually not fatal. The receiver might lower the message's spam score slightly and deliver it anyway. DMARC changed this calculus by making authentication failures actionable: if the sender's DMARC policy is p=quarantine or p=reject, a SPF failure on a forwarded message can lead to the message being silently dropped.
DMARC also adds the alignment requirement: the authenticated domain must match the domain in the visible From header. Even if SPF technically passes (via SRS, covered below), DMARC requires that the SPF-passing domain be the same as (or aligned with) the From domain. After forwarding, these almost never match.
This is why forwarded mail started failing en masse when major providers like Gmail, Yahoo, and Microsoft tightened DMARC enforcement in 2024-2026. The forwarding problem existed for decades; DMARC enforcement turned it from "tolerable annoyance" into "production-breaking failure."
SRS: Rewriting the Envelope to Save SPF
The Sender Rewriting Scheme is the first-generation fix. The idea is simple: when a server forwards a message, it rewrites the envelope sender (the MAIL FROM, also called the return-path) to use the forwarder's own domain. The forwarder's IP is in its own SPF record, so SPF now passes.
SRS in Practice
Without SRS, the forwarded message looks like:
MAIL FROM: alice@example.com
From: alice@example.com
To: bob@gmail.comThe receiver (Gmail) checks SPF against example.com, the forwarder's IP is not in example.com's SPF, and authentication fails.
With SRS, the forwarded message looks like:
MAIL FROM: SRS0=hash=tt=example.com=alice@university.edu
From: alice@example.com
To: bob@gmail.comThe envelope sender now references university.edu (the forwarder's domain), with the original sender encoded into the local part using a special SRS format. The receiver checks SPF against university.edu, the forwarder's IP is in university.edu's SPF record, and SPF passes.
The visible From header is unchanged. The user still sees alice@example.com in their inbox. SRS only rewrites the invisible envelope layer.
Why SRS Encodes the Original Sender
The local part of the SRS-rewritten address is not random. It encodes the original sender so that bounces can be routed back correctly. If bob@gmail.com has been deleted, Gmail will return a bounce to the envelope sender, which is now the SRS address at university.edu. The university's mail server decodes the SRS local part, recovers alice@example.com as the original sender, and forwards the bounce back to Alice.
This requires the forwarder to maintain SRS state long enough to handle bounces. Most implementations include a timestamp in the SRS address and reject decodes older than 30-90 days, balancing bounce handling with abuse prevention.
Why SRS Alone Is Not Enough
SRS fixes SPF authentication. It does not fix DMARC alignment.
DMARC requires that the SPF-authenticated domain match the From header domain in relaxed alignment mode (the organizational domain match) or strict alignment mode (an exact match). After SRS:
- SPF authenticated domain: university.edu (the forwarder)
- From header domain: example.com (the original sender)
These do not align. SPF passes the check but fails the alignment requirement. DMARC therefore fails on the SPF side.
DMARC is satisfied if either SPF OR DKIM passes with alignment. So if the original message had a valid DKIM signature from example.com and that signature survived the forwarding hop intact, DMARC passes via DKIM. This is the standard production pattern: SRS handles SPF, DKIM handles alignment, both must work for the message to survive.
The DKIM survival problem: Many forwarding servers modify messages in ways that break DKIM signatures. Adding [EXTERNAL] to the subject line, appending a footer, rewriting links for security scanning, or transcoding character encoding can all invalidate the DKIM hash. Once DKIM breaks and SPF alignment is broken by SRS, the message fails DMARC entirely.
ARC: The Complete Solution for Forwarded Authentication
The Authenticated Received Chain (RFC 8617) addresses the cases SRS and DKIM survival cannot handle. ARC lets each forwarder cryptographically vouch for the authentication result the message had when it arrived, before any forwarder modifications broke things.
How ARC Works
When a forwarder receives a message, it does three things:
- Evaluates the incoming SPF, DKIM, and DMARC results.
- Writes those results into a new header called
ARC-Authentication-Results. - Signs that header (and the rest of the relevant message state) with the forwarder's own cryptographic signature in an
ARC-Message-Signatureheader, then seals the whole chain with anARC-Sealheader.
The forwarder is essentially telling the next hop: "I received this message and verified that the original authentication was valid. Here is my signature attesting to that fact. If you trust me as a forwarder, you can override DMARC failures caused by my forwarding."
Multiple forwarders can each add their own ARC layer, creating a chain. The final receiver evaluates the chain and decides whether to trust it based on the reputation of the forwarders in the chain.
The ARC Trust Problem
ARC only works if the receiver trusts the sealing forwarder. This trust is established differently at different providers:
- Gmail: Algorithmic. Forwarders earn ARC trust over time based on their behavior. You cannot manually request trust; you build it through consistent good behavior.
- Microsoft 365: Configurable. Administrators can explicitly add domains to a trusted ARC sealers list via PowerShell using
Set-ArcConfig. - Yahoo, Apple, others: Varies. Each provider has its own evaluation logic, and the details are not publicly documented.
The practical implication: if you are a forwarder, your ARC seals only help downstream receivers who recognize you. Major mailing list services and large universities tend to be trusted. Small custom forwarding setups frequently are not, which means ARC adds value but does not guarantee delivery for every forwarded message.
The Production Pattern for Reliable Forwarding
A forwarding setup that reliably survives modern authentication requirements needs all of:
- SRS configured. Rewrites the envelope sender to the forwarder's domain so SPF passes against the forwarder's SPF record.
- DKIM left untouched. The forwarder must not modify the message body or any header included in the DKIM signature. No subject prefixes, no body footers, no link rewriting on signed parts. If the original DKIM signature survives, DMARC passes via DKIM alignment.
- ARC sealing. The forwarder signs the original authentication results so downstream receivers can choose to honor them even if DKIM later breaks.
- Strong forwarder reputation. ARC only helps if downstream receivers trust the forwarder. This is built through volume and good behavior, not configured.
Without all four, forwarded mail will fail at some receivers, particularly Gmail and Microsoft consumer domains where DMARC enforcement is strict.
If you operate a forwarding service, audit every place where the message could be modified. Antivirus scanning that rewrites attachments breaks DKIM. Footer injection breaks DKIM. Link wrapping for security scanning breaks DKIM. Each "feature" your forwarder adds to messages is a DKIM survival risk. Consider scanning without modification, or signing your own DKIM with ARC sealing as a backstop.
Common Forwarding Scenarios and What Actually Works
Simple Mailbox Forwarding
User sets a forward in their mailbox provider (Gmail, Outlook.com) to redirect all incoming mail to another address. Most major providers handle this correctly: they apply SRS, preserve DKIM, and add ARC headers. End users do not need to configure anything. The forwarding "just works" because the provider has invested in compliant infrastructure.
Mailing List Forwarding
A mailing list server receives a message and re-distributes it to subscribers. Mailing lists are notorious for breaking DKIM because they typically modify the subject (adding [list-name] prefixes) and the body (adding footers). Modern mailing list software like Mailman 3 and Sympa support ARC sealing and rewrite the From address to the list's own domain to avoid DMARC failures entirely. Older or custom mailing list setups frequently still break.
Shared Hosting Forwarding
A web host offers email forwarding as part of a domain hosting package. info@yourdomain.com forwards to your real Gmail. This is the most common forwarding scenario and also the most likely to be broken. cPanel's default forwarding does not always apply SRS, frequently does not sign ARC, and rarely preserves DKIM intact. If your hosting provider's forwarding is broken, the fix is to either use a managed forwarding service that handles this correctly or to host a real mailbox at your provider rather than forwarding.
Hybrid Microsoft 365 / On-Premise
Organizations running hybrid Exchange setups route some mail through on-premise servers and some through Microsoft 365. Microsoft enabled SRS automatically for Exchange Online in August 2023 and tightened forwarding rules through 2025-2026. Hybrid setups frequently need explicit SRS configuration on the on-premise side and trusted ARC sealer entries on the M365 side.
How to Test Whether Your Forwarding Survives Authentication
Send a test message through your forwarding setup and inspect the headers at the destination:
- Send from a domain with strict DMARC (
p=reject) through your forwarder to a Gmail address. - If the message arrives in the Gmail inbox, your setup probably works. If it lands in spam or does not arrive at all, authentication is failing somewhere.
- In Gmail, click "Show original" on the message and look at the
Authentication-Results:header. - Check three things: SPF (should pass after SRS), DKIM (should pass if signature survived), and DMARC (should pass via DKIM alignment).
- If ARC headers are present, check the
ARC-Authentication-Resultschain to see what the forwarder vouched for.
If DMARC fails, the failure mode tells you what to fix. SPF fail with DKIM fail means SRS is missing and DKIM was broken by the forwarder. SPF pass with DKIM fail means SRS is working but the forwarder is modifying the message in ways that invalidate DKIM. SPF fail with DKIM pass means SRS is missing but DKIM survived, and DMARC is passing via DKIM alignment despite the SPF failure.
When to Stop Forwarding Entirely
Sometimes the right answer is not "fix forwarding" but "stop forwarding." If you own a domain and want mail sent to it to end up in your real Gmail inbox, hosting a real mailbox at that domain (via Google Workspace, Microsoft 365, Fastmail, or similar) and using IMAP from your Gmail client to read it has none of the forwarding problems. The mail lands in a properly-authenticated mailbox at your domain and never crosses a forwarding hop.
For organizations running custom forwarding for hundreds of users, this transition is non-trivial. For an individual who just wants info@yourdomain.com to reach their inbox, replacing the forwarder with a real mailbox is usually the cleanest fix.
Frequently Asked Questions
Because forwarding breaks SPF authentication by design, and modern Gmail enforces DMARC strictly. When SPF fails and the forwarder modified the message in a way that broke DKIM, DMARC fails entirely and Gmail treats the message as suspicious. The fix requires SRS to handle SPF, intact DKIM signatures, and ideally ARC sealing from a trusted forwarder.
Only partially. SRS fixes SPF authentication by rewriting the envelope sender to the forwarder's domain, but this breaks SPF alignment because the From header still shows the original sender. DMARC then needs to pass via DKIM alignment, which requires the original DKIM signature to survive the forwarding hop intact. If both SPF alignment and DKIM survival fail, DMARC fails.
SRS rewrites the envelope sender to fix SPF authentication after forwarding. ARC adds cryptographic headers that vouch for the original authentication result, so downstream receivers can trust the message even if SPF and DKIM are broken by the forwarder. They solve different parts of the same problem and are used together in production forwarding setups.
Technically yes, but it only works if you control every forwarding hop and the forwarders use a stable, enumerable set of IPs. For a known, fixed forwarder this can work as a simple solution. For arbitrary forwarders (users who set their own mailbox forwards), there is no way to predict the forwarding IPs, so SRS at the forwarder is the only viable answer.
No. ARC only helps if the receiving server trusts the forwarder's ARC seal. Major providers like Gmail use algorithmic trust based on the forwarder's reputation, which means small or new forwarders may not be trusted yet. Microsoft 365 lets administrators explicitly configure trusted ARC sealers. ARC is part of a layered defense, not a complete guarantee on its own.