Stopping Forged Email 1: SPF to the Rescue
We have recently looked at how hackers and spammers can send forged email and then seen how these forged messages can be almost identical to legitimate messages from the purported senders. In fact, 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 — as this cannot realistically be forged in any way that would still enable you to receive the message.
We know who the message says it is from and the address of the server 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 there are a number (yes, more than one!) of techniques that 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.
SPF – 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 setup the SPF authorization list. If they do not do this, then 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. You can read about the syntax for these DNS records here: SPF Record Syntax. If you want to setup SPF for your own domains, you can read the above links 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 and 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 a good job at helping folks identify forged email. It does exactly what, on the surface, one needs to do — verify that the sending server is authorized to send. Use of SPF is highly recommended for every domain owner and for every email filtering system.
However, as we shall see next, all is not wine and roses.
SPF – Its Limitations
Sender Policy Framework has some significant limitations in its ability to stamp 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.
E.g. 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).
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 “OK” … 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 OK. 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.
SPF does not really 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 setup 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 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?
- If the sender address does not support SPF at all — the attacker is “all set”.
- If the attacker can send you a message from one of the servers authorized by the SPF for the domain, then the message will look legitimate. E.g. If the attacker signs up with the same email provider as that used by the forged domain, then s/he 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”.
- If the forged domain’s SPF records are weak and the attacker can’t use an authorized server to make the message look valid, then it doesn’t really matter — as SPF Failure won’t make their message look forged.
If the attacker has a choice of addresses to forger to achieve his/her ends, then it is very likely that s/he can pick one that meets one of these 3 options.
How to Fix SPF?
Ok — so SPF by itself is clearly useful but no real protection against fraud. What do you do?
A responsible domain owner who wants to protect his/her domain from forgeries and identify forged inbound email, takes additional steps which we shall discuss in future articles. These include use of DKIM, DMARC, and other message signature and isolation techniques.
Read next: Stopping Forged Email 2: DKIM to the Rescue