SPF and Email Forwarding: Why It Breaks and How to Fix It
Learn why email forwarding breaks SPF checks and how solutions like SRS, ARC, and DKIM can fix it. Practical advice for any domain.
Last updated: 2026-06-02
You have set up your SPF record correctly. It passes every check. But then you find SPF failures on messages that went through an email forwarder. This is not a configuration error on your part. Email forwarding fundamentally breaks how SPF works, and it is one of the most common sources of confusion in email authentication.
This guide explains why forwarding causes SPF failures, what happens behind the scenes, and what you can do about it. For a broader overview of SPF, see our complete SPF guide.
How SPF Normally Works
When you send an email from you@yourdomain.com, it travels to the recipient's mail server. That server checks the SPF record for yourdomain.com to see if the sending server's IP address is authorized. If the IP matches, SPF passes. This works perfectly in a direct delivery scenario.
Why Email Forwarding Breaks SPF
The problem starts when email goes through a forwarding server. Here is what happens step by step:
- You send an email from
you@yourdomain.comtocontact@theirdomain.com. - Your email reaches theirdomain.com's mail server. SPF checks your server's IP against
yourdomain.com's SPF record. It passes. - But contact@theirdomain.com has forwarding enabled. The email gets forwarded to
contact@gmail.com(their real inbox). - The forwarding server sends the email to Gmail. Here is the problem: Gmail now sees the email arriving from the forwarding server's IP address, but the From address still says
you@yourdomain.com. - Gmail checks SPF for yourdomain.com. It looks up your SPF record to see if the forwarding server's IP is authorized. It is not — because the forwarding server belongs to
theirdomain.com, not to you. SPF fails.
This is not a bug or a misconfiguration. It is a fundamental limitation of SPF as defined in RFC 7208. SPF checks whether the delivering server is authorized by the sender's domain. A forwarding server becomes the delivering server, but it is not in the original sender's SPF record.
This is not your fault
If your SPF record is correctly configured and passes checks on direct delivery, SPF failures from forwarding are caused by the forwarding setup — not by anything wrong with your DNS. You cannot fix this by changing your SPF record.
The Impact on Your Email
When SPF fails due to forwarding, the forwarded email might land in spam. However, DMARC may still pass if you have DKIM set up correctly (more on this below), and your domain's reputation is generally not affected — most large mailbox providers understand that forwarding causes SPF breaks. The severity depends on whether you have other authentication methods in place, particularly DKIM. Understanding SPF alignment is key to grasping why forwarding creates these issues.
Solutions and Workarounds
There is no way to make SPF itself survive forwarding — it is a limitation baked into the protocol. But there are several mechanisms that address this problem.
DKIM Survives Forwarding
This is the single most important thing to understand. Unlike SPF, DKIM (RFC 6376) signatures travel with the email itself. DKIM adds a cryptographic signature to the email headers and body when you send the message. That signature stays attached no matter how many servers the email passes through.
When the forwarded email arrives at the final destination, the receiving server verifies the DKIM signature against the public key in your domain's DNS. Since the signature is part of the message — not dependent on which server delivered it — DKIM passes even after forwarding. If SPF is your only authentication method, forwarding breaks your authentication entirely. With DKIM, you still have a valid signal.
DMARC Alignment Can Pass via DKIM
DMARC (RFC 7489) requires that at least one authentication method (SPF or DKIM) both passes and aligns with the From header domain. When email is forwarded, SPF fails but DKIM passes. As long as DKIM passes and aligns, DMARC passes. This is why the authentication ecosystem uses multiple protocols — they complement each other.
SRS (Sender Rewriting Scheme)
SRS is a technique where the forwarding server rewrites the Return-Path address to use its own domain. This way, the final destination checks SPF against the forwarding server's domain — where its IP is authorized. SRS is implemented by the forwarding server's administrator, not something you configure on your end.
ARC (Authenticated Received Chain)
ARC lets intermediate servers (like forwarders) record the authentication results they observed when they first received the email. The final receiving server can look at the ARC chain and see that SPF originally passed before forwarding. Gmail and Microsoft both support ARC. Like SRS, it is implemented by the forwarding infrastructure — not something you configure on your sending domain.
SPF vs DKIM: Forwarding Behavior
| Feature | SPF | DKIM |
|---|---|---|
| Depends on sending server IP | Yes — checks IP of delivering server | No — signature is part of the message |
| Survives forwarding | No — forwarding server IP is not authorized | Yes — signature stays with the email |
| Can be fixed by sender | No — sender cannot control forwarding servers | Yes — set up DKIM signing on your domain |
| DMARC alignment after forwarding | Fails — wrong domain in Return-Path | Passes — signature matches From domain |
Practical Advice for Small Businesses
If you run a small business and email forwarding is causing SPF failures, here is what to do:
1. Make sure DKIM is set up. This is the most effective step you can take. DKIM will keep your emails authenticated even when SPF fails due to forwarding. Check your current DKIM setup with DKIM Test.
2. Set up DMARC with a relaxed policy. A DMARC policy of p=none lets you monitor authentication results without rejecting email. As you gain confidence that DKIM is working, you can move to stricter policies. Understanding the difference between softfail and hardfail can also help you choose the right SPF enforcement level.
3. Do not add forwarding servers to your SPF record. You would be authorizing a server you do not control to send email as your domain, and you usually do not even know which forwarding servers your recipients use.
4. Do not panic about forwarding-related SPF failures. Major email providers understand that forwarding breaks SPF and factor this into their spam filtering. If you have DKIM and DMARC set up correctly, these failures rarely cause deliverability problems.
5. Monitor your authentication results. Use Email Deliverability Checker to monitor your setup and distinguish real problems from expected forwarding failures.
Never add unknown servers to your SPF record
Adding IP addresses to your SPF record for servers you do not control is a security risk. It authorizes those servers to send email as your domain. Stick to authorized services only.
The Bottom Line
Email forwarding breaks SPF by design. You cannot fix this with SPF alone. The solution is to use DKIM alongside SPF — DKIM signatures survive forwarding, and DMARC can pass based on DKIM alignment even when SPF fails.
References
- RFC 7208: Sender Policy Framework (SPF) — The current SPF specification
- RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM signatures survive email forwarding
- RFC 7489: DMARC — DMARC can pass via DKIM alignment when SPF fails due to forwarding
Never miss an SPF issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring