What is SPF?

Robust email performance is an art form. 

Some tactics are clear, like sending useful and engaging content. But there are other ‘infrastructural’ methods you can set up to make reaching your target email stats easier.

If your thoughtfully crafted email fails to land in a person’s inbox, it doesn’t always mean that the content is bad. Instead, the reason your email was quarantined may simply be because you didn’t implement certain email authentication protocols that allow servers to confirm your identity and validate your emails.

The Sender Policy Framework (SPF) is one of three essential email protocols you have to implement to ensure your emails reach inboxes: SPF, DKIM, and DMARC. 

In this post, we’ll explain what SPF is, how it works, and how you can set it up.

What is the Sender Policy Framework?

SPF allows domain owners to whitelist all email servers that are authorized to send emails from their domain. This authorization also provides protection against spoofing.

It’s similar to a car manufacturer’s list of authorized part distributors. 

If you check the manufacturer’s website and can’t find the business you want to buy parts from, that distributor may not be legit and the parts might not be genuine. 

But if the manufacturer’s website does list the distributor, the manufacturer is essentially saying the seller is official, the parts are genuine, and you can trust that seller.

SPF’s protection of emails works similarly. 

When an email with your name in the “From” field arrives from a server that’s not included in your SPF record, security systems get triggered and they send an alert that there’s an attempt at spoofing. 

But if an email bearing your name comes from an SPF-authorized address, the receiver’s server deems it safe.

What does an SPF record look like?

An SPF record is a specially formatted line of text that stores a list of authorized mail servers for your domain.

An SPF record consists of:

• A prefix that identifies it as an SPF record
• A formatted list of servers that are identified by their IP addresses
• An “-all” ending telling the recipient’s server to reject all emails coming from addresses not included in the list

Some SPF records use “~all” as an alternative ending. This allows a server to accept emails from unlisted addresses, but such emails will be marked as spam.

It’s important to note that there can only be one SPF record associated with a domain. 

Although some email authentication methods allow the use of multiple lists (such as DKIM), the SPF protocol does not allow multiple records.

Brief explanation of SPF record syntax

The syntax of SPF records defines which servers are authorized to send emails on behalf of a domain.

Here’s a simple breakdown:

Here’s what each part means:

• v=spf1 – This specifies the version of SPF being used (always v=spf1)
• Mechanisms – These are rules that determine which IP addresses or domains are allowed to send emails. Common ones include:
  • ‘ip4’ or ‘ip6’: Allows specific IP addresses
  • ‘a’: Matches the domain’s A record
  • ‘mx’: Matches the domain’s mail servers (i.e. MX records)
  • ‘include’: Allows other domains (e.g., include:_spf.google.com)
• Modifiers – These define how mechanisms are treated. These are the possible results:
  • + (pass): Default
  • - (fail): Emails from unauthorized sources are rejected
  • ~ (soft fail): Emails from unauthorized sources are accepted but marked as spam
  • ? (neutral): No specific action to take
• ~all – Ends the record and allows servers to treat emails from unlisted addresses as spam

Here’s what this might look like in action:

This means:

• Allow emails from the IP address 192.168.0.1
• Include other authorized servers with the domain example.com
• Treat all other emails as spam

How does SPF work?

The process of email authentication using SPF can be broken down into three main steps:

• Publishing the SPF record
• Performing Domain Name System (DNS) lookups
• Verifying the SPF record

Publishing the SPF record

After you set up an SPF record (more on that later), you’ll need to publish it in your DNS so it’s available to everyone who needs to verify the authenticity of your email.

Performing DNS lookups

When a server receives your email, it extracts your domain name from the return-path address (an address to send bounced mail to, hidden in your header) and looks up an SPF record for this domain in your DNS records.

If you have an SPF record, the server uses it to verify the sender’s address.

Verifying the SPF record

The server searches the SPF record for the sender’s IP address. 

If the address is on the list and marked as authorized, the email goes through to the receiver. 

Otherwise, the email fails the server’s SPF check and the server may bounce the email back to the return-path address, delete it, or flag it as spam.

