How to Prevent Email Spoofing with DKIM, DMARC & SPF

How to Prevent Email Spoofing with DKIM, DMARC & SPF


Email wasn't designed for the modern world. It dates back to before the Internet as we know it even existed - Back when it was just a US defence project called ARPANET. Back then, when everyone knew everyone else on the network, security wasn't really so much of a thing; but fast-forward to the modern world and a vast number of data breaches start with a spoofed email.

The simple fact is it's ridiculously easy to make an email look like it came from anyone you want. If someone spoofs your email address, that can enable them to breach your organisation, or one of your customers. Let's face it. If one of your customers loses money or data because of an email with your address on it, that doesn't look good. It might not matter that you didn't actually send it. The fact is you didn't do enough to stop it happening; and that is going to damage your relationship, your reputation, and even your brand. Let me show you how to stop it happening.

Why on earth is email so easy to spoof? Well, think about it for a moment. What is email? It's electronic mail. It's the digital equivalent of sending a paper letter. If you send a paper letter, how do you let the recipient know who to reply to? You write your address at the top, don't you? But that's up to you. You can actually write any address and there's no way to prevent you doing that. Well, email is exactly the same. Your email software writes your address at the top, so the recipient knows who to reply to, but there's nothing stopping you putting anyone's address at the top.

With a paper letter, people often try to add authenticity by signing their name at the bottom. You can do something similar with email, using S/MIME to digitally sign your emails; but a digital signature has some of the same problems as a pen and paper signature. A digital one is a heck of a lot harder to fake, but it still only works if you know what it's supposed to look like in the first place. In the digital world this normally mean swapping certificates, That's very cumbersome. You have to exchange certificates between every single combination of sender and recipient, and that's a lot of work.

You could cut a lot of the work out by buying publicly signed certificates for everyone, but that's going to get expensive quickly, and it's still a pain to manage. This doesn't scale well - especially to the internet. As a result, only a tiny fraction of emails are actually digitally signed. That means you can't rely on it as a validation mechanism unless you've previously had a conversation with the recipient and you've instructed them to reject any emails from you that aren't digitally signed. In reality, that relegates this to very niche cases.

So if we can't rely on a signature being present, what can we do? I'm going to talk about three different complementary technologies that can help you prevent people from spoofing your email addresses. They are SPF, DKIM, and DMARC. All three of these rely on the domain name system, or DNS. If you've got your own domain name (that's a bit after the "@" sign in an email address) then you have DNS somewhere.

DNS

DNS is essentially a public directory where you can publish information. Normally it's used to help you find services, so it translates names and IP addresses to help you find websites, and it publishes the location of your email servers so people know where to send your messages to. You where you can use it to publish other information as well - including information that can help recipients validate your emails.

SPF

SPF, or Sender Policy Framework is a standard method of publishing a list of servers that are authorised to send emails on your behalf. There's a fixed location in DNS where it should be found, and it's based on the domain name (remember the domain name is the bit after the "@" sign in your email address).

So when someone receives an email from you their anti-spam system can look at the domain name, go check the SPF record, and if the server that sent that email isn't on the list, they know it's a scam.


It's worth mentioning that if you don't have an SPF record, a lot of spam filters these days will treat every email from you with suspicion. That's just because they've got limited set of information to decide if the email's legitimate or not; so they'll tend to treat your emails a little bit more harshly as a result. That means that if you implement SPF, you not only make it more difficult for people to spoof your emails; you also make it more likely that your legitimate emails will get through as well.

Implementing SPF is almost a no-brainer, but you do have to do your homework first. Because you're telling recipient spam filters to reject anything that doesn't come from that authorised list of servers, you need to make sure that list is complete. That doesn't just include your email system. That can include a lot of other things as well - third-party applications, cloud services, marketing newsletters, your website... all of these things could send emails on your behalf. You need to make sure you've identified all of them and put them on the list, otherwise they're going to get blocked.

Typically, these things have been deployed over many years, by many people, in many different departments. That list for a well-established company, can be quite long. You need to make sure you have identified all of them or something could get blocked. That can be a fair bit of effort, but it's definitely worth doing.

DKIM

DKIM, or DomainKeys Identified Mail is more complex than SPF because it relies on digital signatures. These DKIM signatures are different from the S/MIME signatures we spoke about previously, they serve a different purpose. S/MIME proves the identity of the sender, DKIM doesn't. DKIM proves the identity of an organisation who've chosen to vouch for the authenticity of that email.
If S/MIME is like signing your name at the bottom of a letter, then DKIM is like putting that letter in an envelope and stamping it with a wax seal.


