What Is Sender Policy Framework (SPF) In Email Authentication And How Does It Work

Email authentication is a series of checks that verify whether an email is received from a legitimate source, and are who they say they are. Email authentication helps reduce spoof and spam emails, and if configured, filters them out into separate junk and spam folders.

There are three main email authentication technologies in use today: SPF, DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication Reporting and Conformance (DMARC). All of these work together to provide maximum security and privacy for your email account and mail servers, and prevent you from falling victim to email spoofing, where a spammer may ask you to divulge sensitive information by pretending to be someone they are not.

While not all three need to be configured on a mail server, they do provide maximum security through maximum-possible authentication mechanisms. However, you may only configure SPF or DKIM for authentication purposes, but those would leave loopholes for spammers to get through. That said, DMARC cannot be configured without setting up DKIM and SPF, since DMARC builds on top of these technologies.

Learn the key differences between SPF, DKIM, and DMARC.

To begin, in this post, we only emphasize SPF, what it is, how it is used, what it does, and how to set it up for authentication.

What is a DNS SPF Record

Before delving into SPF, let us understand what a Domain Name Server (DNS) is. A DNS is a directory that stores the names of different names against their IP addresses. So when you enter a URL in your browser, the request is initially sent to your DNS, which resolves it and then reroutes the traffic to the server where the webpage is located against the propagated IP address.

However, the functionality of the DNS does not end here. Other information stored on a DNS is also useful, such as the MX record, or the DNS TXT record. A “text” record stores information in plain text, and with special syntax, it is also used to store SPF as well as DKIM records. Therefore, an SPF record becomes a DNS TXT record.

The SPF record stores the information for the servers that are allowed to send emails to it. If the sending mail server is allowed, it would be included in the SPF record of the receiving server, and the SPF check would PASS, making the email land in your inbox. However, if the record for the sending server is not found in the SPF record, the SPF check would FAIL, and the email would either be rejected or land in the spam folder, depending on the SPF configuration.

You can think of SPF as a bouncer outside a party – if you aren’t on the list, you are not allowed inside.

Why SPF Records are used

As mentioned above, SPF records enhance the security of your emails and prevent spammers from spoofing emails, which practically allows them to become someone they are not. For example, if I am a member of the “itechtics.org” domain, they can manipulate the header of an email and make it seem like they, too, are a member of “itechtics.org”, and ask for sensitive information.

I, thinking that they are a legitimate user, might even provide them with the information requested.

Not only that but SPF records also serve other purposes, which are as follows:

• Preventing cyber attacks: If emails are not authenticated, organizations and individuals 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.
• Improves email deliverability: Email deliverability refers to the likeliness of an email ending up in the Inbox, instead of the junk folder, or being rejected. 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 its audience’s inboxes, compromising efforts to communicate with customers, employees, and other entities.
• DMARC compliance: DMARC basically instructs which emails to be allowed to pass through, which to reject, and which to send to the spam folder. These decisions are based on both the DKIM and the SPF records and their checks. Therefore, indirectly, the SPF records control how the incoming emails are filtered.

How SPF works

Understanding how SPF works is both simple and somewhat complicated at the same time. It’s simple because it basically cross-matches an existing record with the incoming record, and allows it to pass if they match; if not, the main is rejected. However, it gets complicated when you learn how SPF checks the incoming email for the sender’s information.

Do not worry. Here, I have explained both information as simply as possible.

Here is an example to understand the basics of how SPF works:

1. I send an email to my colleague from subhan@itechtics.org using my Google Workspace server.
2. Gmail, which is the receiving server for my colleague, receives the email.
3. Since the domain for my email is “itechtics.org“, the Gmail server will look up the DNS records for the domain.
4. The server finds the DNS records for “itechtics.org” which also declares an SPF policy, allowing itechtics.org to send emails.
5. Since the email was sent from “itechtics.org”, it passed the SPF test, and the email will land in my colleague’s inbox.

Now what would happen if the SPF record did not include the “itechtics.org” domain? The Gmail server would then either reject the email or send it to my colleague’s spam folder. This depends on how the SPF policy is configured. We shall discuss that below. But before that, we shall clear up how SPF checks the sender information from an incoming email.

Mail From vs. From Header

When you open an email, you find the metadata, including the email’s information, like who it was sent to, who it was sent from, the timestamp, etc. This is the FROM field that the user sees, known as the FROM HEADER. However, it is not the information that the SMTP protocol uses to route the email. Instead, it uses a completely different MAIL FROM hidden inside the “envelope“.

Note: You can view the full FROM HEADER by going to the email menu and clicking either”View original” or “View raw message“, but it will only show the FROM HEADER and other email information, and not the information in the envelope.

Think of the email as a physical letter. There is the content, which is the email itself, and then there is the envelope containing the content. The carrier (servers) uses the address on the envelope to deliver the letter. Note that this MAIL FROM might be entirely different from the FROM HEADER. This Mail Form is also referred to as Envelope From, Return To, or Bounce Address.

It is the same information the mail servers use to send bounce notifications when an email is not delivered. Moreover, it is the Envelope From a receiving mail server used to look for its DNS records when performing an SPF check.

What are SPF Record Mechanisms, Qualifiers

An SPF record looks something like the following example:

