What is Sender Policy Framework?

History of the Sender Policy Framework (SPF)

The first mention of SPF dates back to 2000, but back then it stood for “Sender Permitted Form” instead of “Sender Policy Framework.” Between 2000 and 2014, SPF underwent a name change and evolved from an experimental email authentication standard to the final version of SPF we know today.

Sender Policy Framework isn’t the most complex or thorough method of email authentication, but it is a fundamental element of protocols such as DKIM and DMARC, and still plays an important role in authenticating email messages.

What is an SPF record?

An SPF record is a TXT record published in the Domain Name System (DNS). This DNS TXT record contains a list of all the IP addresses that are authorized to send emails from a given domain. In the case of your company, that would mean all of the IP addresses of your company’s servers and domains.

For instance, if you have multiple sending IP addresses, you can indicate all of them on your SPF record. This lets your recipients’ email services know those IP addresses are allowed to send mail on behalf of your domain. On the contrary, it also tells email servers that mail coming from an IP not listed on your SPF record isn’t really coming from your company and should be rejected.

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, SPF is instantly operational.

The Sender Policy Framework process starts with the receiving email server looking at the domain identified in the return-path address of the email message, which is the address the email should go back to if it gets rejected.

The receiving email server checks to verify if the sending IP address is on the domain’s list of approved senders (as recorded in the SPF record). If it is, it is approved and the email continues to be processed for delivery.

Do I need SPF?

Yes. Implementing SPF is crucial to safeguard your sender reputation by ensuring only legitimate messages are sent from your domain. An SPF-protected domain is less attractive to fraudsters and therefore less likely to be blacklisted by spam filters.

Without SPF, you won’t be able to do any sort of technical vetting of the emails using your domain. There won’t be any indicator if an email landing in your recipient’s inbox originated from an unauthorized domain, and malicious mail will move freely to recipients as if coming from your domain. This can damage your reputation.

There really isn’t any reason not to set up an SPF record.

How do I set up my SPF record?

There are five steps businesses sending email should follow to properly build an SPF record:

1. 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.

2. 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 protected.

3. Create the SPF record. This can be nuanced and often requires close collaboration with your IT team and email service provider. See below for technical details.

4. Publish your SPF record to DNS. Work with your DNS server administrator, IT department, or email service provider for support.

5. Test. There are free tools to check your SPF record, which will result in a complete list of IPs authorized to send mail from your domain. Make sure they’re all listed, and if they aren’t, go back to fix the record.

Benefits of proper SPF implementation

Proper implementation of SPF records can be a game-changer for your email security. Here’s how.

It protects against domain impersonation

Including SPF in your DNS record helps ensure that only legitimate messages sent from your domain are allowed into recipients’ inboxes. Only those who send messages from authorized IP addresses will be able to do so on behalf of your domain, and SPF checks will catch email spoofing attempts.

It improves domain reputation and email deliverability

Having malicious senders send email on behalf of your domain can gravely damage your reputation, both with your subscribers and with receiving mail servers and clients.

Subscribers will see you as untrustworthy if you send them spam, malware, and other harmful messages. This will result in them not opening your future emails, sending you to spam, or even unsubscribing—all signs for receiving email servers to send you to spam as well.

In this sense, proper implementation of SPF records doesn’t just keep your subscribers safe, it also helps protect your email deliverability.

It sets the foundation for Domain-Based Message Authentication, Reporting & Conformance (DMARC) authentication

Together with the other email authentication protocol DomainKeys Identified Mail (DKIM), SPF forms the foundation for the DMARC authentication framework. DMARC allows domain owners to specify what they would like to happen in case an email sent from their domain fails an authentication test.

SPF troubleshooting and testing

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.

FAIL and forwarding

One downside to Sender Policy Framework is that it stops working when an email is forwarded. The moment someone forwards an email, they’re seen as the sender of that email. If the forwarder’s IP address is not included in the SPF record, their mail will be rejected even though they’re forwarding a legitimate email message. Thus, SPF failure occurs.

In essence, the SPF record breaks when the mail is forwarded outside of its intended path. If the forwarder doesn’t change the return-path address and isn’t safe-listed by the domain owner, their email message will be rejected by the recipient server when SPF is checked.

To prevent an SPF fail for emails sent by trustworthy senders outside of your organization, you can establish an SPF policy including forward mechanisms that guide recipient email servers during the DNS lookup stage.

Examples of Sender Policy Framework mechanisms

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

• “+” means Pass. If the Pass SPF mechanism is detected, the mail is authorized for that IP and passes authentication.
• “-” means Fail. The Fail SPF mechanism indicates that the IP address is not authorized to send mail. The mail will not continue transmission.
• “~”is a Soft Fail. When a soft fail SPF occurs, the IP address may or may not be allowed to send mail from the domain. These emails won’t be blocked—they will typically be sent to subscribers’ spam folders and marked as suspicious.
• “?” 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 that won’t resolve. This could mean the SPF record isn’t configured properly.
• Temperror: This means 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 and knowing what your bounce codes mean, you’re leaving the issue unaddressed and your problems will continue. There are free resources to help you monitor your SPF record, plus Validity provides this data in its Everest platform.

HELO tests

In a way, sending and receiving mail 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 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.

Why SPF is not enough

SPF works only when there is an SPF record that lists the authorized IP addresses. So what happens if there isn’t? In that case, the recipient server will still process it, but it won’t be able to rely on DNS records to authenticate the email.

This can happen when legitimate email is forwarded or when an email is truly malicious.

When the SPF record is vague (or non-existent), the SPF check doesn’t work. That’s why you need additional email authentication standards, such as DKIM and DMARC. These provide multiple layers of authentication for increased protection against malicious spoofing attacks.

DKIM is a protocol that allows senders to claim responsibility for sending emails by cryptographically adding a signature in email headers. Email clients can read this signature and use it to verify whether the email truly comes from the domain it claims to come from.

DMARC is a protocol that decides what should happen to an email when it fails both SPF and DKIM verification. Senders can set a policy of “do nothing,” “quarantine,” or “reject.”

To optimally secure your email sender reputation and prevent spammers, hackers, and other illegitimate senders from sending email on your behalf, senders should implement all three protocols: SPF, DKIM, and DMARC.

Validity Everest supports Sender Policy Framework

Our email deliverability platform Everest proactively monitors the health of your sending infrastructure by tracking Sender Policy Framework. Everest makes it easy for senders to view their authentication status for each send and provides them with the insights they need to know if protocols are working correctly or if any issues arise that could lead to attacks.