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. Now 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. Now, 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.
Welcome back to The Pro Tech Show - the place for tech, tips, and advice for IT
Pros and decision-makers. Now 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 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, 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. Now, 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. Now
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. If you find this sort of content
useful, then go ahead and hit that subscribe button for future videos. Now
let's talk about DKIM.
DKIM, or DomainKeys Identified Mail is more complex than SPF because it
relies on digital signatures. Now 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. Now 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. Now if you want to know how
that works, drop a comment below and if there's
enough demand, I'll do a follow up video on digital signatures. For now, just know that 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.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.
That's a mouthful I'm not going to be saying again. DMARC builds on top of
both SPF and DKIM. DMARC's essentially a policy that's stored in (you guessed it)
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. Now 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. Now,
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. Speaking of alignment,
there's very little chance I'm going to be able to align my fingers to these videos
over here, but I'm going to try anyway and suggest you watch them. If you liked this
video then give it a thumbs up before you go, and don't forget to subscribe for
future videos. Thanks for watching, guys. See you next time!