Sender Policy Framework helps fight spam and phishing by designating what IPs a website or company sends emails from
My recent change into this IT administrative role has left me with some new ideas to consider. I’d never worked for a company that had such a large market. Previously, my experience was with digital signage, which applies to so many aspects of the information technology world, but was certainly more niche as many businesses and consumers worldwide don’t have much of a need for digital signage. That’s kind of the opposite of this role: starting this week every website needs a digital certificate.
The technology climate these days focuses heavily on security. Digital certificates play a crucial role. This marketplace calls for lots of marketing. That, when coupled with many other aspects of this business, generates many emails. This circles back to a question I asked early in this series: How can I give peace of mind to email recipients that my emails are legitimate and not from some spoofer pretending to be a thesslstore-ite? The short answer is that there are a few ways to do it. We’ll look at one of the solution in this post, when we investigate a protocol called SPF (Sender Policy Framework).
Where Did You Come From? ♩Cotton-Eyed Joe♫
When it comes to verifying authenticity, isn’t that the question anyone would ask? Seems to be a fair question. If I receive an email from a vendor, I want to know where it came from as that incdicates the legitimacy of the sender. If I receive an email from an American-based company that originated in Kuala Lumpur, I would be a bit suspicious of that (no offense to Malaysia, I just find it fun to say/spell Kuala Lumpur). So, where does SPF come into play?
SPF is a protocol referenced by a DNS entry that indicates the valid IP addresses that email from a given domain may come from. In the DNS entry, the record indicates specific IP addresses, blocks of IP addresses (often denoted with CIDR) or other domain names. For example, all the following would be valid:
- IP Address with CIDR Notation: 126.96.36.199 /32
- IP Address Block with CIDR Notation: 188.8.131.52 /22
- Domain names: domainname.com
So, if an email comes through from an IP address listed in the DNS’s SPF record, then the email would be SPF compliant from the recipient’s perspective. If an email from an email comes from an IP address not listed in the DNS record, then it wouldn’t trusted. So, it would make sense to have a complete list of all IP addresses that an email might come from listed in a DNS record. Sound easier than it is? It is. Have you ever had déjà vu? It is.
More Addresses Than a Phonebook
Some businesses may host their own mail server. In this case, setting up Sender Policy Framework should be easy so long as the mail is not going through any other kind of mail exchanger. Some businesses may have a 3rd party hosting their mail server. In this case, the SPF could also be simple, just includes the mail service’s hostname or block/list of IP addresses. There may also be a need to list the IPs for intermediary or mail exchanger IPs.
However, some businesses, that may or may not be marketing driven, have emails expedited from all over the place. In these cases, each email domain should have an SPF record to ensure that emails aren’t not-trusted and your DMARC ratings doesn’t go up (nary you worry, we’ll discuss DMARC in 2ish blog posts from now).
To put that in some production perspective, we have emails generated from AmazonSES, MailChimp & Freshdesk, to name a few. MXToolbox has a bevy of tools that to help lookup DNS information, including Sender Policy Framework entries, for a given domain. So, the DNS records for those associated emails need to have the IPs listed for each of those services. Listing all IPs could look a bit messy but putting the simple domain name for each of those services calls for DNS lookups which adds overhead. Unfortunately, SPF has problems when it must perform over 10 DNS lookups. Services like Google Mail add many lookups with just the one domain name entry. Services like this are best expressed in their IP blocks. Woof. That could call for many IPs. And it does. Fortunately, these services often have the blocks listed out on their websites, so you don’t have to brush up on your subnet math skills. Again, MXToolbox and other services, such as DMarcian or DMARC Analyzer will check if the lookups exceed 10 and what issues that may bring. Best to be complete and we must play by the rules.
Let’s Have a Look-See
Since Sender Policy Framework records are publicly accessible let’s have a look at our main SPF record:
v=spf1 a mx include:spf.mtasv.net include:emailsrvr.com include:mailspf.smtp.com include:site2max.com include:servers.mcsv.net ip4:184.108.40.206/32 ip4:220.127.116.11/22 ip4:18.104.22.168/22 ip4:22.214.171.124/18 ip4:126.96.36.199/17 ip4:188.8.131.52/32 ~all
Our parameter explanations:
a – This will match the domain’s ‘a’ record
mx – This will include the IPs of a domain’s mail exchanger record
These first 2 parameters are typically standard but can be fine-tuned to put more restrictions about what is acceptable.
include – There are a series of ‘include:’ statements followed by domain names which list acceptable mail originators for this email domain. This will include the DNS lookups mentioned earlier in this post.
ip4 – This series of ‘ip4’ listings is specific IPs and IP blocks. Some are for AmazonSES and some are for Gmail. Both Amazon and Gmail have high DNS lookups and that is why we went with IPs. It can also be used with ‘ip6’ but Earth has still not fully embraced IPv6 for some reason….
~all – Current hypocrisy. We are still in the ‘~’ phase as there is evaluation as to where we are at with our massive mail movement. The question mark ‘?’ could be replaced with a few other characters that have different rules. Here is what the other qualifier symbols mean:
+ Pass an IP that matches IP
– Fail an IP that matches IP
~ Run the SPF rules against email but do not enforce. SPF fail will allow mail through
? Neither pass nor fail. Essentially disables SPF
These qualifiers can be applied to each ‘include:’ or ‘ipv4:’ statement. Using ‘all’ will apply to all addresses/domain names included.
I recommend that anyone who wants to learn more should look up different website domains’ Sender Policy Framework through MXToolbox and try to understand how they are setup. MXToolbox, among other sites, have tools to help build SPF records so don’t be afraid to use those, if needed.
Cheers and happy scrutinizing!
Check out the rest of the Email Security Series
- Email Security – Part 1: Certificate Signed Emails
- Email Security – Part 2: Phishing and Other Falseness
- Email Security – Part 4: DKIM (DomainKeys Identified Mail)
- Email Security Series – Part 5: DMARC, Reporting and Email