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.
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.
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 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.
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.
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 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.
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" (firstname.lastname@example.org) doesn't need to be checked. However, if the HELO cannot be verified, the receiving mail server must verify the more complex MAIL FROM.
The receiving mail server also determines its following action by evaluating the SPF record. There are seven possible outcomes of this evaluation:
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.
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:
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.