Email Authentication – The Ins & Outs of Protecting Your Inbox

Emails – can’t live with them, can’t live without them, right?

The average office employee gets about 121 per day, so it is no wonder that workers have had to come up with their own mechanisms for deciding which emails they should pay attention to and which not. Some years ago, it used to be the same for the good old “physical” mail. How many ads did you have to sort through to get to the most important pieces?

Interestingly enough, the decision about whether to open or trash a piece of mail – digital or physical – is often based on one singular factor: The sender’s name that appears on the envelope.

Sender Authentication for Email

But is this actually a reasonable way to make a distinction? How can we know that the name on the envelope was not forged?

The answer is: Without a closer look, we cannot! For physical mail there are assurances such as signatures, stamps, seals and due process for those handling our mail. But even then, occasionally, very believable forgeries of official documents will make the rounds, as criminals try their best to defraud people and take their money.

It can happen to the best of us. Some years ago, I received some invoices from my carrier. I paid, but a few weeks later I received the same invoice. On second glance it became clear that the account number on the second invoice was different. After calling the carrier I learned this was a scam– a clever one, as the letter itself was completely indistinguishable from the real thing!

For electronic mail, there are other mechanisms for determining whether or not the message is legitimate. And those tools definitely should be used, as it does not require a great deal of technical know-how to forge the friendly-from sender address (name and email address displayed to the recipient). In technical terms, this is called spoofing. Don’t take my word for it, just have a look here:

So, what mechanisms do we have available to prevent and detect spoofed emails?

DKIM, SPF, and DMARC

DomainKey Identified Mail (DKIM), Sender Policy Framework (SPF) and Domain-based Message Authentication, Reporting & Conformance (DMARC) are DNS-based mechanisms that aim to prevent spoofing of email domains.

Let’s look at each of these in more detail, covering how they work and what they can and cannot do.

SPF

The idea behind SPF is simple. When setting up SPF for a domain, a specific DNS TXT record for that domain is created. A properly configured mail server on the receiving end, processing a mail send from the sender’s domain, will then encounter the SPF record on a DNS lookup.

Let’s look at the first part of the one for globalsign.com to better understand this:

v=spf1 ip4:114.179.250.0/30 ip4:211.123.204.251/32 ip4:27.121.42.215/32 […] -all

The logic here is pretty simple. v=spf1 declares that this entry is in regard to SPF. The range of IP addresses denotes all IP addresses which a recipient mail server should accept as origin for a mail with the domain globalsign.com. And -all means that all if any other IP address is sending a mail on behalf of globalsign.com, the recipient mail server should quarantine or reject the mail altogether.

The whole entry would be a bit longer and include an allow list of domains that can send on behalf of globalsign.com, but the above is pretty much all there is to it. However, there are some limitations with SPF. When it comes to forwarded mails and advanced spoofing that also manipulates the sender IP address, SPF might fail. In that case, other mechanisms are required to create higher levels of assurance.

DKIM

That’s why DKIM was created. It provides a higher level of assurance for the authenticity of the domain part of a sender’s email. The higher level of assurance comes from a cryptographic signature (a little bit like S/MIME but not quite…we’ll get there), and so one requirement for configuring DKIM is to create a public/private keypair. The public key is then noted in the DNS zone of the domain and can be retrieved by the recipient mail server to validate emails sent from that domain, which are signed with the private key to match.

Let’s look at one of the entries for globalsign.com again:

“v=DKIM1;k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1vhugV30ayqwRy2mu+m6QyxvdVtHee/Chr
UqtrPflazjf3LfuGryocUGTZ66DsHZeTpjqdcRRXms1+xpVsqqeiXipw4jNPwx9VpyIyg0suI/2QYsIjKyj0
OFYWe22Ilgp/zjXXJUxJ4fTqT5ae0cAX5u3GNsj6dA8u9n3atIlIwIDAQAB”

As with SPF, v=DKIM1 declares that this entry is meant for DKIM. k=rsa lets the recipient mail server know that this keypair is of RSA type and the p=[…] is the public key itself. Again, pretty simple stuff. Now when a mail from globalsign.com is sent, the globalsign.com mail server will use the DKIM private key to sign the mail cryptographically by hashing the mail, encrypting the hash with the private key and attaching it to the mail. The recipient mail server can then hash the mail again and decrypt the encrypted hash with the public key it retrieves from the DNS entry. If both hashes match, the mail is guaranteed to have originated from globalsign.com and has not been tampered with.

