What is Sender Policy Framework?

Hidden Anchor

History of the Sender Policy Framework (SPF)

Originally, SPF didn’t stand for Sender Policy Framework. Instead, it was “Sender Permitted Form.” Between 2000 and 2014, SPF evolved from an experimental email authentication standard to the final version of SPF we know today. While it may not be the most complex or thorough method of email protection, Sender Policy Framework is the foundation on which everything else stands.

Hidden Anchor

What is an SPF record?

An SPF record is a TXT record published in the Domain Name System (DNS). This record contains a list of any IP authorized to send mail from a given domain. For instance, if you have multiple sending IPs, you can indicate all of them on your SPF record to authenticate email from those IPs sending messages on behalf of your domain. This makes it clear an IP record not listed on your SPF record should not be associated with mail originating from your domain.

Hidden Anchor

How does SPF work?

Sender Policy Framework is relatively simple in the grand scheme of email authentication. After configuring your SPF record and publishing it in the DNS, it starts to work to better ensure intended delivery.

The SPF process starts with the receiving server looking at the domain identified in the return-path address, which is the address the mail should go back to if rejected. It is checking to verify if the sending IP is on the domain’s list of approved senders (as recorded in the SPF record). If it is, it’s approved and it continues being processed for delivery.

Hidden Anchor

What is an SPF record?

A Sender Policy Framework record is a TXT string published in the DNS. It contains a list of any IP authorized to send mail from the given domain.

Hidden Anchor

Do I need SPF?

Yes. An SPF-protected domain is less attractive to fraudsters and therefore less likely to be blocklisted by spam filters. Without SPF, you won’t enable any sort of technical vetting of emails using your domain. There won’t be any indicator the mail is originating from an unauthorized domain and malicious mail will move freely to recipients with your hijacked brand. There isn’t any reason to forgo a simple method of email authentication.

Hidden Anchor

Principles of operation

While setting up an SPF record is fairly straightforward, what happens once it’s implemented is more involved. Behind the scenes, there are several factors that can impact the effectiveness of SPF authentication.

Hidden Anchor

FAIL and forwarding

As mentioned before, forwarded mail can complicate Sender Policy Framework results. If a domain configures the record to include an SPF FAIL policy, unless the forwarder follows a series of steps, the mail will be rejected even if it is legitimate.

In essence, the SPF breaks when the mail is forwarded outside of its intended path. If the forwarder doesn’t change the return-path address, nor is the forwarder safelisted, the message will be rejected by the mailbox provider when SPF is checked.

If you publish an SPF FAIL policy, MBPs will need to rely on other signals to try and identify if your email is legitimate prior to delivering the message.

Hidden Anchor

HELO tests

In a way, both sending and receiving servers talk to each other back and forth. When a message arrives, the incoming mail uses a “HELO” command, much like two people would say hello to each other when greeting. Sometimes the command reads “EHLO,” but the intent is the same. The receiver then responds with “250” and the sending server relays the intent. This begins the process to open a connection to the SMTP server.

If the receiving server gets information they can verify, they give a “250 ok” to indicate the message is received and good to go for delivery.

If there are SPF issues during this exchange, the mail is pushed back via the return-path.

Hidden Anchor

Why SPF-only isn’t safe enough

What happens if the SPF record doesn’t list the sender’s IP? The server will process it. There are a few ways this mismatch could have happened, such as legitimate mail being forwarded or it truly being dangerous mail. Because the SPF record is vague, it isn’t a way to truly block mail. Additional email authentication standards, such as DKIM and DMARC, can provide multiple layers of authentication for increased protection against malicious spoofing attacks.

Hidden Anchor

Implementation

Sender Policy Framework details can get very complex. Some of the information is so in-depth and technical, it wouldn’t be a good use of a marketer’s time to try to master it. But mechanisms are key in understanding results of SPF lookups.

Hidden Anchor

Mechanisms

When creating your SPF record, you dictate which IPs are safe. However, you can also add IP addresses which shouldn’t immediately be granted permission to be transmitted. These are called “mechanisms,” and they help the decision-making involved in a lookup.

“+” means Pass. If this mechanism is detected, the mail is authorized for that IP and passes authentication.
“-” is Fail. Of course, this means the host is not authorized to send mail. The mail will not continue transmission.
“~”is a Softfail. This also means the IP is not allowed to send mail from the domain, but it is still continuing its journey.
“?” indicates Neutral. There are no matches for the mechanisms listed, and it’s designated as a neutral result.

Bounce codes can give you further insight into lookup results.

None: There isn’t an SPF record to look up. Alternatively, the SPF lookup doesn’t return any results at all.
Permerror: Like the name indicates, there is a permanent error which won’t resolve. This could mean the SPF record isn’t configured properly.
Temperror: There was an issue during transit but it’s not related to an error that can’t be fixed during the deployment. For instance, there might have been an issue when retrieving information from the DNS.

These mechanisms allow you to rectify issues in your Sender Policy Framework. Without monitoring or knowledge of what your bounce codes mean, you’re leaving the issue unaddressed and your problems will continue. There are free resources to help you figure this out, plus Validity provides this data in their Everest platform.

Hidden Anchor

FAQ

Hidden Anchor

How do I set up my SPF record?

There are five steps any email marketer should follow to properly set up and implement their SPF record.

Collect all IPs sending mail on behalf of your domains. Don’t forget, you need to list every single one. Is there a server for internal mail? Make sure to include it so your in-office mail travels without issue. Would you like your recipients to forward mail without it bouncing? Add the IP addresses of the mailbox providers of the individuals on your mailing lists.
Make a list of your sending domains. It is important to create SPF records for all domains, even those you’re not emailing from. Criminals are likely to spoof your non-sending domains if they are not also protected.
Create the SPF record. This can be nuanced and often requires some advanced knowledge of SPF mechanisms. This setup resource has in-depth guidance for building your record.
Publish your SPF record to DNS. Work with your DNS server administrator, IT department or email service provider for support.
Test. There are free tools to check your record, which will result in a list of IPs authorized to send your mail. Make sure they’re all listed, and if they aren’t, you can go back to fix the record.

Discover how Everest can help you set up and monitor proper email authentication to keep your program safe and secure.

Learn More

Email Authentication

What is Sender Policy Framework?