SPF

SPF, the Sender Policy Framework, authorises sending infrastructure. A domain owner publishes a TXT record beginning v=spf1, followed by mechanisms naming authorised sources: ip4: for the organization’s own address ranges, and include: to inherit a third-party provider’s list wholesale. The record ends in an all qualifier telling receivers how to treat everything else, usually -all for a hard fail or ~all for a softfail. When a message arrives, the receiving mail transfer agent takes the IP address of the connecting server and checks it against the record published by the domain in the SMTP envelope.

Two properties explain most of what confuses people. First, the record consulted belongs to the envelope sender, the address set by the MAIL FROM command and used to route bounces, not the From: header a recipient reads. An SPF pass therefore says a domain authorised the connection and says nothing about the displayed brand. Only DMARC alignment connects the two.

Second, SPF authenticates a network path rather than a message, so it breaks whenever mail is legitimately relayed: a forwarder becomes the connecting server and was never listed. DKIM covers that gap because its signature travels inside the message. SPF evaluation is also capped at 10 DNS lookups, a budget every include: consumes. Exceeding it returns permerror, which most receivers treat as though no record existed at all, so authentication can fail silently the day another platform is onboarded.