Why is SPF important?

On February 1, 2024, Google released new guidelines that mandated SPF or DKIM for everyone sending emails to Gmail accounts. 

However, SPF offers more than just compliance with Google’s policies.

A published SPF record makes it harder for malicious parties to impersonate your domain. 

Although it doesn’t guarantee 100% protection, your recipients will be safer from spoofing or phishing attempts when opening your emails. 

Here’s a bit of a closer look at how SPF enhances email security and deliverability.

Greater email security and trust

The Simple Mail Transfer Protocol (SMTP) – a standard communication protocol for emails – provides no protection against someone using the “From” field to pretend to be you. 

SPF makes sure the email was sent from an authorized server, regardless of what name is in the “From” field, which delivers an important layer of security.

Improved email deliverability

Without a published SPF record, receiving servers may not trust emails from your domain. As a result, emails may bounce or get marked as spam.

Too many bounces can tank your sender reputation with mail servers, which means your future emails become even more likely to be filtered away. 

When you use SPF, your emails will almost certainly reach their recipients instead of bouncing. Over time, this improved deliverability will add up, earning you an excellent reputation with mail servers.

DMARC compliance

Setting up SPF is an important step to compliance with the Domain-based Message Authentication Reporting and Conformance (DMARC) protocol. 

If you have neither SPF nor DKIM properly set up, your messages will probably bounce or be quarantined when sent to someone who uses DMARC.

Role of an SPF record in email authentication

SPF records play an essential role in email authentication since they state which servers can send emails on behalf of your domain.

Before accepting emails, receiving servers check the SPF record. If the sending server isn’t listed, the email can be flagged as spam or rejected.

How does Sender Policy Framework protect against spoofing and spam?

Here’s how SPF protects you from spoofing and spam:

• Verifies the sending server – SPF checks that emails are coming from servers in the domain’s SPF record. If a server’s not there, the email is likely fraudulent.
• Prevents domain spoofing – SPF blocks attackers from impersonating your domain by only allowing specific IP addresses to send emails via your domain.
• Supports spam filtering – Email providers use SPF as a factor in spam filtering, rejecting or marking as spam any emails that fail SPF checks.

How to set up SPF

There are three steps to carry out to properly set up your SPF.

Identify all sending mail servers

To start, you need to know what domain or domains appear in your return path. It might be just one that’s the same as your domain, but not necessarily.

Google and some email service providers (ESPs) use your domain in your return path. 

However, there are ESPs such as Postmark that use their own domain instead of yours. In this case, there’s no need for you to set your own SPF as your provider’s probably using it.

If you discover your own domain name used in the return path, you can proceed to the next step.

Construct the SPF record

Check the ESP’s documentation and verify the correct format for how their address should appear in your SPF record. Copy it into a .txt file.

If you use multiple tools to send email (e.g. Google, Mailchimp, and HubSpot), make sure to add all their IP addresses (or domain names) to your SPF record. 

If and when you need to add more sending addresses, put them in the same SPF record. 

Never create a new SPF record for your domain. This is a common error that causes emails to fail SPF checks. Remember, a domain can have only one SPF record.

Publish the SPF record in your DNS

To publish your SPF record, follow your DNS provider’s specific instructions. In most cases, that means navigating to the DNS settings menu, adding a new .txt record to your domain, and then copying your SPF record into it. 

In some cases, you can upload the .txt file containing the SPF record directly to the DNS records.

With this, your SPF is all set! Now you can engage your audience more effectively and build a robust sender reputation.

Benefits of proper Sender Policy Framework implementation

Within the greater context of email security, these are the benefits of proper SPF implementation:

• Prevents email spoofing by blocking unauthorized parties from sending emails that appear like they’re from your domain
• Improves email deliverability by not flagging emails from authorized servers as spam
• Protects brand reputation by reducing the risk of your domain being attacked by spam and phishing
• Increases trust among recipients by building credibility with email providers
• Strengthens overall email security in tandem with DKIM and DMARC