Sender Policy Framework is an email authentication standard (along with DKIM) that uses whitelisted IP addresses to be the only ones authorized to send emails. It is an underpinning of DMARC, and works hand in hand with DKIM to prevent spammers from sending messages as you in an exact-domain impersonation. 

SPF prevents spoofing by enabling domain owners to whitelist IP addresses of servers that are authorized to send email on the domain’s behalf. If the IP address of a mail server is not on the list, mail sent trying to use that domain won’t pass SPF authentication.

How SPF works

  1. Domain owners publish SPF records to the Domain Name System (DNS) that spell out rule sets for their domains. An SPF record is plain text and can be as simple as listing IP addresses that are allowed to send email on the domain’s behalf.
  2. When an email server receives an 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. The receiving server will then attempt to find the IP address of the sending server in the SPF record. This will normally require further DNS lookups to process parts of the SPF record linked in ‘include’ statements. 
  4. If there’s a match, the email passes 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 mark it as suspicious.


How do you implement SPF?

Generally, you can gain the IPs or SPF include from the senders documentation or customer support team. You then use this information to add to a TXT SPF record in your DNS.

What are the challenges in implementing it?

SPF is the oldest email authentication standard and was designed for a much simpler Internet. Today’s cloud hosted platforms and services present a number of limitations to the effectiveness of SPF to prevent phishing. 

Some of the challenges with using SPF-only authentication

SPF Syntax

SPF records are text, but the syntax is a little tricky and it can be easy to make typos or other errors that are hard to spot, rendering the SPF record useless.

The SPF directives (rules) include more than simple lists of IP addresses. 

For example, an SPF record can include:

  • A list of specific permitted IP addresses or net blocks (ranges of IPs)
  • Rules that point to other types of DNS records. Example: “If the MX record or the A record for the sending server contains a specific IP address, let the message pass.”
  • “Include” directives that reference SPF rules controlled by other entities. Example: to enable SPF for the mail sent by Gmail (as well as email notifications sent by Google Docs, Google Calendar, and so on) and are using Google’s G Suite, you would have to  add “” to your SPF record. This tells mail servers to do an additional DNS lookup for to find additional SPF rules listed there.

Identifying originating IP addresses for SPF records

Using SPF only tells you that a message came from an approved IP address. 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.

The 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 pretty quickly, particularly because one lookup might contain other nested ‘include’ statements requiring further DNS queries. At the time this was published,
G Suite’s “include” actually comprises four different lookups, because the SPF record at contains three more lookups of its own.

As an analogy, think of when you go grocery shopping. Your cart has a limited amount of space (10 SPF lookups) and every item you get milk gallon (Google), a dozen eggs (Salesforce), and a can of tomato (Marketo) will each takes up a different amount of space. In the same way, each include will contribute towards the lookup but some take more space than others, which all adds up quickly.

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

Flattening, a band-aid remedy on a bigger wound, quickly becomes a problem because of 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. 

In the end, this temporary remedy will be your responsibility to upkeep or have pay a vendor to handle the delegated task. Who knows how many messages could have been blocked from the moment the IP's changed, the moment it was detected, and the moment it was corrected. 

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 email to be sent on behalf of your domain, defeating the purpose of DMARC enforcement.

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, and return service-specific SPF rules that can be evaluated by the receiver. Valimail Instant SPF dynamically generates a perfectly tailored SPF record, in milliseconds, in response to each mail server request.

SPF limitations

SPF alone is spoofable

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

  1. The “From:” address can still be spoofed.
  2. The Return-Path is used to indicate 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:” to set up their own domains with their own SPF records. Then they can send out phishing emails with a company’s domain showing in the “From:” field but the phisher’s own domain in Return-Path. Such messages are fake, but they will pass SPF authentication.

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 it looks like the message is coming from the forwarding server, not the source. 

Identifying originating IP addresses                                                                                                      

SPF lets you know that a message came from an approved IP address. 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, anyone using the same IP address on that system could send messages that authorize with your SPF record.

SPF is an essential part of email authentication, but it wasn’t designed for the cloud era. On its own, SPF will not authenticate email, which is why DMARC is so important.