DKIM: Protect your domain from email forging

Jump to

DKIM (DomainKeys Identified Mail) is an email security standard designed to make sure messages weren’t altered in transit between the sending and recipient servers. It uses public-key cryptography to sign email with a private key as it leaves a sending server. Recipient servers can then use a public key published to a domain’s DNS to verify the source of the message, and that the body of the message hasn’t changed during transit. Once the hash made with the private key is verified with the public key by the recipient server, the message passes DKIM and is considered authentic.

It’s easy to impersonate a trusted sender over SMTP. This led to spam for end users that appeared to come from legitimate sources. Spoofing email from trusted domains is a popular technique for malicious spam and phishing campaigns, and DKIM makes it harder to spoof email from domains that use it.

DKIM is compatible with existing email infrastructure and works with SPF and DMARC to create a layered security for domains sending emails. Mail servers that don’t support DKIM signatures are still able to receive signed messages without any problems. It’s an optional security protocol, and DKIM is not a universally adopted standard.

Even though it’s not required, we recommend you use it whenever possible to authenticate mail from your domain. We use it to sign messages at Postmark, and ISPs like Yahoo, AOL, and Gmail use it to check incoming messages. We’ve done testing that proved messages are more likely to be delivered when they use these security protocols.

An additional benefit of DKIM is that ISPs use it to build a reputation on your domain over time. As you send email and improve your delivery practices (low spam and bounces, high engagement), you help your domain build a good sending reputation with ISPs which improves delivery.

While it’s important to understand what DKIM does, it’s also important to be clear about what it doesn’t solve. Using DKIM will make sure your message hasn’t been altered, but it doesn’t encrypt the contents of your message. Many ESPs use opportunistic TLS to encrypt messages as they move between sender and recipients, but it’s still possible to send unencrypted messages if an email server refuses a TLS handshake. Once a message has been delivered, the DKIM signature will remain in the SMTP headers but won’t encrypt the content of the message in any way.

Since we’ve described what DKIM does, let’s move on to how it protects your domain’s email.

DKIM uses two actions to verify your messages. The first action takes place on a server sending DKIM signed emails, while the second happens on a recipient server checking DKIM signatures on incoming messages. The entire process is made possible by a private/public key pair. Your private key is kept secret and safe, either on your own server or with your ESP and the public key is added to the DNS records for your domain to broadcast it to the world to help verify your messages. Let’s dive a little deeper into how DKIM works on servers that are sending and receiving email.

If you run your own mail server, you can generate this pair on your own. Any time you use a service like Google Apps, Campaign Monitor, Postmark, or other email providers that support DKIM they’ll normally generate the key for you.

To give you an idea of how DKIM works, let’s explain the process on Postmark. We keep your private key securely stored on our servers and sign each message as it is sent. When a message is sent we create a hash from the content of the message headers and then use your private key to sign the hash. This signature carries everything a recipient server needs to validate the message, and looks like this:

a=rsa-sha1; the algorithm used to generate the hash for the private/public key. There are two officially supported signature algorithms for this hash, rsa-sha1 and rsa-sha256.

c=relaxed/relaxed; sets the canonicalization posture for the sending domain. This regulates whitespace and text wrapping changes in a message. There are two canonicalized postures. `Simple` doesn’t allow any changes, and `relaxed` allows common changes to whitespace and header line wrapping. Canonicalization in the header and body can be managed individually, and uses a header/body format.

s=20130519032151pm; is used as a selector for the public DKIM key for verification. Domains can have multiple public DKIM keys, and the selector value makes sure recipient servers are using the correct public key.

d=postmarkapp.com; is the email domain that signed the message. It’s important that your DKIM signature use your domain name here, because this bolsters your domain’s reputation with ISPs as you send valid email, regardless of the Email Service Provider you use.

From:Date:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:To:Message-ID; are the headers included with the message when it was cryptographically signed.

i=support@postmarkapp.com; is the identity of the signer and is usually provided as an email address.

bh=vYFvy46eesUDGJ45hyBTH30JfN4=; is the value of a body hash generated before the message headers are signed.

b=iHeFQ+7rCiSQs3DPjR2eUSZSv4i/Kp+sipURfVH7BGf+SxcwOkX7X8R1RVObMQsFcbIxnrq7Ba2QCf0YZlL9iqJf32V+baDI8IykuDztuoNUF2Kk0pawZkbSPNHYRtLxV2CTOtc+x4eIeSeYptaiu7g7GupekLZ2DE1ODHhuP4I=is the cryptographic signature of all the preceding information from the DKIM-Signature field. This entry is treated as an empty string during the verification process.

This signature is computed and added to the outgoing SMTP headers. The message is now ready for a recipient server to verify the message hasn’t been modified in transit.

Mail systems start DKIM verification by making sure the version number meets the DKIM specification, the identity of the sender’s domain matches the domain set in the signature, and the “h=“ tag contains the From header field.

Once the signature has been validated, the recipient server tries to retrieve the public key for the sending domain. The server uses the “d=“ tag to look up the DNS records for the sending domain, and the “s=“ tag to select the correct DKIM key. Here’s what the public key for Postmark looks like:

No matter which ESP or mail server you use, the general setup for DKIM is the same. You need a private key stored somewhere safe, and you need to share a public key in your domain’s DNS records.

It’s considered a best practice to periodically rotate your DKIM keys. The DKIM standard recommends rotating your keys every quarter, and it also recommends you revoke your old DKIM keys as part of this rotation. The best way to manage this is by adding your new keys, and a few days later removing your old keys DNS records for your domain. Postmark is one of the only ESPs that make it easy to manage this rotation because we keep your old private key active while your new public key propagates.