What is SPF? Email SPF explained: How it works

SPF is an important email feature, but it has its strengths and weaknesses. Find out all you need to know about SPF in this article.
SPF example. Left text reads "How SPF works: Receiver validates the sender against the IP whitelist associated with the  domain from the SMTP envelope".  Right text reads" But messages passing SPF can still be spoofed: Receivers only check the  domain and this may not match the domain people see in the visible  field, as in the example below".

Sender Policy Framework (SPF) is an email standard that pioneered the concept of domain-based email authentication. Below, we’ll walk you through everything you need to know about SPF, including what it is, how it works, limitations, and solutions.

What is SPF?

SPF prevents spoofing by enabling domain owners to allowlist IP addresses of servers that are authorized to send email on the domain’s behalf.

If a mail server with an IP address not on the list tries to send an email using that domain, it won’t pass SPF authentication.

How SPF email records work

Here’s a quick overview of how SPF works:

  1. Publish SPF record: Domain owners publish SPF records to the Domain Name System (DNS) that spell out the rule sets for their domains. An SPF record is plain text, and it can be as simple as a single line listing the IP addresses allowed to send an email on the domain’s behalf.
  2. Perform DNS lookup: When an email server receives an incoming email, it performs DNS lookups to retrieve the SPF record for a domain and examines the domain shown in the message’s Return-Path.
  3. Process SPF record: It will then process that SPF record to attempt to find the IP address of the sending server in the SPF record. This typically requires further DNS lookups to process parts of the SPF record linked in “include” statements. Notice the “include” statements in the above SPF record
  4. Pass or fail test: If there’s a match, the email passes the test and, in most cases, is delivered to the user’s inbox. If there is no match, the receiving server will treat the email as having failed SPF verification and will typically reject the message or add a flag to it, marking it as suspicious.

SPF risks and limitations

While SPF is better than nothing, it’s not a complete solution to protect your sending domains. Here are a few of the risks and limitations of SPF:

  1. Identifying and originating IP addresses for SPF records
  2. SPF 10 DNS lookup limit 
  3. SPF is spoofable
  4. Email SPF doesn’t survive email forwarding 

1. Identifying originating IP addresses for SPF records

SPF only lets you know that a message came from an approved IP address. But an approved IP address isn’t that easy to find. 

Shared systems like cloud platforms can host multiple cloud services that are dynamically assigned IP addresses at runtime. If the IP address identifies a service that you authorize, such as MailChimp, then anyone using the same IP address on that system could send messages that authorize with your SPF record.

2. SPF 10 DNS lookup limit 

The SPF standard limits the number of DNS lookups that mail servers will do when evaluating an SPF record. Before cloud services became common, 10 DNS queries were sufficient because most email messages were sent from applications hosted by the domain owner.

For modern cloud services, 10 lookups can go quickly, particularly because one lookup might contain other nested “include” statements requiring further DNS queries. When this article was published, G Suite’s “include _spf.google.com” actually comprised four different lookups because the SPF record at _spf.google.com contains three more lookups of its own.

Many folks implementing email authentication realize they must include all their cloud-sending services. To include them all means the SPF record exceeds the 10 DNS lookup limit. To mitigate the limitations of 10 domain lookups, they “flatten” the SPF record by pulling all the IP addresses of approved sending services forward into the primary SPF record.

Fluctuations in the IP addresses used by a cloud platform or sending service will require constant updates to the SPF record to prevent good email from being blocked. Some vendors attempt to cover any possible changes to IP address blocks used by cloud providers by specifying wide ranges in the SPF record—in tens of thousands to millions of IP addresses. Overly permissive IP blocks can allow fraudulent senders to send email on behalf of your domain, defeating the purpose of DMARC enforcement.

3. SPF is spoofable

SPF uses the domain shown in a message’s Return-Path field for authentication, not the “From:” address that humans can read. This creates a few issues:

  1. The “From:” address can still be spoofed.
  2. The Return-Path indicates where bounce messages should go, so the “From:” and Return-Path domains may differ. Most mail clients do not display the Return-Path address by default. For example, if you’re sending mail through a mailing list, the “From:” field might show your address, while the “Return-Path:” field shows the address of the email list.
  3. Phishers can use the general invisibility of “Return-Path:” when setting up their domains with their own SPF records. Then, they can send phishing emails with a company’s domain showing in the “From:” field but the phisher’s domain in Return-Path. Such messages are fake, but they will pass SPF authentication.

4. Email SPF doesn’t survive email forwarding 

SPF does not inherently support email forwarding. Any SPF records from senders trying to reach you through a forwarding address won’t validate because, to the receiving server, it looks like the message is coming from the forwarding server—not the source-identifying originating IP addresses.

SPF only lets you know that a message came from an approved IP address. This doesn’t always represent a one-to-one relationship. 

Shared systems like cloud platforms can host multiple cloud services that are dynamically assigned IP addresses at runtime. Some could use the same IP address. Or if the IP identifies a service that you authorize, say MailChimp, then anyone using the same IP address on that system could send messages that authorize with your SPF record.

Get complete DMARC, DKIM, and SPF protection

SPF is an essential part of email authentication but wasn’t designed for the cloud era. On its own, SPF will not authenticate email. However, in the absence of a DMARC record, how receiving servers handle a message that fails SPF is entirely up to them.

Valimail has a patented methodology to manage SPF records that mitigates the SPF 10-lookup limit and enables you to define unlimited senders. Valimail’s Instant SPF leverages the macros already defined in the SPF standard to:

  • Extract identifying information
  • Map this information to the originating service
  • Return service-specific SPF rules that the receiver can evaluate

Valimail Instant SPF dynamically generates a perfectly tailored SPF record, in milliseconds, in response to each mail server request.

Ready to get started? Schedule a call with our team to learn more.

Get started for free
with Monitor

Start your path to DMARC enforcement with a panoramic view of the traffic being sent on your behalf.
No trial offers, credit cards, or obligations.

Explore all Valimail
has to offer

Go one step further than visibility…Take action! Reach DMARC enforcement faster. Stay compliant with evolving sender requirements. All while protecting your brand.

Phishing and BEC protection starts with your domain — verify your DMARC status with the Valimail Domain Checker.