An Elementary Explanation of SPF

We’ve all had our fair share of emails that made us reconsider whether we’re going crazy or the company sending this email had something wrong with breakfast. Emails that shouldn’t hit your inbox in the first place, emails that are clearly spam – maybe even a legitimately looking call-to-action with a phishing link. Don’t start questioning your sanity; this company’s domain might have been spoofed due to the lack of good domain protection.

A significant problem with email is that domain names (@yourbusiness.com) can easily be spoofed. Sending emails on someone else’s behalf isn’t rocket science. Since email is a fairly old system (it’s been around since the ’70s!), many protective measures have been developed over the years. One of these measures is SPF: The Sender Policy Framework.

The Sender Policy Framework (SPF)

An SPF record is a piece of text in the DNS settings of your domain (yourbusiness.com) that protects it from being spoofed (misused by others). Many spam filters and mail servers use an algorithm to mark emails as wanted or unwanted, often based on this record. The Sender Policy Framework tells the receiving mail server (like Gmail) that the domain is used by someone who can do so.

Email without SPF

Email communications happen between two mail servers: yours and the one your recipient uses – the SMTP protocol. Your server hands over the information you want to send to your recipients. However, the problem is that a sender can use any name or address. We could easily fake the sender and say we’re Google, Amazon, or any other big brand, a.k.a. spoofing.

Email with SPF

With the Sender Policy Framework (SPF) in place, the receiving server can check whether the email you send actually comes from you. The SPF record holds a list of IP addresses allowed to be sent on your behalf. If the sender sends the email from an IP address that isn’t on that list, it will not pass the SPF check. Later on, we’ll explain how that works.

The Sender Policy Framework RFC

How SPF records work is found in RFC7208. This documentation describes how SPF works in communication between two mail servers: Publishing on one side and authorizing on the other. The communication happens mainly during the so-called SMTP transaction, where one mail server (MTA) offers an email to another mail server. During authorization, the receiving mail server checks evaluates, and provides feedback about the sender.

The four steps of the Sender Policy Framework

Publishing an SPF record

The sending domain publishes the SPF record, including authorized IP addresses. These addresses are allowed to send emails on behalf of the respective domain. During the email transaction, the names “HELO” and “MAIL FROM” are used. This ‘greeting’ allows the sending mail server to be known to the receiving mail server.

Authorizing the SPF record

According to the RFC, the receiving mail server should (not every receiver does) check for the availability of an SPF record. The two identities (HELO & MAIL FROM) are examined during this check. It then determines whether the sending address can send this email on behalf of those identities. Most receiving mail servers check the identities in chronological order. “HELO” (smtp.yourcompany.com) is a somewhat “easier” identity to verify. If that identity is confirmed and passes authorization, the “MAIL FROM” (info@jouwbedrijf.nl) doesn’t need to be checked. However, if the HELO cannot be verified, the receiving mail server must verify the more complex MAIL FROM.

Evaluating the SPF record

The receiving mail server also determines its following action by evaluating the SPF record. There are seven possible outcomes of this evaluation:

None: no SPF record or no valid DNS domain was found during the SMTP transaction;
Neutral: no check could be done on whether the sending IP address is authorized;
Pass: indicates that the sender is authorized;
Fail: suggests that the sender is not allowed;
Soft fail: a mitigated fail because no firm policy could be found in the SPF record;
Temperror: A temporary connection error to DNS could be fixed in the second attempt.
Permerror: The domain could not be interpreted correctly. Requires the DNS administrator of the sender to correct the problem.

The evaluation described above is the default evaluation. However, each recipient’s response to a failed SPF check may vary. Some receiving mail servers require having a solid SPF record, whereas others value it way less.

Feedback

When the SPF record has been checked and evaluated by the receiving mail server, an email passes or gets blocked. If it passes, the mail servers will communicate it’s “delivered.” However, when the SPF check fails, the receiving mail server has two options:

Give a (temporary) error so that the sending mail server knows the message doesn’t need to be sent again (rejection) or whether there is a problem of a temporary nature (“try again later”);
Let the message pass and therefore give “delivered” feedback – but add a header indicating that it is a suspicious message – a.k.a. the spam flag.