Sender Policy Framework (SPF): Email Authentication Protocol

“Malicious actors send 3 billion spoofed emails every day and since 2016, organizations have lost over $26 billion due to email attacks” (Source: CNBC)

Email phishing and spoofing are the two most widely used attack vectors to create widespread havoc. The absence of email authentication standards can incur immense financial and reputational damage to the organization. There are several standards and protocols that are implemented to improve the authenticity of outbound emails. They are SPF, DKIM, and DMARC. Each of these has its respective role and application.

SPF is one of the popular email authentication standards that came into being around the early 2000s. It was taken into consideration when it occurred that SMTP (Simple Mail Transfer Protocol) has certain limitations. And now, 20 years down the line, the sender policy framework has become an essential element for the cybersecurity of an organization.

What is the Sender Policy Framework (SPF)?

The Sender Policy Framework is an authentication technique that is used to mitigate the risks of email attacks. Its primary objective is to prevent phishing by detecting email forging and spoofing. This policy uses technical methods to record DNS (Domain Name Service) and IP addresses so that they can be verified once an email is exchanged between two email servers. 

In common terms, it prevents cybercriminals or spammers from sending emails on behalf of the organization’s domain. There are various methods to stop email phishing attacks. The SPF enhances the level of authorization of email servers. The primary application of SPF is to assist organizations’ domains to prevent spoofing and prevent outbound emails from being marked as spam. 

Example of an SPF

SPF contains a series of text in the form of the syntax that contains the record of an IP address with a specific mechanism. One example is considered below.

“v=spf1 ip4:166.5.50/24 ip4:138.54.200.145 a -all”

• The parameter ‘v’ designates the version of SPF
• The parameter ‘ip4’ designates the mechanism in the IPv4 network, where prefix length is assumed to be 32
• The parameter ‘a’ designates the test of the domain record which contains the domain name of the organization
• The parameter ‘all’ designates the match of the SPF record
• The parameter ‘-’ just before all designates one of the four quantifiers for implementing the mechanism

More details on quantifier significance and its designation are explained later in the blog.

How does SPF Work?

Every email has a header attached to it. When an employee from your organization sends the email, its header includes the ‘Return-Path’ value of the domain. Thus, the Sender Policy Framework works by looking for the same ‘Return-Path’ value across the domain.

As the email reaches the receiving end, the receiving server checks this value and extracts the sender domain’s SPF record. The receiving server tries to verify the domain IP address with that of the SPF record. If there is a match, then the receiver server authenticates the email domain.

The receiver server checks the senders’ email addresses along with their IP addresses in the SPF record. This is done by checking the TXT record of the DNS. The overall method of verifying the email from a domain can be stated in the following steps:

1. The administrator of an email domain establishes a policy that contains the names and information of email servers that are to be authorized. This policy is stored in the form of an SPF record, which is listed in the overall DNS records.
2. When a mail server receives an incoming email, the policy framework seeks bounce rules (return path). Then, the inbound mail server conducts a comparison of the IP address from the sender’s mail server with the IP addresses listed in the SPF record.
3. Upon verification and designation of rules, the domain’s record makes a decision on whether to accept, reject or flag the email.

How to Set Up SPF?

There are some fundamental steps that are essentially carried out to set up the senders’ policy framework. They are-

Step 1: Collecting IP addresses from which emails are to be sent

In this step, the sender policy framework implementation requires the identification of the mail servers of an organization. These servers are the email service provider’s servers, web servers, office mail servers, end-user mailbox providers, or any third-party servers.

Step 2: Compose a List of Sending Domains of the Organization

The SPF record must contain a list of all the domains that are associated with the organization. These domains must be protected with SPF even if they aren’t used for sending mail.

Step 3: Create a Sender Policy Framework Record

The purpose of this policy is to authenticate email by comparing the IP address of the sender with the list of IP addresses in the record. Thus, these records are created to create an exhaustive list of addresses that will be used for authentication. The creation of the record is described later in the blog.

Step 4: Sender Policy Framework is Published on DNS

The DNS  server administrator publishes the records to DNS. The domain provides a web-based application for it. On the other hand, an external tool can be employed to carry out the whole procedure.

Step 5: Validation and Testing

This step involves testing the record using the sender policy framework checker tool.

What are SPF Records?

