Email Fundamentals: SPF, Impersonation, and Sending a Spoofed Message like It's 1984

Sender Policy Framework and the Foundation for Authenticating Email (Part 1)

When I first moved into a role that had to deal with school email security, the most common types of attacks we saw were all email spoofing related. Most commonly, we’d see attackers who scraped our webpages for email addresses and then send semi-targeted spear phishing messages (sidenote: avoid putting your email addresses on a public facing page if your stakeholders will allow it). For example, an attacker would make a list of a school’s employee email addresses, paying attention to relationships and departments. They’d then send messages to all staff except administrators and IT staff, pretending to be the principal requesting gift cards or to have a conversation via text message. We would block these sending addresses and IPs as soon as they were reported, but it was a never-ending game of whack-a-mole.

In the years since, there have been monumental improvements in preventing impersonation attacks, and Google’s move earlier this year to stop allowing email messages without SPF or DKIM throws some clout behind more organizations following best-practice. However, SPF, DKIM, and DMARC are still complicated topics, and most conversations around email security say these should be configured, but the purpose behind them is still a little bit of black magic. So let’s take a deep dive into understanding some of these configurations, beginning with SPF.

Sending an Email from CLI

To begin, it helps to take a step back in time and looks at some of the mechanics of email to understand how spoofing works. To appreciate email’s origins, let’s send an email from the command line and look at how easy it is to impersonate an email sender when there are no layers of security.

First, let’s go to 10minutemail.net. This site serves up disposable email addresses that expire after 10 minutes. That gives us a place to test sending messages.

The address I got is mrm33141@nowni.com (though you may see reference to other nowni.com addresses throughout this article, as my 10minute addresses keep expiring while I document steps😂). We need to find out what the mail server is for this domain. You can use a tool like MX Toolbox, or you can dig it from Linux or Mac using this command:

dig mx nowni.com 25 +short

This will output the mailserver. In this case, mail.nowni.com.

Next, there’s a series of commands we can do to send an email message over telnet. If you’re not familiar with telnet, it’s an insecure protocol that was later replaced by SSH (so don’t send anything over it that you don’t want others to see). As such, it’s disabled by default, so if you’re following along you’ll need to enable it in Windows. If you’re working Linux, you’ll possibly need to install it (apt install telnet). It dates back to the infancy of the internet, back when the mail protocol was part of the FTP protocol in the early 1970s. So it’s been around for a hot minute.

In our terminal, complete each line then hit enter. At the end, you’ll do a line with just a period (.) and then hit enter to send the message.

telnet mail.nowni.com 25

HELO edtechirl.com

MAIL FROM: <andy@edtechirl.com>

RCPT TO: <efm47528@nowni.com>

DATA

Content-Type: multipart/mixed; boundary=”NextMimePart”

From: andy@edtechirl.com

To: efm47528@nowni.com

Subject: Howdy!

--NextMimePart

Content-type: text/html;

How’s it going my dude?

.

In the terminal, it will look like this:

Now, in 10minutemail.net, we should be able to see the receive message like below:

Note the body of the message shows up twice. This seems to be a bug at 10minutemail.net.

Sending A Spoofed Email

From a security perspective, the question you should be asking yourself right now should be something like: Gee… how does the mail server KNOW that it was really andy@edtechirl.com sending that message?

To answer that, we can try the same steps again, except substituting any MAIL FROM: address that we want. In this case, let’s be Sam Walton at sam@walmart.com:

And now we’ve sent our first spoofed email. This lack of sender verification is the first open door for social engineers to begin impersonating you or your users. The shortcoming of inherently trusting email headers lead to the first security feature for preventing unauthorized servers from sending mail as your domain.

Sender Policy Framework (SPF)

To add a layer of authorization, SPF was developed to provide a way for a receiving mail server to verify that an email it’s receiving was sent by an approved sender.

When a mail server receives a message from an address like andy@edtechirl.com, it requests the SPF information from edtechirl.com’s DNS. This will return the following record:

v=spf1 include:icloud.com ~all

In SPF records, the “include:” statement tells the server that icloud.com is an allowed sender. This makes sense, as edtechirl.com is an iCloud+ email address. The server then has to take a second step and check icloud.com’s SPF records, which will return something like this:

v=spf1 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.142.0.0/15 ip4:17.57.155.0/24 ip4:17.57.156.0/24 ip4:10.162.0.0/16 ip4:144.178.36.0/24 ip4:144.178.38.0/24 ip4:112.19.199.64/29 ip4:112.19.242.64/29 ip4:222.73.195.64/29 ip4:157.255.1.64/29 ip4:106.39.212.64/29 ip4:123.126.78.64/29 ip4:183.240.219.64/29 ip4:39.156.163.64/29 ~all

The “ip4:” statement in an SPF record lists the IP addresses/address ranges for allowed senders. Accordingly, if someone is sending an email from an edtechirl.com address, as long as it’s coming from an IP in one of the above listed ranges, it will pass SPF.

Normally, an SPF record will include both the “ip4” and “include” statements. Take the SPF record for walmart.com:

v=spf1 include:_netblocks.walmart.com include:_vspf1.walmart.com include:_vspf2.walmart.com include:_vspf3.walmart.com ip4:161.170.248.0/24 ip4:161.170.244.0/24 ip4:161.170.241.16/30 ip4:161.170.245.0/24 ip4:161.170.249.0/24 ~all

For larger organizations, “include:” statements like this are referred to as netblocks and are used to simplify management. It allows you to segment management of the allowed IPs instead of listing a huge list of IP ranges. I’m not sure how walmart.com does it exactly, but imagine you’re a large multinational company and you have sending infrastructure in multiple regions. It would be easier to manage if you made a subdomain for each region that could be listed in the top level SPF record, then manage the individual IP ranges in the SPF record for the subdomain.

3rd Party Sending Infrastructure

Another use for the “include” statement is for scenarios where you may be using email delivery platforms like Mail Chimp, Send Grid, MailGun, Smore, Parent Messenger, etc. In cases where you’re outsourcing your email delivery, the messages are coming from that 3rd party infrastructure instead of your own, so they’re technically another sender impersonating or spoofing you, just with permission. Adding include statements for these senders in your SPF record will tell mail servers that those external senders are permitted.

Failing SPF

Finally, notice that both of these sets of SPF records end with this statement:

~all

This is the "soft fail" qualifier. It means that any servers not explicitly mentioned or included in the SPF record are not authorized to send emails on behalf of that domain. However, emails from unauthorized servers will not be outright rejected. Instead, they will be marked or flagged as suspicious, often resulting in the email being delivered to the recipient's spam or junk folder.

Wrapping back around to 10minutemail.net, note that our impersonated message was delivered with no issues. This is because 10minutemail.net doesn’t utilize SPF. Without conducting SPF checks, spoofing is trivially simple. Until Google started enforcing email authentication requirements for SPF earlier this year, there was no real clout to enforce this practice.

What’s Next?

While SPF is a useful tool for authenticating email senders, using it without additional measures like DKIM and DMARC leaves you vulnerable to various types of email-based attacks, including spoofing, phishing, and man-in-the-middle attacks. Implementing DKIM helps to ensure email integrity, while DMARC enforces alignment between SPF/DKIM and the "From" address that a recipient sees. In part 2, we’ll focus on the how DKIM works and the role it plays it helping you trust your email.