SPF Record Explained

Today, an SPF record is a must-have DNS record for reliable email delivery. It is a type of email authentication to protect your emails from being forged. This secures your reputation from phishers and spoofers. Find out more about the Sender Policy Framework to increase the credibility of your product.

What is an SPF record?

One of the DNS resource records is TXT. It is mostly used to denote facts about the domain and provide information to outside sources. It’s a must-have for email authentication. For example, an email comes from a server to your internet service provider (ISP). ISP can authenticate the email using a dedicated TXT type record, SPF record. This record contains data about the trusted servers authorized by your domain so, your ISP can identify a source an email is coming from and detect a forged email. SPF or Sender Policy Framework is a primary (but not the only) way to authenticate your email.  

Email authentication standards – what are they for?

SMTP can’t protect your app from frauds such as email spoofing, phishing, and spam. It lacks a feature to identify the origin of an email message and validate its domain. Instead, email authentication can do the job. 

There are three widely adopted standards to authenticate emails: SPF, DKIM, and DMARC. In brief, each of them does the following:

• SPF checks that the IP address the email comes from is authorized.
• DKIM checks the message wasn’t changed in transit using keys for signature-verification.
• DMARC encloses both approaches in one go.

SPF, DKIM, and DMARC differ in technical implementation, butthey all draw on DNS records. You can also encounter other authentication methods like ADSP, Sender ID, iprev, and so on. Some of them are either unclaimed or have been deprecated. 

Sender Policy Framework or SPF

Sender Policy Framework appeared officially as an experimental standard in 2006. Eight years later, SPF was approved as a proposed email authentication standard. 

In plain English, SPF is a protocol according to which the mail servers decide whether to receive or reject an incoming email. The decision is made using the SPF information in TXT records as for the list of authorized IP addresses within a particular domain. If the email has been sent from one of these addresses, it’s not forged and can be let in.

When you need SPF 

If your digital product sends transactional or even commercial messages, make sure to implement Sender Policy Framework. This is currently required by internet service providers. If you don’t have a valid SPF record, or it is incorrect, your ISP might run secondary email filtering. Failed SPF authentication means that your email will be recognized as spam or even blocked. 

SPF scares off spammers and phishers by filtering out forged emails. It keeps your product reputation spotless. But, to complete the picture, it is better to implement a full-scale email authentication (SPF + DKIM + DMARC).

Cons of SPF email authentication

• It is troublesome to keep SPF records up-to-date if you change ISP or add mail streams
• SPF alone does not guarantee that your message will pass authentication
• SPF records break plain message forwarding 

Common SPF misconceptions

SPF is a necessary measure but it is not a silver bullet against spoofing. Make sure you are aware of the following misconceptions so you can use the framework correctly. 

• Full domain protection from spoofing

SPF works with the envelope-from address (return pass) of email. It is invisible to the user unlike the header-from address, which refers to the message content. Hence, an SPF record can’t protect the visible address of the sender.

• With SPF, you get direct protection against spam 

The framework leverages spam filtering systems to check emails. Also, it protects against forged messages from a specific domain. However, it does not offer significant improvements in terms of fighting spam.

• SPF authorizes the email sender

Actually, the mail server sending a message is being authorized according to the SPF record. So, the framework works at the domain level. 

• One SPF record per each authorized domain

Keep in mind that you can only have one SPF record. Otherwise, you’ll get ‘permerror’- an error indicating that the retrieved SPF policy record could not be interpreted. 

• Email authentication with only DKIM is enough

Even if you have all the messages authorized according to DKIM, you still need an SPF record to identify the domain. Moreover, the Sender Policy Framework is required within cloud services and IPv6 networks. So, the best way to combat spoofing and secure your email is to implement SPF, DKIM, and DMARC.

How does SPF work?

In general, the SPF in action consists of the following steps:

• Creating an SPF record. This establishes an authentication policy and defines mail servers authorized to send emails from a particular domain.
• DNS lookup. An incoming message is being verified in the DNS. The domain name should be listed as the “envelope from” address. Then, the inbound server checks whether the IP address the email is sent from is authorized in the SPF record. The mail fails the SPF authentication if any of the checks are  unsuccessful.
• Authentication outcome. The mail server either delivers, flags, or rejects the message based on the rules specified in the SPF record.

