- Developer Hub
- SparkPost API
- Email Tools
- Slack Channel
- User Guides & Migrations
- Submit a Ticket
- SparkPost Academy
- Deliverability Guide
- Email Explained
- White Papers & Guides
- Webinars & Videos
- SparkPost vs. SendGrid
- Contact Us
The big ISPs like Gmail, Yahoo! Mail, and Hotmail are pushing senders to authenticate their email through a carrot/stick approach: Do it well, and you’ll achieve higher deliverability rates. Authenticate poorly, and your email will be downgraded, degrading your overall deliverability. Other symptoms might include warnings or a lack of graphics and identifying logos.
Microsoft & Google are beginning to show consumers if an email has been authenticated. Note that Google will insert logos for authenticated email and “?” for non-authenticated email. Similarly, Microsoft will redact logos and graphics and add red indicators if an email lacks proper authentication. Authenticate properly, and the email will display a green shield and render all logos and graphics.
Given this environment, we wanted to write a quick post on one aspect of email authentication that still breeds confusion: DKIM (short for DomainKeys Identified Mail). DKIM is an open, DNS-based email authentication standard that uses public-key encryption to authenticate email messages. There are several issues that a sender should consider when implementing DKIM.
The Right Way to Implement DKIM
No Key Sharing. Each customer, brand, or entity sending unique mail streams should have their own, dedicated DKIM key. When a sender doesn’t mix and match DKIM keys between mail streams, a compromised DKIM key can only impact a single brand or stream.
Regular Key Rotation. As recommended by the specification, DKIM keys should be changed (or “rotated”) on a regular basis, about 3–4 times per year. Rotation ensures that if a key is compromised for any reason (for example, by a hacker who obtains the private key), then the compromised key can only be used for a limited time. Once the old key is rotated out and replaced with a new key, the compromised key is useless.
Distributed, Encrypted Key Storage. Compromised DKIM private keys are extremely valuable—attackers can use them to impersonate senders and fly under the radar virtually undetected. Senders need to avoid storing private keys in plaintext, avoid maintaining a centralized database of keys, and follow best practices for PKI security.
The Reality of How DKIM is Implemented
Widespread Key Sharing. Because DKIM is relatively complex and proper key management is burdensome, senders often use the same key across their brands, entities and mail streams. The simplified configuration of a shared key provides relative ease in terms of implementation but it creates a unique vulnerability: a single compromised key gives a bad actor total and complete access.
Little to No Key Rotation. Because key rotation typically requires a sender to manually update one or more DNS records—or even worse, have their partners and sending entities manually update one or more DNS records—key rotation is extremely rare in practice. DKIM keys are typically set once and never changed. It’s not uncommon to see DKIM keys that are 5–10 years old in production!
Centralized, Plain Text Key Storage. Finally, even if a sender tries to do DKIM correctly—provide one key per sending entity or mail stream, and rotate keys on a regular basis—the path of least resistance is to store the keys for all their sending domains in a central database in plaintext, to simplify key management and distribution to the mail servers. Unfortunately this sort of architecture is a beacon to criminals, and makes it exceedingly easy to steal all of the sender’s keys during a breach.
Given that numerous major brands and ESPs have reportedly been breached over the last couple of years, this approach must be considered highly risky.
What’s the Answer?
Senders should use a DKIM system that supports frequent and automated key rotation, defines unique DKIM keys per mail stream, and stores the DKIM private keys in a secure way. Email authentication must be treated as an on-going policy and practice and not like a check box—too much depends on it like your brand’s integrity.
Whether or not you are interested in authentication, feel free to drop us a line and we’d be happy to discuss it further. Here’s to automated and secure authentication!
About the Author
Alexander García-Tobar is a serial entrepreneur and currently CEO & Co-Founder of ValiMail, providing Email Authentication as a Service™ . Previously, Alexander held various executive and analyst positions at leading research companies such as The Boston Consulting Group and Forrester Research and at Silicon Valley startups such as ValiCert, Sygate, and SyncTV.
Email systems have grown increasingly complex since they first appeared in the early 1970s. The growth of the Internet (as measured by users of internet-enabled services) is largely responsible for this complexity. Spam, phishing, and forgery attacks have plagued email users across the world in recent years.
The fundamental problem with modern email systems is that, although we ascribe identity to individual email addresses, that identity is generally not enforced. To this day, it is common to find poorly configured email servers and web email forms that allow malicious users to forge emails.
To understand how this is possible and why it is a problem, we need to understand how email works in the first place.
How does email work?
The internet protocol describing email (called SMTP: Simple Mail Transfer Protocol) functions very similarly to what we now know as “snail mail”. (It turns out that this similarity is very unfortunate). In snail mail, we have two major components: the envelope, and the letter.
The envelope contains addressing information: Who is this letter to? Who did the letter come from? The postal service uses the “To” address, printed on the front-center of the envelope, to get the letter to the right place. Sometimes, something is wrong with this address, and the “From” address (usually printed on the top-left or rear of the envelope) allows the postal service to return the letter to the sender.
If neither of these addresses make any sense, the letter will eventually be destroyed as it can neither be delivered or returned.
A letter from a company to a legal office may not mention names of individuals on the envelope. However, the letter will usually have information embedded in it describing who the letter is individually to, and who individually is responsible for the contents of the letter.
What Could Possibly Go Wrong?
The protocol for delivering letters via a postal service requires a large amount of trust. The example letter above is rather inflammatory, and we might have some doubts as to its validity. Consider the following questions:
- Who is B. Baz?
- Does B. Baz exist?
- Did B. Baz write this letter?
- Did Mr. Foo receive the mail, or did someone else?
- Was the letter altered?
We could probably come up with many other questions related to this as well. Fundamentally, these questions boil down to trust. The postal service does not provide us any way to verify that the sender is who they claim to be. It does not provide us with any way to verify that the sender actually wrote the contents of the letter.
For years, people have sought solutions to these problems. We have invented opaque envelopes to prevent people from reading contents. We use better adhesives to prevent tampering (or at least make it obvious if the letter was tampered with).
With hundreds of years of experiencing mail forgery, delivery tampering, and the like, email must have considered these cases, right? Wrong. Email does not solve any of these problems. Why are they problems? Malicious individuals can exploit these issues of trust to send computer viruses or unwanted marketing email (spam). People exploit these issues of trust to send diseases like anthrax, and unwanted marketing mail (coupon books, credit offers, etc.)
Email and snail mail are not so different. But in email, we can do better.
Trusting An Identity Crisis
We have established two problems with email:
- The identity of the sender and recipient of a mail are unknown.
- The contents of the message are not known to be correct.
So, if we are the recipient of a letter (or of an email, for that matter), how do we know who sent it? How do we know what we are reading is what the sender actually wrote?
With regular mail, we rely heavily on context and signatures. Humans are generally pretty good at recognizing visual patterns (and discrepancies in those patterns). If we receive a letter from someone we know, we can make an educated guess as to whether they sent it based on factors like writing style, handwriting, signature, and address information.
Imagine receiving a letter from a friend. This letter is asking you for money. You know your friend is on vacation in the Galapagos Islands, and the signature looks funny. You are probably going to request additional information before you send money to your friend.
Email does not enjoy these same protections. There are no signatures — just addresses. And most people are not technologically inclined. So when King Mubotu emails from Nigeria telling you to send him $50 so he can send you $50,000,000, you do it. I mean, it is King Mubotu, right?! Right!!?
So many people are still unaware of this attack, that it is still successful. Again, the fundamental problem is that identity has not been established, and our normal contextual clues for establishing it are gone. So we fall back to trust. If you follow one rule on the Internet, it should be not to trust anyone unless you have any technical knowledge that would make you think otherwise.
DKIM (pronounced “DEE-kim”) allows organizations to claim responsibility for messages they send and guarantee the contents of the messages they send. Senders may also guarantee the identity of the individual responsible for sending the message (although this is not yet widely used).
How does the guarantee work?
In a word: math. DKIM relies on what is called “asymmetric cryptography” (also known as “public-key cryptography”). After a message is received, and before that message is delivered to its destination, DKIM uses a “private key” to create a signature for both the contents of the message, as well as some key headers of the message. This signature is attached to the message.
When the message is delivered to the destination, the destination server asks the sender for a public key to verify that the signature is correct. If the public key allows the destination server to decrypt the supplied signature to the same value it computes as the signature, it can assume the sender is indeed who they claim to be.
(Note that we can only assume that the sender is not lying about who originated the email. If the malicious party is the sender in the first place, we have to trust that they are not lying to us!)
As an analogy, consider a message sent between two corporate offices. The message includes a reference number and a phone number. The receiving office can call the sending office, provide the reference number, and read the message. The sending office can verify that this is in fact correct.
What if someone else answers the phone?
In the hypothetical scenario of a letter sent between two offices with a reference number and a phone number to verify, it is logical to assume that a malicious person could attack the security of the system. The attacker would have to:
- modify the message,
- hijack the phone line,
- impersonate the sending office, and
- lie about the validity of the message.
This is a difficult attack to pull off. But can we pull off the same attack against a DKIM-signed message? Not really.
When DKIM asks for the public key, it either receives the public key or it receives something that is not the public key. If it receives the wrong key, decryption will fail, and the message will appear invalid. If the message appears invalid, we can assume some aspect of the system has been tampered with, and we can try more strict verification of the message (such as an in-person discussion). This case does not break the guarantee made by the DKIM signature, because it can still be validated with the proper key.
If the attacker responds with the valid public key, all they have done is prove that the message was sent unmodified.
But people have hacked DKIM!
To mount an attack against DKIM, you have to own or reconstruct the private key. This has happened before in, for example, the attack against Google in late 2012. In this case, Google used an insecure key size for their private key and the attacker was able to reconstruct the key. The solution? Use a bigger key! Although this seems like a weak argument, the justification for why this works is outside the scope of this article. I do not wish to attempt to explain the complexity of integer factorization in simple terms. (At least not in this article.)
For the time being, this is a fine solution.
If a key is compromised (either because someone obtains the key by “hacking” the sender or because they were able to reconstruct it by brute force), one can simply change the key. The problem with doing this is that once a key is known to have been compromised, it is impossible to guarantee with certainty that a message has not been tampered with. There are two reasons for this:
- Inherently, once the key is compromised, someone can forge messages that would have validated with the key. With some clever tricks, it might be possible for an attacker to even forge dates to make it look like the message was sent when the key was valid.
- The public key is generally no longer available. Once the private key has changed, the public key must change as well. If both the public and private keys are subsequently lost or forgotten, it is nearly impossible to reconstruct them.
When doing forensics work with DKIM, if the original key was compromised, it is usually not difficult to prove that messages were not forged. Most people lack the skill to forge keys and emails, and the ability to forge dates requires access to both the sending and receiving machines.
Hopefully this is a useful, lucid, and digestable explanation about the security weaknesses inherent to email (and snail mail, for that matter). If you have additional questions, feel free to contact me either via comments or via email.
If you choose email, I hope you are using DKIM!SparkPost © 2018 All Rights Reserved