Email authentication is supposed to be a reliable background check. But when messages get forwarded, those checks can fail in ways that surprise even experienced admins.
One of the most common pain points is SPF: A message can be legitimately sent, legitimately forwarded, and still look like a forgery to the recipient. The result is familiar: Why did my forwarded email land in spam? or Why did DMARC suddenly start failing?
The issue is that SPF answers a very specific question at a specific point in a message’s journey. When a message is forwarded, those conditions change.
Understanding what SPF can and can’t prove is the key to preventing authentication failures without disrupting normal mail flow. SPF is excellent at verifying whether the server delivering a message is authorized to send on behalf of a given domain. But forwarding introduces a new sending server—often one that’s outside the original sender’s control—and SPF doesn’t follow a message across multiple hops.
DKIM, on the other hand, was built to survive that kind of relay because it authenticates the message itself rather than the path it takes. While DKIM has its own limitations, it generally holds up much better than SPF when mail is forwarded.
We’ll explore the most common forwarding failure scenarios, and outline practical ways you can build an authentication strategy that works in the real world.
How SPF authentication works and why it depends on the sending IP
SPF, or Sender Policy Framework, is a DNS-based policy that tells the world which mail servers are authorized to send email using a domain in the return-path (also known as the envelope-from or MAIL FROM).
When a receiving mail server accepts an SMTP connection, it evaluates SPF using two primary inputs: the connecting IP address and the domain in the envelope-from. The receiver looks up that domain’s SPF record in DNS and checks whether the connecting IP is authorized by one of the mechanisms in the record, such as: ip4, ip6, a, mx, include, or exists.
The result is an SPF disposition such as pass, fail, softfail, neutral, or none.
That’s by design. SPF is highly effective at stopping straightforward domain spoofing, where an attacker sends mail from an unauthorized server while claiming to use a legitimate domain. The receiving server simply asks, “Is this IP allowed to send mail for this domain?” and applies its local policy based on the answer. It’s also lightweight because it doesn’t require parsing message headers or validating a cryptographic signature.
However, SPF’s reliance on the connecting IP creates a clear limitation: It’s evaluated independently at every receiving step rather than end to end. Each SPF check reflects the relationship between the SMTP client making the connection and the envelope-from domain presented during that connection. It doesn’t verify who originally authored the message, nor does it provide proof that survives after the message moves beyond the server performing the SPF check.
SPF can also create confusion because the visible From header isn’t necessarily the same as the envelope-from domain used during SPF evaluation. Many legitimate senders use a different return-path domain for bounce handling, while third-party email services often use their own return-path domains.
DMARC helps bridge that gap by requiring alignment between the visible From domain and the domains authenticated by SPF and/or DKIM. Even so, SPF alignment still depends on the IP-based evaluation performed when the receiving server first sees the message.
SPF works best when the server delivering the message is the same one the sender intended to use. Forwarding breaks that assumption, which is why it so often leads to authentication failures.
Why email forwarding commonly causes SPF to fail
Email forwarding sounds simple: A user receives mail at one address, and that mailbox automatically forwards it to another. But from an SMTP perspective, forwarding creates a new delivery event. The forwarding server becomes a new SMTP client that connects to the recipient’s mail server and delivers the message. Even if the message itself isn’t modified, the forwarding server is now the system sending the email from the recipient’s perspective.
The important detail is that most forwarding systems preserve the original envelope-from. As a result, the receiving server evaluates SPF against the original sender’s return-path domain while checking the forwarding server’s IP address. Unless the original sender’s SPF record explicitly authorizes that forwarding server—which is rarely the case—SPF will fail.
In most situations, the original sender can’t and shouldn’t authorize arbitrary forwarding servers across the internet. Forwarding happens outside the sender’s administrative control, and adding unknown forwarding infrastructure to an SPF record would unnecessarily expand the set of systems allowed to send mail on the domain’s behalf.
That’s why standard email forwarding breaks SPF even when every system involved is behaving exactly as intended. A message may pass SPF when it first reaches the forwarding service but fail when it arrives at its final destination because the recipient never sees the original sending IP. It only sees the forwarding server.
Common forwarding scenarios that trigger SPF failures include:
- Automatic forwarding rules in hosted mailboxes
- ISP-provided forwarding services
- University alumni forwarding addresses
- Small business domains that route mail through a central mailbox provider before forwarding it to personal inboxes
Mailing lists can create similar issues depending on how they redistribute messages and manage the envelope-from address. Some rewrite the envelope-from to use the mailing list’s own domain, allowing SPF to pass, but that changes bounce handling and introduces its own tradeoffs.
One industry solution is the Sender Rewriting Scheme (SRS). With SRS, the forwarding server rewrites the envelope-from to a domain it controls while encoding the original sender into the new address. That allows the recipient to evaluate SPF against the forwarding domain, where the connecting IP is authorized. SRS works well, but it isn’t universally deployed. It also doesn’t preserve strict DMARC alignment for the original From domain because SPF now authenticates the forwarding domain instead.
In a DMARC deployment, forwarded messages that fail SPF can still pass DMARC if DKIM passes and aligns with the visible From domain. That’s why DKIM is often considered the more forwarding-friendly authentication method.
How DKIM survives forwarding (and what can still break it)
DKIM, or DomainKeys Identified Mail, takes a different approach. Instead of verifying whether the connecting IP is authorized to send for a domain, DKIM verifies that the message content and selected headers were signed by a domain that published the corresponding public key in DNS.
When a sender applies DKIM, it adds a DKIM-Signature header containing the signing domain (d=), a selector (s=), the headers included in the signature (h=), and a cryptographic signature over the canonicalized headers and body. The receiving server retrieves the public key from selector._domainkey.example.com and verifies that the signature matches.
Because the signature travels with the message, DKIM is far more resilient to forwarding than SPF. The forwarding server’s IP doesn’t affect DKIM verification. As long as the message reaches its destination without changes to the signed portions, the DKIM signature will still validate.
Under DMARC, that’s often enough. A message passes DMARC if either SPF or DKIM passes and aligns with the visible From domain. Since forwarding commonly disrupts SPF alignment, DKIM often becomes the mechanism that preserves DMARC compliance.
DKIM is more resilient than SPF, but it isn’t immune to problems. The signature can break whenever intermediaries modify parts of the message that were included in the signature.
Common examples include:
- Mailing lists adding footers or subject tags
- Gateways appending legal disclaimers or security banners
- URL rewriting
MIME reformatting - Changes to line endings and header formatting
Any modification to a signed header or to the message body beyond what the selected canonicalization allows can invalidate the signature.
DKIM also depends on key management and DNS availability. If the public key record is missing, malformed, or too large for some DNS resolvers to retrieve, verification can fail. Messages can also fail if keys are rotated and old selectors are removed before delayed or in-flight messages are delivered. Some receivers may also reject short key sizes or weaker algorithms as security standards continue to evolve.
There are several ways to improve DKIM’s ability to survive forwarding:
- Sign the From header and other headers required for DMARC alignment, but be selective about signing headers that intermediaries commonly modify, such as Subject or certain trace headers.
- Use relaxed canonicalization for both headers and the message body to tolerate minor formatting changes.
- Avoid downstream systems that alter outbound messages after they’ve been signed, or make sure those systems apply a new signature after making changes.
- If your environment relies heavily on forwarding or mailing lists, align DKIM with the visible From domain so DMARC has a stable path to passing authentication.
- Monitor why DKIM validations fail—not just whether they pass or fail—since different failure reasons often point to very different operational issues.
Learn more here about how to read email headers
Build an authentication strategy that survives forwarding
Forwarding breaks SPF for a straightforward reason: SPF authorizes the server delivering a message at the moment it’s received, and forwarding changes that server. Even when a message is completely legitimate, the recipient evaluates SPF against the original envelope-from domain while seeing the forwarder’s IP address, which typically isn’t authorized in the sender’s SPF record.
That’s expected behavior—not a flaw in SPF—and broadly authorizing forwarding services can create unnecessary security and maintenance challenges.
DKIM provides a more durable solution because it authenticates the message itself rather than the path it takes. As long as the signed portions of the email remain intact, DKIM can continue to validate after a message passes through forwarding systems. While mailing list modifications, disclaimers, and URL rewriting can still break signatures, DKIM generally provides the most reliable path to maintaining DMARC compliance when forwarding disrupts SPF.
SRS can help in some scenarios, but because it shifts SPF authentication to the forwarder’s domain, it doesn’t preserve DMARC alignment for the original From domain.
If you want better visibility into where forwarding is affecting authentication—and practical guidance for strengthening SPF, DKIM, and DMARC together—explore the resources and platform available at Valimail.
Frequently asked questions
Why does my email pass SPF when sent directly but fail when it’s forwarded?
SPF is evaluated using the IP address of the server delivering the message and the domain in the envelope-from. When you send a message directly, the recipient sees your authorized sending infrastructure, so the connecting IP is typically listed in your SPF record and the check passes.
When the message is forwarded, the forwarding server becomes the system delivering it to the final recipient. The recipient still checks SPF against your original envelope-from domain, but it now sees the forwarder’s IP address instead of yours. Because that IP usually isn’t authorized in your SPF record, SPF fails.
This is expected behavior, not a sign that your SPF record is incorrect. In DMARC deployments, a properly aligned DKIM signature often compensates for forwarding-related SPF failures.
What is the difference between the From header and the return-path domain SPF checks?
The From header is the address recipients see in their email client and recognize as the sender. SPF doesn’t authenticate that field directly. Instead, it authenticates the domain used in the SMTP envelope-from, which handles bounce processing and is commonly exposed later as the return-path.
Those domains are sometimes the same, but they often differ in legitimate sending environments, especially when third-party email providers are involved. DMARC ties the two together by requiring alignment between the visible From domain and the domains authenticated by SPF or DKIM.
Forwarding complicates this because the connecting IP changes. Even if SPF passes, it may not align with the visible From domain. That’s one reason DKIM alignment is so important.
What is SRS, and does it fix SPF forwarding problems?
Sender Rewriting Scheme (SRS) allows forwarding services to rewrite the envelope-from address so SPF can be evaluated against the forwarder’s domain instead of the original sender’s domain. The rewritten address still encodes the original sender, allowing bounces to be routed correctly.
This enables SPF to pass because the forwarding server is authorized to send for its own domain. While SRS can reduce SPF failures caused by forwarding, it doesn’t preserve SPF-based DMARC alignment for the original From domain because SPF now authenticates the forwarder’s domain instead.
In practice, SRS is a useful operational tool, but DKIM aligned with the original From domain is usually the more reliable way to keep DMARC passing after forwarding.
Can DKIM fail during forwarding, and what are the most common causes?
Yes. DKIM survives forwarding only if the portions of the message covered by the signature remain unchanged.
Common causes of failure include mailing lists that modify subject lines or append footers, gateways that add disclaimers or security banners, URL rewriting, MIME reformatting, and other changes to signed headers or the message body. Depending on the canonicalization settings, even seemingly minor formatting changes can invalidate the signature.
Verification can also fail because of key management issues, such as missing or incorrect DNS records, selectors that were removed too early during key rotation, or keys that don’t meet modern security requirements.
The best approach is to use signing settings that tolerate minor formatting changes, minimize message modifications after signing, and monitor DKIM verification results to identify recurring issues.
How does DMARC behave when SPF fails because of forwarding?
DMARC checks whether a message aligns with the visible From domain and whether it successfully authenticates through SPF and/or DKIM.
If SPF fails because of forwarding, DMARC can still pass if DKIM passes and aligns with the From domain. That’s the most common and recommended way to handle forwarded email.
If both SPF and DKIM fail, DMARC also fails, and the receiving server may quarantine or reject the message based on the sender’s published DMARC policy.
Organizations moving toward stricter DMARC enforcement should make sure DKIM is properly configured and aligned, especially for mail streams that are likely to be forwarded. Forwarding-related SPF failures are expected, and DMARC is designed to accommodate them when DKIM remains intact.
Should I add forwarding services to my SPF record to stop failures?
Usually not.
Adding third-party forwarding services to your SPF record expands the list of servers authorized to send using your envelope-from domain. Because forwarding is often user-driven and widely distributed, this can unintentionally increase your spoofing risk while making SPF records more difficult to maintain as forwarding providers change their infrastructure.
A better approach is to keep your SPF record limited to your legitimate sending infrastructure, deploy DKIM across all outbound mail streams, and rely on DMARC to enforce alignment and provide visibility into authentication results.
If you operate your own forwarding infrastructure, implementing SRS can reduce SPF failures without weakening your SPF policy. For most organizations, however, DKIM aligned with the visible From domain remains the most scalable solution for supporting forwarded mail.
