Categories
Dmarc as a Service

DKIM for ESPs: How to Implement DKIM Properly

Learn how ESPS should implement DKIM authentication for maximum protection for senders.

image of glowing key
image of glowing key

Note: A version of this post also appeared on CircleID.

Many ESPs struggle when it comes to properly adding and using DKIM authentication. However, it doesn’t need to be a headache—we’ll show you straightforward ways to make it downright simple.

Given the increase in email fraud (phishing) and an increasingly complex email landscape, it is increasingly important for email service providers to implement email authentication properly.

Major ISPs (Gmail, Yahoo! Mail, Apple Mail, etc.) are pushing other senders to authenticate their email and are using a carrot/stick approach:

  • Do it well, and your email gets through with high deliverability rates.
  • Authenticate poorly, and your email will be downgraded with lower deliverability — and increasingly with warnings or a lack of graphics and identifying logos.

Here are two examples from Google and Microsoft showing what non-authenticating emails loos like.

google vs microsoft

You don’t want that big red question mark next to your emails.

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.

DKIM for ESPs: How It Should Be

One aspect of email authentication often trips up many ESPs: 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 an ESP should consider when implementing DKIM:

  • No Key Sharing: Each customer should have their own, dedicated DKIM key, and ESPs should avoid any key sharing between customers. When an ESP doesn’t share DKIM keys between customers, a compromised DKIM key can only impact a single customer.
  • Regular Key Rotation: As recommended by the specification, DKIM keys should be changed (or ‘rotated’) on a regular basis, about 3–4 times/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 will only be useful to the attacker for a short time. Once the old key is rotated out and replaced with a new key, the compromised key is useless.
  • Store Private Keys Securely & in a Distributed Manner: DKIM private keys are extremely valuable, as they can be used by attackers to impersonate your clients in a virtually undetectable way. Given this, it’s critical to use best practices for key management: Don’t store private keys in plaintext, avoid maintaining a centralized database of keys, and follow best practices for PKI security.

The ESP DKIM Reality

computer screenshots

Does this look familiar? That’s because some ESPs make the following mistakes:

  • Widespread Key Sharing: Because DKIM is relatively complex and proper key management is burdensome, it is common for ESPs to use the same key for all their customers. This simplifies configuration: ESPs can provide the same instructions to all of their customers, the same DKIM record gets inserted into every customer’s DNS, and the sending infrastructure can use the same key to sign every message it sends.
  • Little to No Key Rotation: Also, because key rotation typically requires an ESP to manually update one or more DNS records — or even worse, have their customers manually update one or more DNS records — key rotation is extremely rare in practice. DKIM keys are typically set once and never changed, and it’s common to see DKIM keys that are 5–10 years old in production use.
  • Centralized, Plain Text Key Storage: Finally, even if an ESP tries to do DKIM correctly — provide one DKIM key per customer, and rotate DKIM keys on a regular basis — the simplest solution is to store the DKIM keys for all their clients 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 ESP’s customers’ keys during a breach.

Given that at least several major ESPs have reportedly been breached over the last couple of years, this approach must be considered highly risky. As with any enterprise system, it’s probably safe to assume that all ESPs have been breached at some point in the past 5–10 years.

What’s the answer to DKIM for ESPs?

ESPs should use a DKIM system that:

  • Supports frequent and automated key rotation
  • Defines unique DKIM keys per client
  • Stores the DKIM private keys in a secure way.

With this in mind, Valimail created Distributed DKIM (DDKIM), a patent pending method that solves the traditional difficulties with DKIM key management and distribution while adhering to this ideal. Though more secure and robust, DDKIM at the same time vastly simplifies the process and automates proper DKIM implementation and key management, accelerating the onboarding of new clients and allowing for quick key updates of existing clients.

Whether or not you are interested in DDKIM, feel free to drop us a line at info@valimail.com and we’d be happy to discuss DKIM further. Here’s to automated and secure authentication!