Preventing Email Forgery Part One: SPF

Some of the most dangerous cybersecurity threats originate with email, costing businesses millions of dollars annually. How can you increase your email security and prevent email fraud?

In this series, we will look at how to use DNS records to prevent email forgery. The first and simplest method is SPF – Sender Policy Framework. Below, we shall look at what it does, how it works, how to set it up, and what some of its deficiencies are. In future articles, we will look at the other techniques. 

Sender Policy Framework: A Simple Explanation

Simply put, SPF is a way for a domain owner to publish information indicating what servers (internet addresses) are authorized to send email from that domain. Recipients can check the email source against this authorization list. If the server is on the list, the message is likely legitimate. If it is not on the list, the message could be forged. 

Setting up SPF

With SPF (as with all anti-fraud solutions for email), it is up to the domain owner to set up the SPF authorization list. Identifying who manages the domain is often the most significant barrier to implementing SPF. Without access to the DNS settings, creating the SPF authorization list is impossible.

To set up SPF, the domain administrator adds a special entry to the published DNS settings. If you want to set up SPF for your domains, use the SPF Wizard. You can also ask your email provider for assistance. 

We will not spend time on the details of the configuration or setup here. Instead, we will look at the actual utility of SPF, where it falls on its face, and how attackers can get around it.

The Benefits of Sender Policy Framework

Once SPF has been set up, it does an excellent job of helping identify forged emails. It verifies that the sending server is authorized to send. The use of SPF is highly recommended for every domain owner. However, as we shall see next, SPF is insufficient to prevent all email fraud.

SPF Limitations

Sender Policy Framework has some significant limitations in stamping out email forgery. Below, we discuss some of the ways it falls short. 

Identifying Authorized Sending Server Addresses

Identifying all your email-sending servers may not be an issue if you are a small or well-controlled organization. However, it can be more difficult for larger organizations because of their size and use of partners and vendors to send emails on their behalf. In that case, making a complete SPF authorization list is practically impossible.

A related issue is that sometimes, we cannot specify all the authorized servers in SPF. For example, you can only have 10 DNS lookups in an SPF check. If your SPF record must be more complicated than that due to all of the possible organizations that send emails for you, then you must either refrain from using SPF or leave some legitimate sending servers off the list.

 In cases where you cannot make a complete list, you can configure the SPF record as “weak.” This means that if SPF matches, then the message is legitimate. But if the weak SPF check fails because it comes from an unauthorized server, it might or might not be legitimate.

Forwarded Messages Appear Illegitimate

When a message is forwarded, the from address does not change, but the sending server does. For example, if you receive a message from Bank of America and then forward it to your friend, it is now your email server sending a message that purports to be from bankofamerica.com.

If bankofamerica.com’s SPF records were set as strict, then your friend’s email server would identify the forwarded message as forged and mark it as spam or fraud. In most cases, that is not desirable. While there is a technology that allows forwarding to get around this (SRS – Sender Rewriting Scheme), it has yet to be widely adopted. 

For this reason, most domain owners set up their SPF records as weak (indicating that if the SPF check fails, the message could still be legitimate).

Inter-Domain Email Forgery

Because SPF checks only the domain name and the server, two different people in the same organization, Fred and Jane, can send emails legitimately from their @domain.com address using the same authorized servers for domain email.

However, if Fred@domain.com uses his account to send a message forged from Jane@domain.com, the SPF will check out as okay, even if the SPF is set as strict. 

SPF does not protect against inter-domain forgery at all.

Same Email Provider: Shared Email Servers Forgery

If two people using different domain names have the same email provider, they may also have the same SPF records. Email providers usually have their customers use a standard SPF record indicating that messages from any of the provider’s servers are okay. In this case, it may be possible for any user of that email provider to send a forged message purporting to be from another user in an unrelated domain and have the SPF check pass.

One way to avoid this issue is to use dedicated servers to send email from your domain. If your email provider allows it, you can accurately update your SPF list to indicate only the servers assigned to your account. Then, the SPF record would only reflect your sending and could not be corrupted by other customers of the email provider.

Sender Policy Framework does not protect against spam

This is not a limitation of SPF, but it’s worth mentioning in the context of email security. All SPF does is help you identify if a message is forged or not. Most spammers are savvy. They use their own domain names and create valid SPF (and DKIM and DMARC) records so that their email messages look more legitimate.

In truth, this does not make them look less spammy; it just says that the messages are not forged. Of course, if the spammer is trying to evade your filters by forging the sender address so that the sender is you or someone you know, then SPF can absolutely help.

How Attackers Subvert SPF

So, in the war of escalation where an attacker is trying to get a forged email message into your inbox, what tricks do they use to get around sender identity validation by SPF? 

As we have seen, most domains set up SPF weakly so that messages that fail SPF are not automatically flagged as invalid. From an attacker’s perspective, it all comes down to what sender’s email address (and domain) they are forging. Can they pick an address to construct an email that will make it past SPF?

1. If the sender’s address does not have SPF configured, it’s easy for the attacker to impersonate.
2. The message will look legitimate if the attacker can send a message from a server authorized by the SPF for the domain. If the attacker signs up with the same email provider used by the forged domain, they may be able to send an email from the authorized servers for the forged domain. This makes the attacker’s email look legitimate even if the forged domain’s SPF records are strict.
3. If the forged domain’s SPF records are weak and the attacker can’t use an authorized server to make the message look valid, it doesn’t matter, as SPF failure won’t make their message look forged.

If the attacker has a choice of addresses to forge to achieve their ends, then it is likely that they can pick one that meets one of these three options.

How to Fix Sender Policy Framework?

SPF is helpful but not the sole solution for email fraud prevention. What else can you do?

A responsible domain owner who wants to protect their domain from forgeries and identify forged inbound emails takes additional steps, which we shall discuss in future articles. These include DKIM, DMARC, and other message signature and isolation techniques.

Read next: Preventing Email Forgery Part 2: DKIM