v=spf1 +a +mx ip4:65.181.111.142 ip4:65.181.111.145 include:spf.examplesender.email ~all

By the looks of it, an SPF definition can look confusing, but we are here to explain what it all means.

The example above is how you define an SPF policy in a DNS TXT record. It has different parts and each serves a different purpose. Each segment of the SPF record is known as a “mechanism“, and all of them are considered from left to right, with the exception of “all“. The “all” mechanism is meant to be the last one, and no mechanisms after it are considered.

Moreover, some mechanisms have a qualifier, which are the symbols (+, -, ~, ?). These also serve a purpose, which is explained below:

• v=spf1: Defines that this TXT record contains the SPF record for the server.
• a: Defines the policy for when the domain’s name has an address record (A or AAAA) that can be resolved to the sender’s address.
• mx: Defines the policy for when the domain name has an MX (Mail Exchange) record resolving to the sender’s address.
• ip4: Defines the IP addresses for the sending mail servers that are allowed. “ip6” can also be used to define IPv6 addresses.
• include: This mechanism defines another domain, that is not in your control, who’s SPF record should be considered the server’s own. In other words, the content of the SPF record for the other domain should be checked and the IP addresses it contains should also be considered authorized to send emails. An SPF record can contain more than one domain with this mechanism. However, this tag will only function with legitimate domains.
• redirect: Performs a similar function to “include”, but the difference is that this mechanism should be used for domains that are in your control.
• all: Defines how the addresses and domains not listed in the SPF should be handled. The adjacent qualifier defines how to handle them.

I understand that some of the mechanisms above can be confusing, which is why it is also important to understand the qualifiers. The following table explains the different qualifiers:

Note that defining a qualifier is optional, and not mandatory. Therefore, you may come across SPF records that use “+a +mx“, or even “a mx” without the qualifiers. If no qualifier is defined, the default value resorts to “+“.

That said, you will always find a qualifier next to the “all” mechanism in DNS SPF records. This is because it defines how to handle the servers that are not mentioned in the SPF record. This is what the different combinations of qualifiers and the “all” mechanism mean:

Limitations of DNS SPF Records

While defining SPF records is a straightforward process, when you understand it, it has its limitations. If you are not careful, an SPF record may not be correctly defined, and your emails may start being rejected or end up in the spam/junk folder.

Here are a few things to consider when configuring an SPF record:

• There cannot be more than one SPF record associated with a domain.
• The record must end with the “all” mechanism or include a redirect= component (which indicates that another domain’s SPF record).
• An SPF record must not contain uppercase characters.

Lookup SPF Record

Looking up an SPF record means checking the SPF record details for a domain. There are a plethora of tools available for finding the SPF details for any domain, such as the Email Validation Tool. If you run this tool, you can determine the SPF policy defined for a domain, such as in this example:

As you can observe, the qualifier is available for numerous mechanisms. You may also observe that certain mechanisms may even exist if they are not defined in the SPF record. This is because some mechanisms, as well as their qualifiers, are appended automatically, if not explicitly defined.

Here is what the mechanisms and qualifiers in the example above mean:

• +a: The SPF record contains an A or AAAA address against the domain name. If the SPF record does not have a defined IP address, the field will not appear.
• +mx: The SPF record contains a mail exchange record for the domain name. If the DNS record does not have a defined MX record, the field will not appear.
• +include: The domain is allowed in the SPF record.
• +ip4: The IP address is defined within the SPF record.
• ~all: Emails from unlisted servers will be accepted but marked.

How to set up DNS SPF Records to authorize emails

Normally, the SPF records are automatically set by your email service provider or your IT administrator. However, in case you are having trouble authorizing email, or keep getting mail in the spam folder which is actually legitimate, there might be something wrong with your SPF configuration.

Before configuring a new SPF record, it is recommended that you use an email verification tool to confirm whether an SPF record exists for your domain, and if it is configured correctly. In case you need to configure a new one, here are the steps to set up SPF records on a DNS server:

Note: Each DNS server might have different configurations and settings. However, the same logic and syntax apply.

1. Log into the DNS server as an administrator.

2. Click “Add Record” and then click “Add TXT Record“.

   

3. Enter your domain name.

   

4. Now use the following syntax while using the information according to your scenario and paste it in the Record field:

   v=spf1 +a +mx +ip4:[IPAddress] include:[DomainName] ~all

   Note that you must change the variables in the square brackets [] according to the IP address and the SPF records of the domain(s) that you want to allow. You can optionally include the “+a +mx” mechanisms. Moreover, you can adjust the qualifier for the “all” mechanism as well.

   

5. [Optional] You may adjust the Time To Live (TTL) value, which is actually how long the record will be cached for.

6. When done, click Save Record.

After performing the steps above, wait a while so the new DNS records can propagate across the internet. This can take anywhere between a few minutes to a day.

Takeaway

SPF records are a method to authenticate emails and verify that they are from the allowed sources, and are who they claim they are. However, SPF is not capable of performing an action based on the authentication results – it can only perform a check. This is where DMARC comes in.

DMARC is responsible for handling the emails based on the SPF and DKIM results. This has been discussed further in the article dedicated to DMARC.

That said, if you still are confused about how SPF works, you can refer to the original SPF documentation, or leave a comment below.