Email Deliverability

Authentication

An elementary explanation of SPF

Why and how you should implement this form of email authentication

Tom Blijleven

Marketing Manager

@

Flowmailer

We've all had our fair share of emails that made us reconsider whether we're the ones going crazy or the company sending out this email had something wrong for 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.

Published on:

May 2022

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's allowed to 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. The problem, however, is that a sender can use any name or sender 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 that are allowed to send 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. During this check, the two different identities (HELO & MAIL FROM) are looked at. It then determines whether the sending address is allowed to 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:

  1. None: no SPF record or no valid DNS domain was found during the SMTP transaction;
  2. Neutral: no check could be done on whether the sending IP address is authorized;
  3. Pass: indicates that the sender is authorized;
  4. Fail: suggests that the sender is not allowed;
  5. Softfail: a mitigated fail because no firm policy could be found in the SPF record;
  6. Temperror: temporary connection error to DNS could be fixed in the second attempt.
  7. Permerror: 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 an SPF check that fails 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:

  1. 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");
  2. 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.

Summarized:

An elementary explanation of SPF

Simply put, an SPF record is a collection of IP addresses that are allowed to send emails on your domain's behalf. These IP addresses are often linked to the email sending software you use - e.g. your CRM, email marketing tool, ERP. With this record, you also tell the receiving mail server their next move when the IP address that is trying to email on your behalf fails the check. When set up correctly, SPF is the first of the "OG 3" email authentication methods to protect your domain from abuse and increase your reputation with inbox providers.

Recommended reads:

Tom Blijleven

Marketing Manager

@

Flowmailer

With years of experience in the email (marketing) industry, Tom currently manages the marketing department at Flowmailer. In this role, he writes mainly about transactional email, email deliverability, and the API-first economy

Want to stay up to date on Flowmailer resources?