For example, a server with IP address ‘234.213.42.2’ has sent an email from ‘home@apple.com’. During the SPF check, the inbound server will request the ‘apple.com’ domain if this IP address is authorized to send the email. If yes – welcome, if not – the message will be sorted according to the mechanism specified in the SPF record. 

SPF record syntax

First, let’s anatomize a simple SPF record example.

“v=spf1 +a +mx redirect=example.com -all”

v = spf1 is a version number of the current record, and the rest are Mechanisms, Qualifiers, and Modifiers to specify different rules of SPF check. Here is what you can set up in your SPF record.

Qualifier	Purpose	Implementation
+	Accept. The host is allowed to send a message	+
–	Reject. The host is not allowed to send a message	–
~	Accept but mark. The host is not allowed to send a message but is in transition (the mechanism is for testing purposes)	~
?	Accept. The host validity is unstated	?

Mechanism	Purpose	Implementation
a	Defines the DNS A record of the domain as authorized. If unspecified, the current domain is used	a a/<prefix-length> a:<domain> a:<domain>/<prefix-length>
all	Defines policy for all other sources	all
exists	Checks validity of an A record for a provided domain	exists:<domain>
include	Includes the specified domain as authorized. If the domain does not have a valid record, you’ll get ‘permerror’	include:<domain>
ip4	Defines the IPv6 network range. Can be used with prefix, which denotes the range length. If no prefix is specified, /32 is the default	ip4:<ip4-address> ip4:<ip4-network>/<prefix-length>
ip6	Defines the IPv6 network range. Can be used with prefix, which denotes the range length. If no prefix is specified, /128 is the default	ip6:<ip6-address> ip6:<ip6-network>/<prefix-length>
mx	Defines the DNS MX record of the domain as authorized. I.e., the message must be sent by one of the domain’s incoming mail servers.	mx mx/<prefix-length> mx:<domain> mx:<domain>/<prefix-length>
ptr [deprecated]	Defines the reverse hostname and subdomain of the sending IP address.	ptr ptr:<domain>

Modifier	Purpose	Implementation
exp	Specifies the explanation that a sender will see if the message has been rejected	exp=<domain>
redirect	Replaces domain with the current record	redirect=<domain>

What you should keep in mind:

• One SPF record string cannot exceed 255 characters. Use multiple records if necessary.
• Some DNS providers may not require quotations to enclose the record data. Check it in advance.
• Records for subdomains should be named respectively (best for best.example.com)
• To avoid unreasonable load on the DNS, the total number of mechanisms including modifiers should be limited to 10. 

Now, let’s put this knowledge into practice. 

Create an SPF record for your domain

Step 1 – Preparation

• Collect all mail servers and IP addresses that will be specified as authorized in the SPF record 

Step 2 – DNS control panel

• Access the DNS control panel of your ISP and find the section of the TXT type record. 

Step 3 – SPF record

• Start with the version tag: v=spf1. Next versions will be v=spf2, v=spf3, etc. 
• Insert all the IP addresses you’ve collected to specify as authorized: 

ip4:35.167.41.421 ip6:2a13:c025:e4:7a01:bc72:dcb5:7a13

• Add the include tag for each third-party email service to designate it as a trustworthy sender:

include:sendgrid.net or include:mandrillapp.com

• Leverage other mechanisms, qualifiers, or modifiers to set up the SPF record.
• The all tag is usually used to finalize the record.
  • -all – all unspecified servers are not authorized (emails will be rejected).
  • ~all – all unspecified servers are not authorized, but emails will be marked and accepted.
  • +all – any server is authorized (quite undesirable option).

This is how the most common SPF record looks like:

"v=spf1 a mx -all"

Here, all A and MX records in this domain are authorized to send emails. Emails from anything beyond will be rejected. 

SPF record for multiple domains

Let’s say you have a primary domain – alpha.net with a record like this one v=spf1 a mx -all. and you need to make an SPF record for multiple domains like beta.net and gamma.net? 

