Let's say:

  • [email protected] sends an email to [email protected].

  • Bob owns the domain bob.com but doesn't manage an emailing server. Instead he uses an email forwarding service (provided by his registrar / DNS service, for example Cloudflare does this), redirecting every email arriving on [email protected] to [email protected]. Let's say this forwarding server has IP

This means that the email forwarding service actually modifies the original email from Alice and resends an email:

From: [email protected]
To: [email protected]

When arriving by Yahoo, yahoo.com will check if this email is legitimate. Since the email's From is [email protected], it will check the SPF of domain example.com. But the "email forwarding server IP" is not listed in example.com's SPF DNS records! This means yahoo.com should probably refuse this email.

Based on this, how can an email forwarding service even work at all? It shouldn't, based on the fact its servers' IP arent't listed in the original sender's domain's SPF. Still these email forwarding services work very well and reliably. How is this possible?

I'm probably missing a piece of the puzzle, which one is it?

1 Answer 1


SPF does not work at the level of the mail header at all, i.e. the value in the mail header field From (RFC5322.From) is irrelevant for SPF. SPF is only about the SMTP envelope, i.e. the address given in the SMTP MAIL FROM (RFC5321.MailFrom) command (often reflected as Return-Path in the mail header). A forwarder can simply use its own sender domain in the SMTP envelope and thus gets checked against its own SPF records, without touching the original From field in the mail header.

An alignment (same domain) between the mail header field From and the SMTP envelope sender is relevant though when checking DMARC. That's why DMARC will usually fail with forwarders, if the original domain relied on SPF only. Instead or in addition to SPF the original domain should use DKIM, which contrary to SPF does not rely on the senders IP address but on a signature over the mail (DKIM-Signature) added by the senders mail server.

  • Thanks @SteffenUllrich! I didn't know "SMTP MAIL FROM" vs. "mail header FROM" existed! I thought there was only one "FROM"... Would you know a diagram or document (except the RFC ;)) that gives an overview of all these subtleties? FROM vs ReturnPath vs SMTP envelope FROM etc. I miss the big picture. Thanks in advance!
    – Basj
    Oct 7, 2023 at 8:42
  • 1
    @Basj: Just imagine classic business snail mail: There is a sender and recipient at the envelope for transport - which equivalents to SMTP. And then there is the letter with its own sender and recipient in the letter head - which what is shown in the mail client. The information in letter and envelope can be different. Forwarding is basically putting the original letter into a new envelope for the next transport. Oct 7, 2023 at 9:29
  • Makes sense @SteffenUllrich! 1) Does this mean it's DKIM (only DKIM and not SPF nor DMARC) which ensures the content hasn't been modified by the multiple transport agents, is that correct? 2) Then, this requires that DKIM signature (or hashing) is applied only to the internal email content, but not the SMTP "envelope", is that correct? If it was applied to Return-Path (which can be modified by a forwarder) as well, it wouldn't work, right? Which fields are exclued by DKIM signature?
    – Basj
    Oct 7, 2023 at 9:42
  • @Basj: Yes, DKIM is only applied to the internal letter, not the envelope. There is only a single field from the letter head which MUST be included though - this is From. Everything else is optional and there are no clear recommendations - see noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html for the problems with this. Oct 7, 2023 at 9:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .