How to setup a SPF record to prevent spam and spear phishing

Some things go together like peanut butter and jelly: delicious, delightful and a good alternative to my dad’s “Thai-Italian Fusion” dinner experiments as a kid.

When other things are combined it can be terrifying: like SPF records and spear-phishing.

While the nuances of something seemingly mundane as SPF DNS records can seem like a dry boring topic for executives in your organization, you may be able to get them to pay attention to it as they are the most likely targets of spear-phishing attacks.

SPF records not only keep your C-Suite safe, but so much more. Like what, you say? Here’s just the tip of the iceberg on the magnificent benefits of SPF records:

• Prevent breaches
• Are cheap (free!) to set up
• Prevent bad PR from being used as Spam
• Overall benefits to organizational identification

With this in mind, let’s dig into some more of the the how and why of these incredibly useful DNS records.

What is a SPF record?

The Sender Policy Framework (SPF) is an anti-spam system built on top of the existing DNS and Email Internet Infrastructure.

Spammers were impersonating domains to make offers look like they were coming from Amazon or other reputable places, but when you would click through they’d steal your credit card and run up a bill at the local Chuck E Cheese (which is where I presume mob members go to eat).

What does a SPF record do?

An SPF record defines which IP addresses are allowed to send email on behalf of a particular domain. This is tricker than it sounds as many companies have multiple different Email Service Providers for different purposes.

Common different uses:

• Transactional emails from applications
• Internal notifications
• Internal email
• External email
• PR/Marketing emails

Further complicating the situation is that while a company might have a name like SafeEmailSender, there is nothing stopping them from having an email sending domain like wookie-fighter.com .

What does a SPF record prevent?

Having strict SPF rules allows you to control who can send email on behalf of your domain. A good way to think of this is the reverse: who would gain by sending email on behalf of your domain.

What is phishing?

Phishing is where a con artist sends mass emails out that appear as if they are from a legitimate source. Most often impersonated are banks, credit card companies and money handling corporations (like Paypal).

From the point of view of the phisher, they would like to appear as much as possible like the company they are pretending to be. A key aspect of this is making their email appear to be from the genuine source and to definitively not appear to be coming from my clueless neighbor’s malware riddled Windows XP box.

In recent years, data breaches have served as a prime resource for phishers as they are able to create a more convincing email as they have more details about targets.

What is spear phishing?

Spear phishing is similar in intent to standard phishing attempts: trick people into thinking a fake email message is legitimate, what differs is the audience.

With spear phishing it’s an audience of one.

A canonical example of this is the February 2016 spear phishing attack on a Snapchat payroll employee:

http://money.cnn.com/2016/02/29/technology/snapchat-phishing-scam/

What’s the difference between a SPF record and an SPF rule?

All DNS entries are “records”, most typically a domain has A and CNAME records for their website and some MX records to direct where email traffic should go.

A SPF record is what holds the rule. The mere presence of a SPF record doesn’t protect anything. It’s like a padlock that is left unclasped. It could protect something, but whether or not it actually is is something different.

What type of DNS record is a SPF record?

If you thought that people who invented DNS were smart, you are correct. What is somewhat surprising though is that they were also wise. Wise enough to know that while their DNS system was able to (with a few bumps along the way) scale up from a dozen computers to the millions online today that there would be new unexpected uses for DNS and that there should be an option to handle these. Thus the TXT record.

TXT (text) records are used for all sorts of interesting DNS purposes, like proving that you own a domain for SSL issuing purposes, up to and including ASCII art self portraits:

https://isc.sans.edu/forums/diary/Odd+DNS+TXT+Record+Anybody+Seen+This+Before/20283/

So, it’s no surprise that when new functionality was needed for the Sender Policy Framework, the tool of choice was DNS TXT records.

While this historical context is somewhat interesting (come on a guy put a selfie in a DNS record, that deserves some praise) on a more practical note it will also save you from fruitlessly looking for a “SPF DNS Record Type” in the dropdown of your preferred DNS service. You’d choose TXT and enter in the rules.

What are the components of a SPF record?

There are two primary components of an SPF record:

Mechanisms: What is being matched.

Qualifiers: What action should be taken if the mechanism is matched.

What is a SPF Mechanism?

A SPF mechanism is just a group of IP addresses. The nuances of exactly how that group is defined differ a bit between the mechanism types, but at the heart of it the question is always the same: Does the IP address sending email belong to one of these groups?

A SPF mechanism doesn’t have an opinion on anything. An IP address matching a mechanism doesn’t automatically mean it’s good or bad, just that it matched and that further commands about how to consider it can now be evaluated.

What are the SPF Mechanism Types?

The mechanism types are:

DIRECT IP/IP MECHANISMS
Does the client ip match an address in this range?

ip4 and ip6

DNS RECORD MECHANISMS
Does the client ip match the IP address resolving to one of these other domain record types?

a, mx, and ptr

DOMAIN MECHANISMS
Does the client IP address match one of the SPF rules at this OTHER domain. You typically see this when using external email sending services like marketing automation suites and transactional email systems?

include and exists

CATCH ALL MECHANISM
Well the client IP address didn’t match any of the other rules.

all

What are the SPF Qualifier Types?

There are four SPF qualifier types that act upon the SPF Mechanisms.

+ If the client IP matches the mechanism (IP matching group) that follows, it is allowed to send email for this domain.

Example: v=spf1 +a

This example means “If the IP address that any DNS a record for this domain resolves to matches the client IP address, then it is allowed to send email for this domain.”

- If the client IP matches the mechanism that follows, it is NOT allowed to send email

~ If the client IP matches the mechanism that follows, it is allowed to send email. But is marked as being potentially suspicious. The SoftFail qualifier is often used when first implementing SPF rules as you’re less likely to accidently mark all legitimate email emanating from your domain as spam.

In production, typically the final qualifier+mechanism pair is ~all which allows for the earlier rules to positively match.

? Neutral – pass but don’t positively or negatively identify.

Other than “+” which definitively marks an email as properly coming from your domain, the other qualifiers can be thought of as “hints” that an inbound email server can use in their spam calculations:

What’s the best practice method of adding a new SPF record into your DNS Records?

A key aspect of DNS is properly manipulating Time To Live (TTL) Settings. Please checkout our Definitive Guide to DNS TTL Settings for the optimum method of adding and modifying DNS records.

What order should SPF mechanisms be listed?

SPF records are evaluated left to right within the record. Matching a mechanism group immediately invokes the qualifier action and no further rules are matched.

In general you should put your IP address designations, your Domain designations, includes and then your all mechanism. This should roughly align with the time it takes to evaluate the rules.

What evaluates SPF?

It’s important to keep in mind that the receiving email servers for wherever you are sending email is ultimately who reads your SPF record. So if you send an email to abaigail@example.com, it will be the example.com mail server that reads the SPF record for example.com, compares the sending IP Address to the rules, and makes a determination about whether or not the email should be delivered to its intended recipient.

Why use SPF and not another email security standard?

Spam and impersonation have been problems on the Internet since it was invented, so why SPF and not one of the many different standards that have come before?

In contrast to previous security solutions, SPF is reasonably fast to execute and isn’t dependent upon the actual content of the email being received. An email with a 15MB video attached to it can be evaluated as quickly as a one sentence status update – since only the headers of the email are examined. Many previous standards relied upon the ability to cryptographically sign off of the bodies of email, making them unwieldy at best, and a potential vector for denial of service attacks at worst.

How do I lookup the SPF records for my Domain?

On OSX and Linux systems you can use the dig command to list the TXT records for your domain of which your SPF listing will be (if any).

dig -t txt example.com +short

On Windows you can use the NSLookup Utility

Nslookup.exe =q=TXT example.com

I recommend looking up the SPF entry for microsoft.com as you can very easily pick out their different SPF domains included as well as their permission for hotmail.com to send email on their behalf.