What is SPF Email Authentication and Why You Need It!

After reading this article you will be able to:

• Define what a DNS SPF record is
• Explain the benefits of a DNS SPF record
• Understand a DNS SPF record’s components

Just about every business today is doing some level of email marketing and in some cases they are using a 3rd party email service provider for bulk email delivery. What most small/medium sized businesses do not understand is that when you use a 3rd party email service provider you need to setup an SPF record in your domains DNS to authorize that 3rd party service provider to send emails on your behalf, otherwise your emails maybe blocked or marked as SPAM by your email recipients mail server.

What is a DNS SPF record?

A sender policy framework (SPF) record is a type of DNS TXT record that lists all the servers authorized to send emails from a particular domain.

A DNS TXT (“text”) record lets a domain administrator enter arbitrary text into the Domain Name System (DNS). TXT records were initially created for the purpose of including important notices regarding the domain, but have since evolved to serve other purposes.

SPF records were originally created because the standard protocol used for sending email — the Simple Mail Transfer Protocol (SMTP) — does not inherently authenticate the “from” address in an email. This means that without SPF or other authentication records, an attacker can easily impersonate a sender and trick the recipient of their email(s) into taking action or sharing information they otherwise would not.

Think of SPF records like a guest list that is managed by a door attendant. If someone is not on the list, the door attendant will not let them in. Similarly, if an SPF record does not have a sender’s IP address or domain on its list, the receiving server (door attendant) will either not deliver those emails or will mark them as spam.

SPF records are just one of many DNS-based mechanisms that can help email servers confirm whether an email comes from a trusted source. Domain-based Message Authentication Reporting and Conformance (DMARC) and Domain Keys Identified Mail (DKIM) are two other mechanisms used for email authentication.

It is worth noting that, at one point, SPF records had a dedicated DNS record type. The dedicated record type has since been deprecated and only TXT records are to be used.

How does a mail server check an SPF record?

Mail servers go through a relatively simple process when checking an SPF record:

• Server 1 sends an email. Its IP address is 192.0.2.0 and the return-path the email uses is email@returnpath.com. (A return-path address is different from the “from” address and is used specifically for collecting and processing bounced messages.)
• The mail server that is receiving the message (Server 2) takes the return-path domain and searches for its SPF record.
• If Server 2 finds an SPF record for the return-path’s domain, it searches the SPF record for Server 1’s IP address in its list of authorized senders. If the IP address is listed in the SPF record, the SPF check passes and the email will go through. If the IP address is not listed in the SPF record, the SPF check fails. In this case, the email will be rejected or marked as spam.

What does an SPF record look like?

SPF records must follow certain standards in order for the server to understand how to interpret its contents. Here is an example of the core components of an SPF record:

v=spf1 ip4=192.0.2.0 ip4=192.0.2.1 include:examplesender.email -all

This example lets the server know what type of record this is, states the approved IP addresses and a third-party for this domain, and tells the server what to do with non-compliant emails. Let’s break down how the individual components accomplish this:

• v=spf1 tells the server that this contains an SPF record. Every SPF record must begin with this string.
• Then comes the “guest list” portion of the SPF record or the list of authorized IP addresses. In this example, the SPF record is telling the server that ip4=192.0.2.0 and ip4=192.0.2.1 are authorized to send emails on behalf of the domain.
• include:examplesender.net is an example of the include tag, which tells the server what third-party organizations are authorized to send emails on behalf of the domain. This tag signals that the content of the SPF record for the included domain (examplesender.net) should be checked and the IP addresses it contains should also be considered authorized. Multiple domains can be included within an SPF record but this tag will only work for valid domains.
• Finally, -all tells the server that addresses not listed in the SPF record are not authorized to send emails and should be rejected.
  • Alternative options here include ~all, which states that unlisted emails will be marked as insecure or spam but still accepted, and, less commonly, +all, which signifies that any server can send emails on behalf of your domain.

While the example used in this article is fairly straightforward, SPF records can certainly be more complex. Here are just a few things to keep in mind to ensure SPF records are valid:

• There cannot be more than one SPF record associated with a domain.
• The record must end with the all component or include a redirect: component (which indicates that the SPF record is hosted by another domain).
• An SPF record cannot contain uppercase characters.

Check out the official SPF record documentation for more information.

Why are SPF records used?

There are many reasons domain operators use SPF records:

• Preventing attacks: If emails are not authenticated, companies and email recipients are at risk for phishing attacks, spam emails, and email spoofing. With SPF records, it is harder for attackers to imitate a domain, reducing the likelihood of these attacks.
• Improving email deliverability: Domains without a published SPF record may have their emails bounce or be marked as spam. Over time, bounced emails or emails marked as spam can hurt a domain’s ability to reach their audience’s inboxes, compromising efforts to communicate with customers, employees, and other entities.
• DMARC compliance: DMARC is an email validation system that helps ensure that emails are sent only by authorized users. DMARC policies dictate what servers should do with emails that fail SPF and DKIM checks. Based on the DMARC policy instructions, those emails will either be marked as spam, rejected, or delivered as normal. Domain administrators receive reports about their email activity that help them make adjustments to their policy.

If you are not sure if your domain’s DNS is configured properly with SPF records, please contact your domain administrator and speak to them about setting up SPF records to authenticate your email delivery with any/all 3rd party email service providers.