How to prevent email spoofing?

Not a long time ago, Internet email was based on trust. Trust on the servers, trust on the people running the servers.

Trust that who you see in an email “From” is really who wrote that message.

As of 2020 about 3+ billion forged emails are sent in a day, and it is safe to say (no pun intended) that those days of trust are long gone. People are being targeted by cybercriminals on a massive scale now, and email spoofing is one of the most used methods to do that.

Fortunately – and contrary to what many people believe – there are now technologies you can add to your email stack to protect your domain email from those criminals.

The technologies we have today to prevent email spoofing are SPF, DKIM, and DMARC, and in this post we will briefly show you what they are, and how they work together to prevent email spoofing.

SPF, your first line of defense

SPF is one of the first – and easiest – things you can do to help prevent email spoofing. The technology entails publishing a record on the DNS telling who – what servers – are allowed to send emails on behalf of your domain.

Now, when a receiving server gets an email pretending to be from you, they can look up your SPF record on the DNS, parse it, and check if whoever is sending the message is allowed to do so.

If the sending server is authorized, then the email is delivered. Otherwise, the outcome is defined by you on our SPF record (usually you tell servers to reject those unauthorized emails, although it is possible to allow the email to go through, which is useful for example when you’re testing SPF).

Pretty simple, isn’t it?

The SPF record is added to the DNS as a TXT record under your domain. A typical SPF record looks like this:

v=spf1 a ip4:192.168.22.112 -all

Check What is SPF? to know more about SPF and SPF records. For now, let's continue and talk about the next layer of protection we have available today, DKIM.

DKIM, protecting your emails from tampering

While SPF prevents email spoofing by only allowing authorized servers to send email on your behalf, DKIM will do that on a different level: your email contents.

DKIM works by selecting key data from your emails, such as “From”, “Date”, amongst others, and digitally signing their contents. The digital signature is then added together with something called DKIM selector (we will talk about DKIM selectors soon) as a separate header to the email, before it is sent on the Internet.

That’s on the sending side.

On the receiving end, when a DKIM-compatible email server receives a DKIM-protected email, they will get the digital signature attached to it, get the contents that have been signed by the sender, and the public key stored on the DNS.

With the email contents and your public key in hands, the receiving server can check if the digital signature is valid, which indicates that the email wasn’t tampered with. Usually this means “reject the email” but, like with SPF, you can tell the server to let the message go through while you’re still testing DKIM.

As we see, DKIM is like SPF, in that it works by publishing instructions on DNS TXT records. These records contain instructions that any servers on the Internet can use to verify and handle your emails.

However, DKIM adds one additional layer of indirection: instead of a single TXT record with the DKIM configuration in your DNS, you can have many. For example, you can have one configuration for your corporate email server, another for email marketing on Mailchimp, etc.

This can be helpful because you can segregate access to private keys.

So how do we know which DKIM configuration to use?

It is simple.

DKIM uses something called selectors, which is just a name used to locate DKIM records on the DNS. As we saw earlier, the selector used to sign the email is attached to the message, so the receiving server can get it and use it to locate the DKIM record.

To illustrate, you can configure your corporate email to use selector corp, and your email marketing to use mkt. Now, supposing your domain is example.com, to publish those two configurations on the DNS you would create TXT records at corp._domainkeys.example.com and mkt._domainkeys.example.com, respectively.

So far with SPF and DKIM we have already covered a lot of ground to prevent email spoofing.

However, there’s an issue…

The issue with SPF and DKIM

It is safe to say that email spoofing works because people look at the “From” line of an email, and think that the email was really sent by whatever name is written there.

That’s the behavior cybercriminals are exploiting in the first place.

However, SPF and DKIM work on a lower level on the email system.

SPF, for example, checks server names and IP addresses, which is not what your secretary would be checking to see if the order from boss@example.com should be carried on or not.

On the same note, DKIM signatures state that email contents were not altered while in transit.

However, the domain used to sign the message may not necessarily be the same in the “From” line.

Yes, that’s true. It is perfectly possible for a hacker to forge an email “From” boss@example.com, and use DKIM to sign the email using another domain name and signature.

As long as they sign the message with a valid key present on the DNS using the signing selector and domain chosen by them, DKIM checks will pass.

The information that the email was signed by the hacker (and not by example.com’s mail servers) will be indeed on the email headers. If you look at such headers, you will see that the hacker used his domain, with a perfectly valid public/private key pair, so the signature validates.

The thing is: nobody is going to check cryptic email headers (hidden by default) to see if DKIM checks match with what is on the “From” line!

That’s when DMARC comes to play…

DMARC, tying SPF and DKIM together

While SPF and DKIM are good at preventing email spoofing at lower levels on the email system, they fail in that what they authenticate is not what people first look at when they receive an email: the “From” address.

To fill this gap, we have DMARC.

DMARC works by taking both SPF and DKIM authentication results, and using the domain used by those two checks to match against the one in the “From” line.

In DMARC-speak, when SPF or DKIM domains match the one in the “From” line, they’re said to be in alignment.

For example, if you get a pass from SPF for domain example.com, and the “From” address is boss@example.com, then DMARC authorizes the email, because the domains are the same (they’re aligned).

On the other hand, if the SPF domain was example.net, then DMARC would fail, because example.net does not align with example.com (different domains), even if SPF authorizes the email.

It works the same with DKIM: you only get a pass from DMARC if the DKIM domain aligns with the “From” domain. No alignment, no DKIM pass, even if the digital signature validates.

Wrapping up on how to prevent email spoofing

As we discussed in this post, we already have technologies you can deploy to your domain to stop spoof emails. SPF, DKIM, and DMARC add several layers of protection to the email system, and are Internet standards that can be used by anyone.

Although SPF and DKIM alone are the basic tools one can use to prevent email spoofing, one still needs DMARC to fill the gap between the low-level email verification done by SPF and DKIM, and what people actually see (and react to) in their day-to-day emailing activities.

DMARC does that by using the concept of alignment, which basically ties SPF and DKIM verifications to what is an email “From” line.

Notice that besides adding another level of control over how to protect your email system, DMARC also provides a very useful reporting system that can help you stay on top of your email activity as reported by email providers, such as Gmail, Yahoo! Mail, etc. This reporting system is also crucial for a smooth roll-out of DMARC, especially on high traffic domains. We didn’t cover DMARC reporting in this post, but if you’re curious take a look at What is DMARC? for more about DMARC reporting.