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.