SPF Email Record Explained: What It Is and How It Works

Sender Policy Framework (SPF) is an email authentication standard that domain owners use to specify the email servers they send email from, making it harder for fraudsters to spoof sender information. SPF email policies are widely used and are currently defined by the IETF under section RFC 7208. You can think of SPF email records as a public list that lets everyone know where you send your mail from. If an email doesn’t match that list, the recipient should treat it as fake. SPF is configured and managed as a TXT record inside the DNS server your domain uses.

Why are SPF email records important & how do they work?

SPF records play a key role in email security as they ensure your domain is only sending emails from a verified list of servers, which you specify. While it’s true that SPF isn’t perfect, when you combine it with DKIM and DMARC, it can drastically improve your email security posture. Let’s explore what strong SPF email policies can do to improve email security.

• Improve deliverability: When you secure your email server with SPF, attackers cannot use your domain to send spam. This helps keep your domain off global blacklists, thereby improving your mail servers' overall deliverability.
• Combat email spoofing: An SPF email record helps prevent spoofing and phishing by verifying the IP address of the sender compared to the domain owner.
• Improves domain reputation: Having SPF email policies gives your domain elevated reputation and shows other servers and blacklist sites that you’re committed to email security. This drastically decreases the odds that your outbound emails get falsely flagged as spam and helps improve your standing inside firewalls and other cybersecurity databases.

Servers receiving messages verify SPF by querying the domain’s Return-Path value found in the headers of the email. The recipient server uses this Return-Path to check for a TXT record in the sender’s DNS server. If SPF is in place, it will list all approved servers mail is allowed to come from. If that particular IP is not on the list, the SPF check will fail.

SPF email records can be broken down into two parts, qualifiers and mechanisms:

• Mechanisms can be set to describe who is allowed to send mail on behalf of a domain. If those conditions are met, one of four qualifiers can be applied.
• Qualifiers define the action taken when an SPF mechanism matches. If no qualifier is specified, the default is “+” (pass). Below are the four types of qualifiers that can be used when configuring SPF email policies.
  
  
  
  The following elements may be included within the SPF email record.
• v=spf1: This tag is always required and states the version of SPF being used. It will always be the first tag in the SPF policy.
• a: Tests the A records for the domain. If the host IP is found, it is matched. The example below uses the current domain and soft fails anything else.
  • Example: v=spf1 a ~all
• all: Found at the end of the SPF email record, this specifies instructions on what to do when there is no match to the SPF record. One of the most common qualifiers uses ~all to soft fail anything that does not match. The below example allows email from a single IP address, and soft fails all other senders.
  • Example: v=spf1 12.34.56.78 ~all
• mx: Using mx by itself will query the A record IP addresses of the MX record for the current domain. The mx mechanism can also be paired with a completely separate domain. Using mx allows you to update your DNS without having to modify your SPF email record. Below will query the mx records of example.com to see if there is a match.
  • Example: v=spf1 mx:example.com ~all
• Include: Allows for another domain to be specified and is often used when allowing third party services to send mail with your domain. Include mechanisms can be stacked, allowing for multiple senders. Below is an example of using include to allow for multiple sending servers.
  • Example: include:_spf.google.com include:example.com ~all
• Exists: Looks to see if the A record of any specified domain exists. If the A record exists, then this passes. The domain does not have to be your own and simply must resolve. This can be used in conjunction with macros to have the recipient query a public spam list and fail the SPF check if the address is listed on the list. Below is an example of using a macro to query a blacklist. %{i} is a macro syntax that inputs the senders IP address and then checks to see if that address is present on the list.
  • Example: v=spf1 mx -exists:%{i}.rbl.spamchecker.example.org ~all

What Does an SPF Email Record look like?

Here is an example of an SPF email record that could be found inside of a TXT record on a DNS server: v=spf1 a ip4:12.34.56.78/28 include:marketingemailserver.com ~all

In this example, the SPF email record allows email to be sent from 12.34.56.78/28, as well as from marketingemailserver.com. If the message comes from any other address, it will be marked as an SPF soft fail. To better illustrate how SPF email policies work, let’s break down the example above.

• v=spf1: This announces which version of SPF is being used.
• a: If the domain has an A or AAAA record that matches the IP address, it will be considered a match.
• ip4: Denotes that the following IPv4 address is authorized to send.
• 12.34.56.78/28: Specifies the server that is allowed to send from. The /28 allows the entire network subnet to send mail rather than a single IP address. This is useful for organizations with multiple mail servers or dedicated subnets for servers. This is also a great way to shorten a long SPF email record.
• Include: Notes another server is also allowed to send mail on behalf of the domain. In this example, it is a third-party email marketing server.
• ~all: Tag anything else not specified as an SPF soft fail and allow it to be sent.

How do I Check if an SPF Record Exists for my Domain, and how Can I Create one?

If you have access to the DNS server your email server uses, you can look for a TXT record that begins with “v=spf”. If you don’t have an SPF email record set up, you can easily create one. However, there are some steps to take before creating your SPF email record. In order to make changes, you’ll want to know some key information, such as the hostname and/or IP address of your mail server, a list of other servers you want your email to be sent from, and of course the location and login information to your DNS server.

1. Login to your DNS server. This may be through a web portal if your DNS is hosted for you by a third party.
2. Create a new TXT record. Some DNS servers have an option to add an SPF type record, but you should still always use a TXT type record. When choosing a record name you can put “@” or leave it blank.
3. Input your SPF email rule in the section marked text or value. Make sure it begins with the version syntax and ends with an “all” qualifier.
4. Note that after publishing your SPF email record, it may take up to 48 hours to take effect.

Depending on your goals, a simple SPF email record with one server might not be enough. For example, SPF does not automatically encompass subdomains. You’ll need to include each subdomain in your record. In addition, some systems have a 255-character limit for your SPF email record. If you're approaching the limit, you can do the following to shorten your record:

• Remove any ptr mechanisms. These are deprecated and count against your lookup limit and word count.
• Check your sending address range. If you have many different IP addresses those can often be abbreviated by specifying the whole subnet rather than individual servers.
• Clean up old vendors. Over time you may stop using specific email services, check your records to verify that you are still using that server to send from.
• Use Fortra-hosted SPF: Our hosted records have a shorter character length but can effectively include more service providers within those characters.

And remember, SPF alone for email does have its limitations. As a result, it’s important that the SPF email standard isn’t the only email security you have in place. Having proper DKIM email and DMARC email records are key to ensuring email is secured on multiple fronts.

Enterprise clients may find it useful to use a product like Fortra DMARC Protection to help automate the implementation work.