emailverifier.dev
Posts

Why Email Forwarding Breaks SPF (and What DKIM, SRS, and ARC Fix)

| 7 min read | Usama Ejaz
An email keeps its original envelope sender through a forwarding relay; the source-IP identity path breaks at the final SPF gate while the sealed message path continues.

Email forwarding breaks SPF because the final receiver checks the forwarder’s IP address against the domain in the SMTP MAIL FROM address. That IP usually belongs to the forwarding service, not the original sender. SPF can fail even though the message is legitimate.

DKIM, SRS, and ARC address different parts of this problem. DKIM can preserve an aligned authentication result when the message is forwarded unchanged. SRS rewrites the envelope sender so the forwarder can pass SPF for its own domain. ARC carries signed evidence about earlier authentication checks. None of them is a universal “forwarding fix.”

I find the easiest way to reason about this is to stop treating an email as one identity. A forwarded message has at least three relevant facts: the IP making the current SMTP connection, the envelope sender used for bounces, and the visible From domain the reader sees.

The connecting IP changes at the forwarder

Consider this hypothetical direct delivery. The IP addresses use documentation ranges, so this is a protocol walkthrough rather than a live message.

Original sender: 192.0.2.10
SMTP MAIL FROM: <bounce@sender.example>
Header From: Alice <alice@sender.example>
DKIM d=: sender.example

sender.example (192.0.2.10) ──────────> final receiver

SPF:   pass  IP 192.0.2.10 is authorized for sender.example
DKIM:  pass  the signature from sender.example validates
DMARC: pass  SPF and DKIM both align with the visible From domain

SPF evaluates the client IP and the MAIL FROM identity during the SMTP transaction. It does not walk the Received headers and give the original server credit later. That distinction is central to the SPF specification’s discussion of mediators.

Now put a forwarder in the path:

Original sender: 192.0.2.10
Forwarder:      203.0.113.20
SMTP MAIL FROM: <bounce@sender.example>  (preserved)
Header From: Alice <alice@sender.example>

sender.example ──> forwarder ──> final receiver
                                  sees 203.0.113.20

SPF:   fail  203.0.113.20 is not authorized for sender.example
DKIM:  pass  if the signed content survives unchanged
DMARC: pass  through aligned DKIM, despite the SPF failure

The message has not become fraudulent. The observation point changed. RFC 7208 says the mediator becomes the “last” sending SMTP server, so its address is used for SPF. The current DMARC specification makes the operational consequence explicit: relayed mail will most likely fail SPF unless the relay rewrites MAIL FROM, while DKIM generally remains valid in simple relay cases.

This is also why adding every possible forwarder to the original domain’s SPF record is a poor general answer. The sender may not know which forwarding services its recipients use, and authorizing unrelated infrastructure expands who can produce an SPF pass for that domain.

SRS repairs the forwarding hop’s SPF identity

A forwarder can rewrite the envelope sender into its own domain before it sends the message onward. That family of techniques is commonly called the Sender Rewriting Scheme, or SRS.

Before forwarding:
  MAIL FROM:<bounce@sender.example>

After an SRS-style rewrite:
  MAIL FROM:<SRS0=token=sender.example=bounce@forwarder.example>

Final receiver checks:
  client IP: 203.0.113.20
  SPF domain: forwarder.example
  SPF result: pass

The rewrite lets forwarder.example authorize its own outbound server. It also encodes enough return-path information for the forwarder to send a legitimate bounce back toward the original envelope sender. RFC 7208 describes this mitigation in Appendix D.2.

But SRS does not make SPF pass for sender.example. It makes SPF pass for forwarder.example. If the visible From header is still alice@sender.example, those domains are not aligned for DMARC.

SPF authenticated domain: forwarder.example
Visible From domain:      sender.example
DMARC SPF alignment:      fail

So SRS solves a real transport problem, but SRS alone does not restore DMARC. The message still needs an aligned DKIM pass, or the final receiver needs other trusted evidence and local policy.

DKIM survives only if the signed message survives

DKIM is not tied to the IP making the final hop. A DKIM signature covers the message body and selected header fields, and the receiver retrieves the public key for the signing domain. A simple forwarder that changes the envelope recipient and adds a Received field can leave the original signature valid.

That is why senders that publish a strict DMARC policy should not rely on SPF alone. RFC 9989 Section 7.4 requires such domains to apply valid DKIM signatures, specifically because forwarding can break SPF.

The caveat is modification. A mailing list, help desk, or security gateway may prepend a subject tag, add a footer, remove a MIME part, or rewrite a URL. If that operation changes content covered by the signature, DKIM fails. The DKIM specification’s forwarding examples and RFC 7960’s mailing-list analysis document exactly this failure mode.

Forwarded unchanged:
  SPF fail + aligned DKIM pass = DMARC pass

Forwarded after signed content changes:
  SPF fail + aligned DKIM fail = DMARC fail

Relaxed DKIM canonicalization can tolerate some whitespace and formatting changes. It cannot make arbitrary body edits harmless. Signing less content may improve survival, but it also protects less content. That is a security tradeoff, not a free reliability setting.

ARC carries evidence across the indirect path

ARC, the Authenticated Received Chain, lets participating intermediaries record what they observed before forwarding or modifying a message. Each ARC set contains authentication results, a message signature, and a seal that links it to the preceding sets.

Hop 1 receives the original message:
  SPF=pass, DKIM=pass, DMARC=pass
  adds ARC set i=1

Hop 2 modifies and forwards it:
  current DKIM may now fail
  validates i=1, records new results, adds ARC set i=2

Final receiver:
  validates the ARC chain
  may use the sealed history in its local disposition policy

A valid ARC chain does not change today’s SPF result from fail to pass. It also does not prove the message is safe or the intermediary is trustworthy. RFC 8617 says ARC information may inform local policy decisions. The receiver still decides whether it trusts the organizations that sealed the chain.

That distinction matters. Treating arc=pass as a universal override would let any ARC participant manufacture trust. Chain validation only shows that the recorded chain is cryptographically intact.

Do you need DKIM, SRS, or ARC?

The strongest fair objection is that this sounds like three systems solving the same failure. They are not.

  • If you operate the original sending domain: sign with DKIM using a domain aligned with the visible From domain. Monitor DMARC reports before moving to stricter policy. Do not expect SPF alone to survive forwarding.
  • If you operate a forwarding service: use an SRS-style envelope rewrite so your outbound hop can authenticate its own return-path domain and route bounces correctly. Preserve the original message where practical. Add ARC only if you can protect your signing keys, record authentication results correctly, and accept accountability for the seals you create.
  • If you operate the final receiver: evaluate SPF at the SMTP boundary, validate DKIM and DMARC, validate ARC when present, then apply local trust and content signals. Do not convert a valid ARC chain into an automatic allow decision.

For a refresher on the identities each mechanism authenticates, see my guide to SPF, DKIM, and DMARC. The distinction between the visible sender and the SMTP return path is covered in From, Reply-To, and Return-Path. If you are rotating DKIM keys, the DKIM selector walkthrough covers the safe overlap sequence.

The operational model is simple once the identities stay separate: forwarding changes the connecting IP, SRS changes the envelope sender, DKIM protects signed message content, and ARC preserves a signed history of authentication assessments. DMARC then asks whether a current SPF or DKIM pass aligns with the domain the reader sees.

Continue reading

← Back to blog