The key difference is that the person who stamps the envelope with seal hasn't necessarily written the letter - they're just vouching for it. The value of that seal depends entirely upon the reputation of the organisation who made the seal. 

Without getting into too much detail, a digital signature proves two things: it proves who signed it, and it proves that the data hasn't changed since it was signed. If the data does change, then the signature will no longer match the data.

Just as with S/MIME though, we need some information in order to be able to validate that signature. We need to know what it looks like, as it were. That means we need something called a public key from the person who signed it. With S/MIME that was a lot of effort because you had the exchange certificates everywhere. Because DKIM's centralised though, it's a lot easier. You can take that centralised public key, and you can publish it in DNS for all the world to see. Anyone who receives a DKIM-signed email can check the DNS record in order to validate it. It's important to note that whilst the presence of a DKIM signature should make it less likely for an email to get blocked, the absence of a DKIM signature means precisely nothing.

By itself therefore, DKIM is more focused on helping legitimate emails get through than it is about blocking spoofed messages. In terms of implementing DKIM, it normally comes as a feature of an email or anti-spam service. If yours supports it, then it's usually a case of switching on the feature and adding the DNS record.

DMARK

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. DMARC builds on top of both SPF and DKIM. DMARC's essentially a policy that's stored in DNS. Just like SPF, DMARC is found in a set location in DNS that's based on the domain name of the sender's email address. DMARC closes some gaps that exist with SPF and DKIM, it provides guidance to recipients about what to do with spoofed messages, and it also provides a useful feedback loop for senders.
Let's break that down. The gaps it closes are what DMARC refers to as "alignment". Let's talk about SPF first. There are actually two from addresses on an email. There's the "mail from" address that the server uses for message routing, and there's the "from" address that you actually see displayed in the email. Now, normally these are both the same; but not necessarily. The SPF check is carried out against the "mail from" address.


When you use DMARC that SPF check is repeated for the "from" address as well. You only need to pass the first check in order to pass SPF, but if you pass both then you achieve DMARC alignment.

Let's look at DKIM. Remember I said that anyone can send a message using DKIM, not just the sender? Well, that's true, but in order to pass DMARC alignment using DKIM, the domain of the signatory has to match the domain of the sender. If it doesn't, you can still pass DKIM, but you won't achieve DMARC alignment using DKIM. If either SPF or DKIM pass the alignment test, then DMARC is happy.

The next thing DMARC does is gives guidance to recipients on how to handle spoofed messages. You can tell them to block them outright, place them in the spam quarantine, or do nothing. This helps provide consistency, because otherwise different spam filters will behave in different ways. Leading to some messages getting through, and others getting blocked.

Why would you want to choose to do nothing? Well that brings us on the final part of DMARC, which is reporting. This provides an address for recipient servers to report spoofed message activity back to the supposed sending organisation. It serves a couple of purposes. One is it makes you aware of spoofing campaigns that may be targeting you or your customers. The other is it helps you identify legitimate emails that are getting blocked by accident. This is why you might want to initially set your DMARC policy to take now action on spoofed messages.

Remember how I cautioned you against implementing SPF if you haven't identified every single legitimate source of email, because otherwise they'd get blocked? Well, if you implement DMARC with a reporting address, and a policy action of "none", you can collect reports about SPF failures from legitimate systems that would otherwise have been blocked. After you've worked through them all, you can upgrade your policy to "quarantine" or "reject".

I should note that this approach will not completely reduce the risk, and you are better off taking my original advice and identifying as many of these legitimate sources of email as you possibly can up-front. That's because DMARC is not in as widespread use as SPF is. There are a lot of antispam systems out there that won't know to check your DMARC, policy but will reject your emails based on your SPF record.

So where do you start?

Well, if you do nothing else, implement SPF. SPF will have the biggest impact in terms of preventing scammers from using your email address; and it's just a DNS record, so it's completely free. DMARC is useless by itself, it relies on SPF and DKIM, but you don't necessarily have to have both. You can use DMARC with SPF, even if you don't have DKIM. So maybe the next step is to implement DMARC alongside your SPF record.

Again, DMARC is just a DNS record, so it's completely free.

DKIM is the most complex of the three, but because it's usually implemented as a feature in an email system or an anti-spam service, you usually just need to turn it on and add a DNS record. Some vendors like Office 365 turn it on by default, and use their domain to do the signing. In that case all you need to do is add the DNS record and flip it over to your domain if you want to achieve DMARC alignment.


How to Prevent Email Spoofing with DKIM, DMARC & SPF


How to Prevent Email Spoofing with DKIM, DMARC & SPF



Report Page