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.
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.
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.
The following elements may be included within the SPF record.
And now, to put it all together…
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.
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.
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.
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:
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.