The “include” mechanism allows you to designate other domains that are independent from your primary one. For example, alpha.net might send mail using beta.net and gamma.net.

v=spf1 include:beta.net include:gamma.net -all

Also, you can point to your primary domain by adding include:alpha.net in SPF records of your secondary domains: 

v=spf1 include:primary-domain.com -all

This will apply the rules from the primary domain for the secondary ones. 

Keep in mind that you cannot have more than one TXT record for SPF for a domain.

Can I split a large SPF record?

What if your SPF record looks like this?

v=spf1 a mx a:mail.alpha.com a:first.alpha.net a:second.alpha.org mx:third.domain.net ip4:34.243.61.237 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e include:sendgrid.net include:mandrill.com -all

It matches the requirement of 255 characters per string, but still it is very long. Hence, you can split it into several records that will be included in the main SPF record. Here is how it may go:

• First, create separate records. Their names should relate to the current domain like this: 

spf1.alpha.com TXT

v=spf1 a mx a:mail.alpha.com a:first.alpha.net a:second.alpha.org mx:third.domain.net -all

spf2.alpha.com TXT

v=spf1 ip4:34.243.61.237 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e -all

spf3.alpha.com TXT

v=spf1 include:sendgrid.net include:mandrill.com -all

• Now, you can tweak your initial SPF record in this way:

alpha.com TXT

v=spf1 include:spf1.alpha.com include:spf2.alpha.com include:spf3.alpha.com -all

That’s it. All these records will be checked as one after the DNS update.

Validate your SPF record

The last thing we advise you to do is to validate your SPF record. Luckily, there are a bunch of actionable tools like SPF Record Check or SPF Syntax Validator. This will troubleshoot your record and prevent the annoyance in the future. 

How to create an SPF record using my DNS provider?

You can create and manage your SPF records using a respective console or control panel of your DNS provider. Some services give detailed instructions or guides on how to create TXT records. Below, you’ll find links to the guides of some top-rated providers. 

• Amazon Route 53
• Azure DNS
• Cloudflare DNS
• GoDaddy Premium DNS
• Google Cloud DNS

Also, we’ve collected a list of SPF specs for popular email providers so you can copy and paste them into your TXT record.

Email service provider	SPF record
Gmail	v=spf1 include:_spf.google.com ~all
Sendgrid	v=spf1 include:sendgrid.net ~all
MailChimp	v=spf1 include:servers.mcsv.net ?all
Mandrill	v=spf1 include:spf.mandrillapp.com ?all
Mailgun	v=spf1 include:mailgun.org ~all

SPF Troubleshooting: SPF record won’t validate

Here is a short list of common problems (and their basic solutions) one may encounter while trying to validate SPF records.

• Exceeding the limit of DNS lookups. Keep in mind that there are only 10 DNS queries. The most common problem here is using a lot of “include” nesting in the records. There are few solutions to this issue, the most popular being creating a dedicated email stream subdomain. First, you can create a brand-new SPF record for the subdomain. Second, when a verifier performs an SPF check, it only looks at the domain as extracted from the RFC 5321 Mail From. This means it looks straight into the DNS record of a child, not a parent domain. In case you need more ways to troubleshoot the breaking of 10 DNS lookup limit, check out the detailed DMARCian guide.

• Type 99 (SPF type record) deprecation. This means your SPF record is out of date. In 2014, the experimental phase of using DNS RR type records stopped. Now SPF records must only be published as a DNS TXT (type 16). To resolve “Type 99” issues, make sure you are using TXT type DNS records for the SPF authentication.

• Multiple SPF records. If you’re using a large email provider like Microsoft Exchange or Gmail, the issue with duplicated SPF records should be corrected automatically. Smaller email providers do not usually offer such intelligent features, so you’re likely going to have to handle this all by yourself. The best solution is to merge both of your DNS TXT entries into a consolidated version. Find more information on how to deal with this issue in our SPF do’s and don’ts. 

Once you’ve set up your SPF record, you can proceed to DKIM and DMARC protocols to make your email security and marketing campaigns a cut above the rest.