Using Sender Policy Framework (SPF) to Stop Email Spoofing

Email has become a key method of communication in the modern world, but the design hasn’t advanced much since the original specifications were formed in the 70’s and 80’s. While many people view postal mail as the real world analog of email, in reality email is closer to a post card.  While mail tends to be tied to a particular location (return), postcards are generally meant to be sent from anywhere. 

With this evolution of being able to send email from anywhere, it is relatively easy to send fake emails to people and make it look like they have come from somebody else (spoofed). One of the most common technologies available and in use to stop people from pretending to be someone else in email (also known as spoofing) is the Sender Policy Framework (SPF).

SPF is a simple email validation system that relies on your company’s Domain Name System (DNS). As the owner of your domain, say Fabrikam.com, you can create a DNS record that publishes which servers are allowed to send email coming from Fabrikam.com. It also specifies how Fabrikam would like you to react to any email coming from a server not listed. Below is a typical SPF entry

“v=spf1 ip4:172.0.0.1 ip4:172.0.0.2 ip4:172.0.0.3 a.mail.fabrikam.com -all”

The above record tells us:

• This is a version 1 SPF

• That the servers 172.0.0.1, 172.0.0.2, 172.0.0.3, and mail.fabrikam.com are allowed to send email for fabrikam.com.

• The last entry is a qualifier that indicates a fail. Any server not listed is to be treated as fraudulent and discarded by the recipient.

There are three main qualifiers for what to do with an email coming from a non-listed server:

Neutral result (?): requests the recipient to make no judgement based on which server sent the email claiming to be from Fabrikam.

SOFTFAIL (~): requests that that the recipient tag any email not coming from a listed servers as potentially fraudulent. They do allow for other servers than those listed that send email on behalf of Fabrikam, and therefore the email shouldn’t be discarded outright.

FAIL (-): requests that the recipient discard any email coming from a server that is not listed as only listed servers are allowed to send on behalf of Fabrikam.

Why Use SPF?

There are a number of reasons for using SPF. The most obvious is that it gives a company the ability to confirm that email is legitimate. It also makes the domain less likely to be spoofed. Spammers, and phishers are less likely to pretend to be coming from a company that has published an SPF record, because they know there is a simple mechanism in place that will allow their emails to be caught and discarded. Similarly, spammers and phishers are less likely to target a company that has published SPF records because they are more likely to have mechanisms in place to catch the fake email. Both of these present a low return on investment for the spammers and phishers. Finally, because a domain is less likely to be spoofed, it is less likely to appear on blacklists, resulting in a higher chance of legitimate email getting through.

Communication Matters

As you can see from this description, it matters that the people who control your DNS and the people who build systems that facilitate your email, talk to one another. In many companies, these are different teams, or potentially different vendors.

Let’s look at a real example that Mantralogix has been involved in.  It involves a large fast food chain. The fast food chain has a vendor notification system in place that emails comments, questions, and notices about potential concerns with incoming food products. The IT team at this company is very serious about security so they contacted the email team and made sure they had every email server listed. They further went on to configure their SPF so that any server that wasn’t listed was treated as a FAIL (fraudulent email).

Unfortunately, the people who developed the vendor notification system didn’t engage the appropriate technology teams, and as a result their server wasn’t on the validated list. Any emails sent out by the notification system ended up being labeled as fraudulent at the request of the security team at the fast food chain, and any properly configured email servers promptly discarded the email. As you can imagine this was a particular headache for the fast food chain, and potentially increased their liability resulting from food spread illnesses as the system was actively preventing notices from reaching their vendors.

Our Input

At Mantralogix we have a diverse team of people with different specialties. Our ability to easily get up and walk across the office to interact between the technical support (responsible for things like SPF)  and ERP consultants (who might have a requirement of sending email directly from ERP systems) allows us to quickly mitigate potential risk and liability to our customers. Additionally, we are always delighted to engage with other vendors our clients use (such as marketers and security system installers) to properly discuss, plan out, and deploy projects in such a way that customer experience has the most positive impact! Contact us today!