One of the major vectors for spear phishing attacks that we often see is email spoofing – the impersonation of someone inside of your company through the use of a rewritten “From:” mail header.
This is a particularly easy type of attack to execute, if you’re of the mind to do so. In fact, in our recent State of Spear Phishing report, we reported on how we identified and defended our customers from more than 33,000 spoofing attacks in a single calendar quarter!
Even if you aren’t a GreatHorn customer today, you can take some basic steps to protect your organization’s email against this kind of attack for free, using email authentication systems such as SPF, DKIM, and DMARC.
Sender Protection Framework, or SPF, is the most logical starting point. In this quick guide, we’ll cover how to set it up and use it, as well as where its limitations are.
Background of SPF
SPF was born back in 2006, as an experimental approach to stopping forged (or, as we’ll refer to them from here on out, spoofed) emails from being delivered to ordinary users. It often comes as a surprise, but email — as a protocol — places few limits on what someone sending a message can do with their email headers, which are something akin to an envelope.
As with the real world, it’s easy to put more or less anything you like in as the return address. The problem is that unlike a physical letter, email is often rife with links to malicious websites, malware-infected files, and even requests to authorize fraudulent financial transactions and wires.
While it’s undergone some revisions since being introduced, the basic idea of SPF is to make this kind of spoofing more difficult by allowing an organization to define a set of IP addresses which are authorized to use its domain in the “From:” header. While this has some limitations, which we will cover below, it’s both relatively easy and highly worth setting up.
Step 1: Getting Started
First, in order to implement SPF, you’ll need access to the DNS records for your domain. Specifically, we’re going to be creating a TXT record — the details of how exactly to do that vary by who hosts your domain, but make sure you can edit the zone file for your domain before proceeding.
If you’re not sure, check out the support page for your registrar — some of the more common ones are below:
Step 2: Just What Is SPF, Anyways?
SPF is, essentially, a specification that covers two things:
- A list of authorized senders who may use your domain name
- A declaration of how you want to mark emails based on whether they are on that list
We’ll take this in two parts. The first is defining who can send as you. While you can get somewhat sophisticated with how you define that list, the basic process is straightforward.
If you’re running Google Apps for your business, you’ll want your SPF record to look something like this:
v=spf1 include:_spf.google.com ~all
If you’re running Office 365, the suggested SPF rule is:
v=spf1 include:spf.protection.outlook.com -all
Let’s break it down:
v=spf1 says that you’re using version 1 of SPF. That’s all that there is so far, so just leave this as is.
include:_spf.google.com or include:spf.protection.outlook.com says that your mail should only be sent as you when it’s routed through Google or Microsoft’s servers. By defining this here, you’re explicitly deferring to these vendors’ lists of IP addresses for valid senders. While Google and Microsoft might change that list, these lookup addresses will always (in theory) be up to date, ensuring that anyone trying to impersonate you can only do so via the platforms own mail servers, reducing the number of potential spoofing sources that you’ll receive.
The second part of SPF is how you mark messages that you send. What happens when someone tries to impersonate you? There are two reasonable options, and the two cloud email providers have slightly different suggestions for which to use:
~all says, “mark messages that come from an sender not on my list as a “softfail“
-all (not used in the example above, but an option) says, “mark messages that come from a sender not on my list as “fail“
Now we come to one incredibly important point about SPF: you can’t control what recipients of your email will do with messages when they are unauthorized. Some services block any “fail“, others simply deliver them, and almost everyone will receive a “softfail.”
Step 3: How SPF Helps
You might be asking yourself, and reasonably, “if anyone will receive a softfail, what good is SPF?”
The answer is that it’s complicated. Being able to mark messages (in their headers) as softfail is great, but there are a LOT of reasons why a message might fail SPF. Maybe your mail servers change. Maybe your Marketing team sets up email to be sent from an automation platform, and forgets to tell IT, so new IP addresses never get written to your DNS SPF record. It happens.
Step 4: Next Steps
The tricky part of SPF is that, with most cloud email providers, you simply can’t control what happens on the receiving side. In fact, you’re probably receiving quite a few softfail-marked email today — most of it benign, but maybe not all.
Effective email security required more control than SPF alone provides.
This means two things: implementing complementary authentication systems such as DKIM and DMARC, as well as additional security systems that address the threats that are not mitigated through authentication alone.
As with any cyberthreat, spoofing is often part of a more sophisticated attack chain, one that not only uses receiver-side SPF decisions that allow fail and softfail messages to reach user inboxes, but also carefully crafted and highly targeted language that can trick users into clicking on links, giving up their credentials, or even authorizing wire transfers that send significant amount of money to hackers.
It may sound complex, but GreatHorn makes this kind of email security simple.
With GreatHorn Inbound Email Security for Google Apps and Office 365, you can take control (via the GreatHorn Policy Engine) of how to handle those softfail messages. For example, GreatHorn allows you to:
- Extend SPF analysis to include content analytics, quickly identifying known threats, regulated data, and other mail-based attack indicators
- Detect and remove messages that come from domains that are homographs of your domain – for example, yourcompany.com vs yourcornpany.com
- Quarantine messages that violate GreatHorn policy, removing them from the inbox and placing them into a folder, similar to a Spam folder
- Automatically flag failed and softfailed messages to your users, warning them to be more cautious when responding to them, and automatically “white list” messages that are routinely failing SPF checks to reduce false positives
Setting up SPF is a necessary first start, but it needs to be part of a true defense-in-depth strategy. If you’re running Google Apps or Office 365, and want to truly protect your organization against spoofing attacks, let us know – we’d be delighted to offer you a free trial of the GreatHorn platform.