An SPF record is a DNS record, which is a database of records. These records are used to map a particular URL to a respective IP address. They are stored on DNS servers, or more commonly, email domain servers. These servers act as a medium of connection between an organization and the outside cyber world. 

An SPF record registers the pool of IP addresses that are associated with the senders’ email server. When emails from your organization reach the receiver’s end, the receiver’s domain server starts checking the SPF record, based on the DNS record and authenticates your email. When the email authentication is completed, it is sent to the email application and becomes visible in the inbox of the receiver.

How to Implement SPF Record?

The implementation and registration of the domains in the SPF record is an easy task. If a company or an organization wants you to register their domain in your SPF record, they will send a description of their entry. The domains may have one SPF record each whereas the record can specify multiple servers.

The Sender Policy Framework record is implemented in the form of a DNS TXT record, which can have a maximum character size of 255 characters. The size of this TXT file should not be more than 512 bytes. The procedure of implementation involves a syntactic understanding of the elements that comprise the SPF record. Each of the elements has a respective set of parameters, which designate particular conditions and activities for various situations. 

From the example of the SPF record which is used above, you can understand the basic structure of the syntax of the record consists of quantifiers and mechanisms. There are four quantifiers and eight mechanisms, where each of them is to signify a set of records, which has a specific application in terms of implementation. Finally, the created record is placed on the domain server.

SPF Record Syntax Mechanism

The notion of the SPF record mechanism is to describe There are primarily four qualifiers, where each of them is represented by one of the following prefixes: 

• “+” (Pass): This indicates an SPF record to allow ‘send’ from hosts and the intended action is ‘Accept’.
• “-” (Fail): This indicates the SPF record to NOT allow hosts to send, and the intended action is ‘Reject’.
• “~” (SoftFail): This indicates an SPF record to NOT allow hosts to send but let it in ‘transition’, where the intended action is ‘Accept but Mark’.
• “?” (Neutral): This indicates the SPF record explicitly states nothing for validity, and the intended action is ‘Accept’.

What is the Record Checker?

The SPF record checker is a diagnostic tool that performs the comprehensive role of SPF record lookup and validator. This tool is used to look for a specific domain name in a record, display it, and run a series of diagnostic tests such as SPF validation that highlight the errors that could have an adverse impact on email delivery. 

The record allows the organization’s domain to publish a list of subnets and IP addresses, which is further used to authorize emails on behalf of the organization. The purpose of this tool is to ensure spam reduction and fraudulent activity.

Limitations of Sender Policy Framework?

The Sender Policy Framework is an excellent technique implemented for email authentication. And yet it has several limitations that an organization must be aware of to employ resolution tools. Some of those limitations are:

• They do not validate or authenticate the ‘From’ header. This header is visible for most of the senders and they cannot be validated. 
• They can not be validated if the emails are forwarded, because the forwarding domain becomes the sender. Thus, the genuineness of the original sender cannot be ensured.
• There is no mechanism of reporting. 

Email Security is the Main Defense Against Cyber Attacks

SPF itself is not a complete solution. It is often required for cyber experts to implement other email authentication techniques such as DKIM and DMARC, along with SPF, to provide a comprehensive solution. Thus, it is very important for organizations to implement this authentication technique to ensure that emails are not spammed or spoofed. The primary role of SPF is to enhance the authenticity of outbound emails for the organization.

The implementation of SPF is a challenging and technical task. It requires a highly technical expert, who has to carry out the process of SPF implementation very carefully. There are multiple chances of errors, and a single mistake can destroy the reputation and authenticity of the whole domain of the organization. That’s why implementing SPF is a tedious process that is also risky. So, an organization should employ tools that can implement SPF easily and risk-free. 

How would you implement SPF in an appropriate way?

TDMARC brings a dynamic way of implementing smart SPF that carry out prominent procedure of eliminating and whitelisting IP addresses. It provides interactive interface to make SPF record and update in DNS server.

TDMARC is the best tool on the market that provides a simple mechanism to implement SPF, DKIM, and DMARC. The biggest advantage of using TDMARC is that it provides an instant mechanism for configuring, managing, and implementing SPF. It facilitates following features:

• Monitoring multiple email domains
• Defending organization’s domain against phishing and spoofing
• Increasing email delivering rate