Categories
Dmarc as a Service

What is SPF?

Photo of man working on computer
Photo of man working on computer

Sender Policy Framework is the standard that pioneered the concept of domain-based email authentication. 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 a mail server with an IP address that’s not on the list tries to send email using that domain, it won’t pass SPF authentication.

How SPF Works

  1. 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 that are allowed to send email on the domain’s behalf.
  2. 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. It will then process that SPF record to 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. Notice the ‘include’ statements in the above SPF record, indicating
  4. 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 mark it as suspicious.

SPF implementation challenges

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. Here are some of the challenges and limitations with SPF:

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 “include:_spf.google.com” to your SPF record. This tells mail servers to do an additional DNS lookup for _spf.google.com to find additional SPF rules listed there.

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.

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 _spf.google.com” actually comprises four different lookups, because the SPF record at _spf.google.com contains three more lookups of its own.

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.

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 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 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.
  3. 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.
  4. 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 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.

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. But  In the absence of a DMARC record, how receiving servers handle a message that fails SPF is entirely up to them.