DMARC

DMARC is tying up both SPF and DKIM with some additional rules to let a recipient mail server know what to do with emails that don’t conform with either of the above policies.

Let’s look at the entry for globalsign.com one more time:

v=DMARC1; p=reject; rua=mailto:[email protected]

As with both SPF and DKIM, v=DMARC1 simply declares that this DNS TXT entry is declaring DMARC policies. P=reject is the policy for mails which fails the above, “reject” meaning that the recipient mail server should always reject these mails. “Quarantine” would mean the mails should be moved to some sort of quarantine, like spam folders or such. And “None” would allow the recipient mail server its own judgement on whether emails should be rejected, quarantined, or allowed through.

rua=mailto:[email protected] then specifies one or more email addresses that should be notified when either SPF or DKIM validation fail. This can be useful to snuff out organized efforts from bad actors to spoof a domain, which is especially useful for domains that frequently find themselves being the subject of impersonation.

Closing the gaps with S/MIME

While SPF, DKIM, and DMARC provide a significant improvement in email security, they are not the complete package. There are at least three weaknesses:

1. All of these policies are DNS based and are therefore circumvented by, for example, spoofing the DNS lookup on the recipients’ end or simply using homoglyph/alternate email addresses for the sender address that do not share the policies of the actual domain.
2. The authenticity of email is limited to the domain part of the email, meaning that while there is some assurance the mail actually came from a certain domain, the non-domain portion can still be spoofed. This can leave the sender vulnerable to, for example, malicious insiders spoofing mail on behalf of another internal department or person.
3. Since DKIM signatures are only applied by the sender mail server and are validated by the recipient mail server the guarantee of content integrity and authenticity of the sender is not fully end-to-end. The message is left vulnerable between the client and the mail server for both sender and recipient. This can be mitigated by proper implementation of TLS for both the sender and recipient mail server, but this is another topic beyond the scope of this article.

Figure 1: Simplified overview of how a standard Email is routed, including relevant DNS lookups

This is where S/MIME does the job better than SPF, DKIM and DMARC:

• S/MIME signatures are applied directly by the email client and are only validated by the recipients’ email client. This means that no manipulation of the message can take place, even between mail server and mail client.
• The public key for validation of the signature is attached with the certificate that comes with the mail, and therefore the email client does not need to rely on a DNS entry.
• The sender organisation in the certificate has also been verified by the CA issuing the S/MIME certificate. Therefore, a bad actor using a homoglyph email address is locked out from using the organisation name of the original domain.
• And lastly, the RFC 822 name in the certificate needs to match the friendly-from email address exactly, meaning the authenticity of the sender is now guaranteed at the email address level and no longer only at domain level. This significantly mitigates the weaknesses listed above.

Good, better, best – what will you choose for your enterprise email security?

Does that mean every organization should choose S/MIME over SPF, DKIM and DMARC? The answer is clearly “no.”

Organisations should have their SPF, DKIM and DMARC configured properly – honestly, this should be the bare minimum – but as pointed out earlier, they do not go all the way. For those that mean to provide the highest level of assurance to the recipients of their email, S/MIME certificates should be the tool of choice. Remember, S/MIME can allow for end-to-end encryption of email – something left entirely out of consideration by SPF, DKIM and DMARC.

Email has seen an incredible resurgence in the last two years, no doubt helped along by the growth of eCommerce and shift towards remote work we have witnessed during the pandemic. In fact, more than 306 billion emails are sent and received each day (Statista, 2021, via Hubspot).

Unfortunately, hackers are taking note, too, looking for new and sophisticated ways to infiltrate corporate data and wreak havoc. Smart businesses will arm their employees with the strongest email security methods available and, right now, that means S/MIME.

Luckily, S/MIME certificate deployment and management methods have only gotten better and more seamless over time. Learn how easy S/MIME certificate enrollment and revocation can be with the Auto Enrollment Gateway, or take a look at our complete set of enterprise email security tools now.