What is SPF

What is SPF

Sender Policy Framework (SPF) is an email authentication protocol that domain owners use to specify the email servers they send emails from, making it harder for fraudsters to spoof sender information.

SPF email policies are widely used across the globe and are currently defined by the IETF under section RFC 7208. You can think of SPF 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 records important?

SPF records play a key role in email security because they ensure that 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 look at what strong SPF email policies can do.

  • 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 server’s overall deliverability.
  • Combat email spoofing: An SPF 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 in place gives your domain an 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.

 

 

How do SPF email records work?

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 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 are the action that is ultimately applied when a mechanism is matched. If no qualifier is listed, the default + is used. Below are the four types of qualifiers that can be used when configuring SPF email policies.

Chart explaining the various symbols and actions taken for SPF records.

The following elements may be included within the SPF 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 fail anything else.
    • Example: v=spf1 a ~all
  • all: Found at the end of the SPF 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 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 a 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 to 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 sender’s 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

And now, to put it all together…

 

What does an SPF record look like?

Below is an example of an SPF 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 the above example, this SPF 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 softfail.

To better illustrate how SPF 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. 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 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 softfail and allow it to be sent.

 

 

How do I know if I have an SPF email record?

If you have access to the DNS server your mail server uses, you can look for a TXT record that begins with “v=spf”. An easier way to check any domain is to use the Agari SPF Lookup Tool. This allows you to quickly lookup SPF records to verify their existence and settings.

 

How do I create an SPF record?

If you don’t have an SPF record, you can easily create one. However, there are some steps to take before creating your SPF 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 the 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 record, it may take up to 48 hours to take effect.

Depending on your goals, a simple SPF 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 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 Agari-hosted SPF: Our hosted records have a shorter character length, but can effectively include more service providers within those characters.

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