How do DKIM and DKIM records work?

This is the second chapter in our DKIM guide, which gives you a technical deep dive into how DKIM works on servers that are sending and receiving email. 

If you are new to DKIM or need a refresher before continuing, you can head back to chapter 1: What is DKIM and why is it important; and if you want to know how to implement it, you can skip to chapter 3: How to set up DKIM.

Let's dive in! 

The private/public key pair behind DKIM #

DKIM signing uses two actions to verify your messages:

• The first action takes place on a server sending DKIM signed emails
• 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.

Sending a signed DKIM message #

If you run your own mail server, you can generate this private/public key pair on your own. Any time you use a service like Postmark (that's us 👋), Google Apps, Campaign Monitor, 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:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=20130519032151pm; d=postmarkapp.com;
h=From:Date:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:To:Message-ID;
i=support@postmarkapp.com; bh=vYFvy46eesUDGJ45hyBTH30JfN4=;
b=iHeFQ+7rCiSQs3DPjR2eUSZSv4i/Kp+sipURfVH7BGf+SxcwOkX7X8R1RVObMQsFcbIxnrq7Ba2QCf0YZlL9iqJf32V+baDI8IykuDztuoNUF2Kk0pawZkbSPNHYRtLxV2CTOtc+x4eIeSeYptaiu7g7GupekLZ2DE1ODHhuP4I=

Here’s what each part of the header means:

• DKIM-Signature: The header registered for DKIM-signed messages.
• v=1; The version of DKIM being used by the sending server.
• 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; Used as a DKIM 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; 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; The headers included with the message when it was cryptographically signed.
• i=support@postmarkapp.com; The identity of the signer and is usually provided as an email address.
• bh=vYFvy46eesUDGJ45hyBTH30JfN4=; The value of a body hash generated before the message headers are signed.
• b=iHeFQ+7rCiSQs3DPjR2eUSZSv4i/Kp+sipURfVH7BGf+SxcwOkX7X8R1RVObMQsFcbIxnrq7Ba2QCf0YZlL9iqJf32V+baDI8IykuDztuoNUF2Kk0pawZkbSPNHYRtLxV2CTOtc+x4eIeSeYptaiu7g7GupekLZ2DE1ODHhuP4I=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 message headers. The message is now ready for a recipient server to verify the message hasn’t been modified in transit.

Verifying a signed DKIM message #

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
• 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:

20130519032151pm._domainkey.postmarkapp.com. 3599 IN TXT "k=rsa\; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCSGLvJw6sZ5YEeFe5tl6D7h6IiE1J5kmMH6TEpG99BIHDuXg3vz/qRblKa0WcbI4SLDwsMkq17VheGt7ZZANqrCjcieHkKC8u52h5mezNFHRcKiOpr06o8PfkbqQsCX58ZpALcH0S1aQb6zkpebYsA111l1pGv5qlKvsbJ9t+9jwIDAQAB"

The public key decrypts the encrypted hash sent. The receiving mail server then computes its own hash. If the two match, the message is let through.

A few Frequently Asked Questions about DKIM #

How does DKIM improve email deliverability? #

ISPs like Gmail, Yahoo, and AOL use DKIM as a signal when determining whether a message is legitimate or not. Our testing has found that using email authentication methods like SPF and DKIM is critical to good deliverability.

How does DKIM prevent domain spoofing? #

DKIM alone does not prevent domain spoofing. It’s possible to sign a message using a DKIM key linked to a different domain than the one specified in the "From" header.

However, if you have a DMARC policy set for your domain, the receiving mail server will check that the DKIM key used to sign the message matches the From domain when determining DMARC compliance.

What do SPF and DMARC have to do with DKIM? #

While DKIM ensures messages aren’t altered in transit between the sending and recipient servers, SPF validates that the sending server is authorized to send messages using a domain in the first place. In turn, DMARC gives a domain owner a mechanism for communicating how they’d like unauthenticated messages to be handled by receivers. It uses DKIM and SPF to determine if a message is legitimate and whether it should be delivered to the recipient or blocked.

PS: speaking of DMARC, we made a tool you should try 👇