Why email forwarding breaks SPF, and what fixes it

When a message is forwarded, the last hop comes from the forwarding server, and your SPF record has never heard of it. SPF fails, and nothing you add to your own record can change that. DKIM is what gets forwarded mail through.

What happens on the second hop

SPF checks one thing: whether the server connecting to the receiver is listed by the domain in the envelope sender. Take a message from you@example.com to someone@university.edu, who forwards everything to a personal mailbox:

1. Your provider delivers to university.edu. The connecting server is in your record, so SPF passes.
2. The university's server sends the same message on, often with the envelope sender unchanged as you@example.com. The receiver checks your record for the university's server, does not find it, and SPF fails.

Nothing is wrong with your record. SPF authorises servers, and the second hop was sent by a server you never authorised and should not.

Why adding the forwarder is not the answer

You cannot list every server that might forward your mail, because anyone you write to can set up forwarding without telling you. Adding a large provider's include to cover its forwarding would authorise everyone who sends through that provider to send as your domain. It would also spend lookups you probably do not have.

What actually fixes it

DKIM, on everything you send

A DKIM signature is carried inside the message, so it survives a plain forward as long as the message is not altered on the way. DMARC passes when either SPF or DKIM passes and aligns with the From domain, so a forwarded message with a valid signature still passes DMARC even though SPF failed.

This is the fix that is in your hands. Every service that sends as your domain should sign with a key on your domain, not the vendor's.

~all rather than -all

A hardfail lets the final receiver reject during SMTP, on the SPF result alone, before it has seen the DKIM signature. A softfail leaves the decision to DMARC, which will see a valid, aligned signature and pass the message. ~all or -all covers this in full.

What the forwarder can do

Two fixes belong to the forwarding side, not to you:

• SRS, the Sender Rewriting Scheme, rewrites the envelope sender to the forwarder's own domain, so SPF is checked against the forwarder's record and passes. It does not align with your From domain, so for DMARC it is DKIM that still has to pass.
• ARC, Authenticated Received Chain, lets the forwarder record the authentication results it saw on arrival and sign them. A receiver that trusts that forwarder may accept the message on that basis. Whether it does is the receiver's choice.

Mailing lists are harder

A list that adds a subject tag or a footer changes the message, which breaks the DKIM signature as well as SPF. Lists that handle DMARC properly rewrite the From address to their own domain for senders whose DMARC policy would otherwise cause rejection. If yours does not, that is for the list operator to fix.

Seeing it in your reports

Forwarding shows up in DMARC aggregate reports as SPF failures from servers you do not recognise, often large providers and universities, alongside a DKIM pass. That pattern is forwarding working as intended. SPF failures from unknown servers with DKIM failing too are the ones worth investigating.

Check your own side

Enter your domain to see your record and its all term, or use the SPF checker to see how a specific server evaluates against it.