Sender Policy Framework authentication | What is SPF?

Sender Policy Framework (SPF) is an email-authentication standard used to prevent spammers from sending messages that appear to come from a spoofed domain. It also helps to ensure that emails are delivered correctly – without being delivered to a recipient's spam box.

SPF works by allowing organizations to specify the mail servers that are authorized to send out emails from their domain. This prevents anybody from impersonating the organization using a malicious process called email spoofing.

It's important to remember that organizations often have several domains. Only some of those domains are used to send emails, however. Therefore, it's essential for organizations to leverage authentication that prevents cybercriminals from exploiting the other domains to send emails that appear to come from them.

Any organization can publish authorized mail servers in the Domain Name Service (DNS) record by leveraging SPF, and this allows recipients to validate the origin of any emails received from them.

To permit this, the webmaster publishes the SPF information (a list of authorized mail servers) in the DNS TXT record. The receiving email server then checks that SPF record using an SPF record check, which looks up the SPF record to validate the sender's IP address.

What is an SPF record?

The SPF record is a list of authorized mail servers that a webmaster publishes to the DNS as a TXT record. This record permits any recipients to use a diagnostic tool (called the SPF record check) to validate the origin of an email. Setting up an SPF record is relatively easy, and it protects an organization against email spoofing attacks. 

Once the SPF record has been set up, anybody who receives an email can check that it came from a server that has been authorized. If an email originates from a non-authorized domain, the server can treat the mail as spam and exclude it by either bouncing or rejecting it. 

How does SPF protect against spam?

Having an SPF policy allows recipient email servers to verify the origin of an email. As a result, the recipient can check whether the email really comes from the sender it claims to be from. 

SPF authentication protects against email spoofing – a technique leveraged by cybercriminals to send out phishing emails and spam that appear to come from somebody else (the organization being spoofed).

SPF prevents sender address forgery by checking the envelope sender's IP address against the claimed sending domain. If the SPF check fails because the administrator has not authorized emails from that domain – the email will be treated as spam and will be bounced or rejected.

What happens when SPF fails?

When an SPF record check fails, the recipient is informed that the sender is not authorized to send an email from that domain. Then, the email server can reject or bounce the message.

During the diagnosis carried out by the SPF Record Check, it is possible that the analysis will result in one of a few different messages. We have broken down these qualifiers below to explain them:

• Pass. The SPF record designates the sender as authorized to send.
• Fail. The SPF record designates the sender as not being allowed to send.
• None. Unable to resolve the domain name in the DNS and/or unable to find the SPF record for the domain.
• Neutral. The SPF record states that it is not asserting whether the IP address is authorized. SPF neutral can be interpreted as either a Pass or Fail depending on how the server is set up, but is usually defaulted to fail.
• Softfail. This is a weak fail message that indicates that the sender is probably not authorized, This message occurred when the domain has not set up a strong SPF policy that results in a hard fail. 
• Temperror. SPF check encountered a transient error usually caused by a DNS timeout. It will usually result in a retry later, as long as the retry policy on the client is set up properly.
• Permerror. SPF check could not validate the published SPF record for the domain either because multiple SPF records were found on the domain, the SPF record is written incorrectly, the number of DNS lookups involved in the SPF check exceeded 10, the number of void lookups involved in the SPF check exceeded two. 

Limitations of the SPF record check 

An SPF check validates against the Return-Path value rather than the From header to determine the authenticity of an originating server. The Return-Path is the address used by recipient mail servers to communicate with the sender if there is a problem (to bounce an email, for example).

The problem with this is that an email recipient will see the fake From address in their email client if the email is delivered. Unfortunately, this can sometimes happen even if an email fails an SPF check depending on the receiving ISP (which makes the final decision). SPF's shortcoming has since been fixed by DMARC, a newer standard that addresses the problem by authenticating the From header instead.

Despite its shortcomings, it is always better to set up an SPF policy for your emails because it results in additional trust signals and increases the chances that an email will pass an ISP's checks to be successfully delivered rather than rejected or bounced.

How to check the SPF record for a domain

If you want to check and read a Sender Policy Framework record for a domain, the good news is that it is actually very straightforward. The SPF TXT record is stored in the DNS database and is bundled with the DNS lookup information so that anybody can access it. As a result, you can check it manually from inside your command prompt window:

What is DKIM?

DomainKeys Identified Mail (DKIM) is another email authentication standard that is vital for protecting both domains against spoofing, and email recipients against spam and phishing emails. What many organizations may not realize, is that to fully optimize their email security they should leverage SPF, DKIM, and DMARC.

DKIM functions by ensuring the contents of emails haven't been compromised and can be trusted by the recipient. It was initially rolled out in 2007 and has been updated several times since then.

What is DMARC?

Domain-based Message Authentication, Reporting and Conformance (DMARC) is a useful protocol that combines SPF and DKIM into a single coherent policy framework. In addition, it increases security by linking the sender's domain name with what is listed in the From header. 

Which email authentication protocol should my organization use?

The only way to optimize your organization's email security is to leverage all three of these important protocols. They all serve slightly different purposes, and they provide the greatest level of security when used together. 

Admittedly, setting up these standards for all your domains can be time-consuming, but it is highly important if you want to avoid sophisticated phishing attacks that lead to cyberattacks.

Generally speaking, it is always a good idea to start by setting up an SPF record – it's the most straightforward, after all. Following that, you should seek to implement DKIM, and then DMARC.

By leveraging all three protocols, you'll ensure that messages can't easily be forged and that your inboxes don't receive dodgy spoofed emails that could cause serious repercussions, such as malware infection and data theft.