Sender Policy Framework (SPF) is one of the oldest and most widely used standards for validating the identities of email senders. It is a cornerstone of modern email authentication.
However, SPF alone isn’t actually very helpful for protecting your domain from fraud. The biggest problem: SPF bases its authentication decisions on a message header field that most humans never see (the Return-Path).
That makes it way too easy for hackers to create messages that look legitimate (because they use SPF to validate the domain shown in the hidden Return-Path field) but are fraudulent (because they are using someone else’s domain in the From field).
SPF originated in the early 2000s, when the primary consideration was preventing spammers from overloading mail servers with junk. As a result, it’s oriented towards blocking unauthorized email servers.
In essence, SPF allows domain owners to create a rule system specifying a whitelist of senders. It’s an IP address-based system, and the creators expected domain owners would allow IP addresses that they manage through explicit lists as well as implicit rules that map to IP addresses.
In today’s world, many companies use email senders they don’t directly manage (cloud services that send on their behalf, for instance). Fortunately SPF also allows you to include rulesets defined by third-party services, but the standard limits the number of such rulesets that can be imported to 10.
By creating a whitelist, SPF allows receiving servers to authenticate only those messages that come from senders on that whitelist.
However, SPF doesn’t actually tell those receiving servers what they should do with non-authorized messages. Worse, it provides no feedback to domain owners, and it has no check on the From field that humans actually see.
It’s only with the addition of the more recent standard, Domain-based Message Authentication, Reporting & Conformance (DMARC) that SPF becomes useful as an authentication standard. That’s because DMARC adds a few essential elements:
- DMARC requires the visible From address to match the hidden Return-Path address.
- With DMARC, domain owners can set a policy that tells receiving servers how they should handle non-authenticating emails: Do nothing, quarantine them (in a spam folder), or reject them (drop them on the floor).
- DMARC includes provisions for receiving email servers to send reports back to domain owners, detailing successful and unsuccessful authentications (usually every 24 hours).
This table summarizes how SPF differs from SPF combined with DMARC.
None of this is meant to cast aspersions on the creators of SPF or the standard itself. SPF was an important part of the wide-ranging defense system email experts built to curb the onslaught of spam in the early 2000s. And it provides a crucial component needed to authenticate inbound emails: A ruleset for identifying legitimate senders.
But it’s only with the addition of DMARC that SPF really functions properly as an anti-fraud tool.