Why Your Email Forwarder Breaks SPF (and How SRS Fixes It)

You set up email forwarding on your custom domain. SPF, DKIM, and DMARC are all configured correctly. But emails forwarded through your service fail SPF at the destination. What went wrong?

Nothing. This is how SPF works by design. And it is a problem every email forwarding service must solve.

How SPF works (the 30-second version)

SPF (Sender Policy Framework) is a DNS record that lists which servers are allowed to send email for a domain. When Gmail receives an email claiming to be from newsletter@shop.com, it checks shop.com's SPF record to see if the sending server's IP is authorized.

If the IP matches → SPF pass. If not → SPF fail.

Why forwarding breaks it

Here is the problem with forwarding:

1. newsletter@shop.com sends email to you@yourdomain.com
2. Your domain uses Cleanbox (or ImprovMX, or any forwarder) for email forwarding
3. Cleanbox receives the email and forwards it to your Gmail inbox
4. Gmail checks SPF: "Is the Cleanbox server authorized to send email for shop.com?"
5. Answer: No. Cleanbox is not in shop.com's SPF record. SPF fails.

The email is legitimate. The forwarding is legitimate. But SPF fails because the forwarding server is not authorized by the original sender's domain. This is not a bug — SPF was designed to prevent unauthorized servers from sending email for a domain. A forwarding server is, by definition, an unauthorized sender.

What about DKIM?

DKIM (DomainKeys Identified Mail) survives forwarding because it is a cryptographic signature on the email content, not a check on the sending server's IP. As long as the email content is not modified during forwarding, the DKIM signature remains valid.

This is why DKIM alignment is critical for forwarded email. If the original sender signed with DKIM, the forwarded email can still pass DMARC through DKIM alignment even when SPF fails.

Enter SRS: Sender Rewriting Scheme

SRS solves the SPF problem by rewriting the envelope sender (Return-Path) during forwarding. Instead of forwarding the email with the original envelope sender (newsletter@shop.com), the forwarder rewrites it to use its own domain:

Original envelope:  newsletter@shop.com
After SRS:          SRS0=HHH=TT=shop.com=newsletter@cleanbox.to

Now when Gmail checks SPF, it asks: "Is the Cleanbox server authorized to send email for cleanbox.to?" Yes, it is. SPF passes.

The rewritten address encodes the original sender so that bounces can be routed back correctly. The format includes a hash (HHH) for validation and a timestamp (TT) for expiration.

What SRS does NOT change

• From header — The visible "From" address stays the same. The recipient still sees newsletter@shop.com as the sender.
• DKIM signature — The original DKIM signature is preserved. If the sender signed with DKIM, it still validates.
• Email content — Nothing in the body or headers is modified (except the envelope sender).

How Cleanbox handles this

Cleanbox uses SRS for Relay addresses. When email is forwarded from Cleanbox to your mail server, the envelope sender is rewritten to @srs.cleanbox.to so that SPF passes at your destination server.

For alias delivery via IMAP, SRS is not needed because Cleanbox delivers directly to the mailbox — there is no second forwarding hop that would trigger an SPF check.

Bounce handling works through the SRS address: if the destination server sends a bounce, it goes to the SRS address, Cleanbox decodes the original sender from the SRS envelope, and routes the bounce back to the original sender.

What about ARC?

ARC (Authenticated Received Chain) is a newer protocol that tries to solve the same problem differently. Instead of rewriting the envelope, ARC lets each server in the forwarding chain add a signed header vouching for the authentication results it observed.

In theory, a receiving server could say: "SPF failed, but the ARC chain shows that the first server saw SPF pass, and I trust that server." In practice, ARC adoption is limited. Most receiving servers do not make delivery decisions based on ARC headers — they treat them as informational metadata, not actionable trust signals.

SRS is the pragmatic solution that works today with every receiving server. ARC may become relevant as adoption grows, but it is not a replacement for SRS.

Takeaways

• SPF failure on forwarded email is normal and expected — not a sign of misconfiguration
• SRS fixes it by rewriting the envelope sender to the forwarder's domain
• DKIM is the authentication method that survives forwarding intact
• When choosing a forwarding service, verify that it implements SRS (or delivers via IMAP, bypassing the issue)
• If you run your own mail server behind a relay, enable SRS or trust the relay's SRS implementation

For more on email authentication, see The Complete Guide to Email Authentication: SPF, DKIM, DMARC, and Beyond.