Stopping Forged Email 1: SPF to the Rescue

We have recently looked at how hackers and spammers can send forged emails and then seen how these forged messages can be almost identical to legitimate messages from the purported senders. We learned that generally, all you can trust in an inbound email message is the internet IP address of the server talking to your inbound email server. This cannot realistically be forged in any way that would still enable you to receive the message.

We know who the message is from and the server’s address that delivered it to us. How can we reliably prevent fraud by checking if the message was forged or not? Seems hard.

It turns out that a number (yes, more than one!) of techniques can be used to do this. The first and simplest is SPF – Sender Policy Framework. Below, we shall look at what this 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 Super Simple Explanation

Simply put, SPF is a way for the owner of a domain, such as bankofamerica.com, to publish information indicating what servers (internet addresses) are authorized to send email from that domain. Recipients (e.g., your spam filtering software) can check the internet address that is trying to send you an email from bankofamerica.com against this authorization list- if it is on it, the message is probably legitimate; if not, it’s probably forged.

Setting up SPF

With SPF (as with all anti-fraud solutions for email), it is up to the owner of a domain (e.g., the owner of bankofamerica.com) to set up the SPF authorization list. If they do not do this, there is no authorization list and no way to see if the message came from a legitimate server.

SPF is set up by adding special entries to the published DNS settings for the domain. If you want to set up SPF for your domains, you can read the links above to get started and use the SPF Wizard. You can also ask your email provider for assistance.

We are not going to 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.

SPF – The Good Parts

Once SPF has been set up, it really can do an excellent job at helping folks identify forged emails. It does exactly what, on the surface, one needs to do – verify that the sending server is authorized to send. The use of SPF is highly recommended for every domain owner and every email filtering system.

However, as we shall see next, SPF is not enough.

SPF Limitations

Sender Policy Framework has some significant limitations in stamping out forgery.

It can be hard to identify all authorized server addresses

If you are a small or well-controlled organization, you can probably identify all of the servers that should ever send email from your domain. However, if your legitimate users are allowed to send messages from arbitrary servers (e.g. from their home ISPs, from the servers of a changing ecosystem of your vendor-partners, etc.), then it becomes impossible to make an complete SPF authorization list.

A related issue is that, due to limitations of SPF, you sometimes cannot specify all of the possible authorized servers in SPF.  E.g., 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 may be sending email for you, then you must either not use SPF, or leave some legitimate sending servers off the list.

In cases where you can not make a complete list, the SPF record has to be configured to be “weak” — if SPF matches, then the message is probably legitimate (e.g. “weak” is denoted by using the “Soft Fail” code “~all” in the SPF DNS configuration). If the weak SPF check fails because it comes from an unauthorized server, then it might or might not be legitimate.

A large number of providers (e.g. gmail.com, bankofamerica.com, luxsci.com and others) have their SPF records set up as “weak” for this reason and others, see below.

Forwarded messages are problematic

When a message is forwarded, the “From address” does not change but the sending server does change.

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 that message that purports to be from bankofamerica.com.

If  bankofamerica.com’s SPF records were setup as strict (e.g. “strict” is denoted by using the “Hard Fail” code “-all” in the SPF DNS configuration), then your friend’s email server would look at that message forwarded from you as “forged” and mark it as Spam/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 is not widely or universally used.

For this reason as well, 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 Forgery

SPF checks only the domain name and the server.

If there are two different people in the same organization, Fred@domain.com and Jane@domain.com — either of them can send email legitimately from their @domain.com address using the servers they are authorized to use for domain.com email.

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

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

Same Email Provider: Shared Servers Forgery

This is a generalization to inter-domain forgery. If two people are using the same email provider, they will often have the same SPF records — as email providers usually have everyone use a standard SPF record indicating that messages coming 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.

It may be possible to “narrow” the scope of your SPF records to only those servers at your email provider that could actually be used by your account for sending. However, unless you have dedicated servers with them which isolate all of your sending to machines only accessible to folks in your own account, your SPF record must authorize servers shared with other, unrelated accounts over which you have no control.

Sender Policy Framework does not protect against Spam

This is not a limitation of SPF, but worth noting anyway just to clear the air. All SPF does is help you identify if a message is forged or not. Most spammers are savvy. They use their own legitimate 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 get by 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 you can imagine, the protections afforded by SPF are minimal. 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 you will trust that will make it past SPF?

1. If the sender address does not support SPF, the attacker is “all set.”
2. The message will look legitimate if the attacker can send you a message from one of the servers authorized by the SPF for the domain. E.g., if the attacker signs up with the same email provider used by the forged domain, they can send an email from those same servers authorized by SPF as “good” for the forged domain. This makes the attacker’s email look “Good” 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 forger to achieve their ends, then it is very likely that they can pick one that meets one of these three options.

How to Fix Sender Policy Framework?

SPF by itself is helpful but no real protection against fraud. What do 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 using DKIM, DMARC, and other message signature and isolation techniques.

Read next: Stopping Forged Email 2: DKIM to the Rescue