Using Sender Policy Framework to Mitigate Spoofing

What is the Sender Policy Framework (SPF)?

Sender Policy Framework (SPF) is an email verification system. First introduced through the Internet Engineering Task Force (IETF) in 2014, it helps determine whether a sender of a message has permission to use the specified domain.

How does the SPF protocol work?

An SPF record—a DNS record that identifies the hosts that are authorized to send email on a specific domain’s behalf—is a database record that can be published and queried by the SPF protocol. Adding an SPF record to the Domain Name System (DNS) also helps to protect recipients and senders from spam, spoofing, and phishing; senders can establish a list of approved servers to send emails from their domain.

The email is then cross-checked by the receiving servers to ensure that it originated from a server that has been granted permission to send on behalf of that specific sender’s domain. If it is determined that the sender is not permitted to send the email from that domain, the server’s spam policy will determine what to do with the message.

Even though the SPF standard has been around for many years, it has not been fully adopted everywhere, particularly in small businesses and some mid-market organizations. Attackers target small businesses as they often don’t possess the technical know-how to configure SPF.

When carrying out attacks, an adversary disguises the email address from which they are sending the emails, a technique known as spoofing. As a result, the email appears to the recipient as coming from a known and trusted email address.

Example of spoofed email: shared doc from Google Drive containing macro doc designed to establish connectivity persistence on end-point.

The Sender Policy Framework (SPF) process:

The diagram below illustrates the receiving email server’s actions when receiving an email.

1. The SPF record is created by the organization’s domain administrator and published to its DNS records.

2. The email is written by someone from the sending organization and sent to recipients.

3. The email is then transferred from the sending organization’s email server to the inbound server.

4. Upon receiving the email, the inbound server reads the return-path domain noted in the email header to look up the domain’s DNS records.

5. Next, the inbound mail server will take the IP address of the mail sender and compare it with the IP addresses that have been pre-authorized in the SPF record.

6. Once the IP address of the mail sender is confirmed as a match to one of the IP addresses in the SPF record, the email is delivered to the intended recipient. However, if the IP address is not found to match one in the SPF record, the inbound mail server will utilize the rules specified in the domain’s SPF record and either blocks or flags the message.

How Datto SaaS Defense uses SPF to prevent spoofing attacks

Datto SaaS Defense works to prevent phishing and spam attacks the first time they are encountered. First, it checks that the incoming email has the whole organization domain in its return-path address. Then, SaaS Defense accesses the domain’s SPF record to verify the sending server is authorized. SaaS Defense considers any discrepancy as a definitive sign of email spoofing.

Datto SaaS Defense blocks emails sent between clients in your organization whose SPF records are not configured correctly. While the sender has no malicious intent, an inaccurate SPF record results in the email being blocked.

Why organizations should add an SPF record to their domain

SPF is not required to send emails, but with the policy in place, you provide an additional trust signal to the receiving mail server, increasing the chance for the emails to reach the recipient’s inbox.

While SPF doesn’t eradicate all issues created by spoofing, it does provide an additional layer of protection that, combined with standards like DKIM and DMARC, can improve delivery rates and prevent abuse.

Limitations of Sender Policy Framework (SPF)

The Simple Mail Transfer Protocol (SMTP), has no protections on what is added in the “From” field in an email: the only requirement is a valid email address. This makes it possible for threat actors to impersonate a financial institution, place of employment, or any individual – which led to the creation of SPF.

SPF does not check or validate the domain associated with the email address. Instead, it examines the Return-Path – the address used by the receiving server to notify the sending mail server of delivery issues. For instance, the email address doesn’t exist on the receiving server. Thus, an email can pass SPF regardless of whether or not the “From” address is fake.

What is the Structure of a SPF Record?

While each email provider’s process of adding or updating an SPF record may vary slightly, the record syntax and attributes are universal.

An SPF record includes the following elements (identified in the image below). While it looks complicated, there are three distinct parts.

• Version (prefix): Domains may have multiple TXT records, which hold domain ownership, DNS service discovery, and DKIM information. SPF1 is read by the parsers and informs the record used for SPF checking.
• Mechanisms: The mechanism identifies a specific email server or servers to include in the SPF record. The inbound mail server looks for the mechanism that matches the IP address of the mail sender. An SPF record can consist of many mechanisms, each separated by a space.
• Enforcement rule: This qualifier rule identifies how the inbound mail server should process emails sent by a server if it is not defined in the domain’s SPF (i.e. an email from a server that fails the SPF verification).

Type of SPF record Qualifiers

There are four qualifiers to indicate the strictness in which the inbound server should process an email from a non-authorized server.

Fail Qualifier: Minus (-all)

The minus qualifier means fail—Emails from non-authorized servers should be blocked, not delivered.

Soft Fail Qualifier: Tilde (~all)

The tilde qualifier means soft fail—Emails from non-authorized servers should be delivered but flagged as suspicious (e.g., junk).

Pass Qualifier: Plus (+all)

The plus qualifier means pass—Emails from any servers should be delivered. It is not recommended to use this qualifier.

Neutral Qualifier: Question mark (?all)

The question mark qualifier means neutral, there is no policy. It is not recommended to use this qualifier.

When an email fails SPF checks, it will not be made visible in most email clients. Unfortunately, threat actors have figured this out and will disguise emails so that they originate from a trusted or familiar source to the recipient. Neutralizing these threats within the first few seconds of arrival keeps a user mailbox safe from spam, phishing, and spoofing emails. Advanced Threat Protection like Datto SaaS Defense is critical in a client cyber defense strategy in order to identify emails where SPF fails and other first encounter threats with valid SPF.

Don’t leave your business vulnerable to ransomware and other hacks. Join us for MSP Technology Day to learn how to leverage Datto SaaS Protection and Datto SaaS Defence to strengthen your security efforts.