ARC vs SRS: Which One Fixes Email Forwarding?
Why Email Forwarding Breaks Authentication
Email authentication was designed for direct delivery: sender to recipient, one hop. When a forwarding server sits in the middle, the assumptions break down.
- SPF checks the sending IP against the domain's DNS. When email is forwarded, the IP changes to the forwarder's server, which isn't in the original sender's SPF record. SPF fails.
- DKIM signs the message content. It survives forwarding unless the forwarder modifies headers or body (adding footers, rewriting subjects). If modified, DKIM fails.
- DMARC requires at least one (SPF or DKIM) to pass with domain alignment. If both fail, DMARC fails, and the email hits spam or gets rejected.
Two technologies exist to solve this: SRS and ARC. They take fundamentally different approaches.
What is SRS (Sender Rewriting Scheme)?
SRS rewrites the envelope sender (Return-Path) from the original address to the forwarding domain. Instead of:
Return-Path: [email protected]
The forwarder rewrites it to:
Return-Path: [email protected]
Now when the receiving server checks SPF, it checks forwarder.com's SPF record instead of the original domain's. Since the forwarding server is authorized to send from its own domain, SPF passes.
The receiving server can unwrap the SRS address to find the original sender for bounce handling.
SRS: Pros and Cons
- Simple to implement
- Widely supported across mail servers
- Fixes SPF immediately
- Preserves bounce handling
- Doesn't preserve original authentication chain
- Doesn't help if DKIM breaks
- Original sender domain is no longer the envelope sender
- DMARC alignment may still fail
What is ARC (Authenticated Received Chain)?
ARC takes a completely different approach. Instead of rewriting addresses, it preserves the original authentication results through a chain of cryptographic seals.
Each intermediary (forwarding server) adds three headers with incrementing instance numbers:
- ARC-Authentication-Results (i=N): Records SPF, DKIM, and DMARC results at this hop
- ARC-Message-Signature (i=N): Signs the message content at this hop
- ARC-Seal (i=N): Cryptographically seals the entire chain so far
The final recipient verifies the chain to see that authentication was valid at the origin, even if SPF and DKIM fail at the final hop. You can inspect ARC chains with our ARC Validator.
ARC: Pros and Cons
- Preserves full authentication history
- Works with DMARC alignment
- Trusted by Gmail, Microsoft, Yahoo
- Supports multi-hop forwarding
- Requires key management (DKIM-like keys)
- Not universally supported yet
- More complex to implement
- Trust is based on sealer reputation
Side-by-Side Comparison
| SRS | ARC | |
|---|---|---|
| Fixes SPF | Yes | No (indirectly via chain) |
| Preserves DKIM | N/A | Yes |
| Preserves DMARC | No (changes envelope) | Yes (records original results) |
| Complexity | Low | High |
| Provider support | Universal | Growing (Gmail, Microsoft, Yahoo) |
| Best for | Simple forwarding | Multi-hop forwarding with authentication |
Why You Need Both
SRS fixes the immediate SPF problem. ARC preserves the authentication evidence. Together, they ensure forwarded email passes both SPF (via SRS) and DMARC (via ARC chain).
Using SRS alone means SPF passes, but the receiving server has no evidence the original email was legitimate. Using ARC alone means the authentication chain is preserved, but SPF still fails at the final hop.
This is exactly what ARC-Relay does: SRS rewriting for SPF compliance, plus ARC sealing for authentication chain preservation. The combination provides complete coverage.
How ARC-Relay Implements ARC + SRS
Here's what happens when an email passes through ARC-Relay:
Email arrives at ARC-Relay's SMTP server on port 2525 with STARTTLS encryption
mailauth.authenticate() records the current SPF, DKIM, and DMARC results
ARC seal is added with the correct instance number, cryptographically signing the authentication results and message
Envelope sender is SRS-rewritten to [email protected]
Email is forwarded via Postfix to the final destination
Destination server validates: SRS-rewritten sender passes SPF, ARC chain passes verification
You can verify the results with our ARC Validator, Header Analyzer, and SPF Validator.
Get both ARC and SRS in one relay
ARC-Relay handles ARC sealing and SRS rewriting automatically. No key management, no configuration headaches.
Get Started Free