DomainKeys Identified Mail (DKIM) adds public key cryptography to the Simple Mail Transfer Protocol (SMTP). Email for the domain is digitally signed by the sending mail server using the private key for the domain. Receiving mail servers use the public key from the domain’s DKIM record to validate that messages have not been tampered with.
DKIM is specified in RFC 6376.
How DKIM works
A public key is published in a DNS DKIM record for the domain. The corresponding private key is used to sign email messages sent from the domain. Since the public key can be looked up in the DNS, all receiving mail servers can retrieve the public key from the DNS and use it to validate email signatures for the domain.
Signing outgoing messages
Each email sent from the domain is signed just before the message is transmitted. To sign each email, the sending Mail Transfer Agent (MTA) normalizes the message following the rules in RFC 6376. Then it creates a hash of the normalized email and uses the domain’s private key to generate a cryptographic signature of the hash. The signature is inserted into the email message in the DKIM-Signature header field.
Validating received messages
When email is received, the receiving mail server examines the DKIM-Signature header field and performs a DNS lookup to retrieve the DKIM record for the domain. The DKIM record contains the public key for the domain. The receiving mail server normalizes the message and computes the hash, and then uses the domain’s public key from the DKIM record to cryptographically validate that the email message has not been altered.
DMARC is required to prevent unsigned mail
DKIM does not include a policy to require that every email from a domain is signed. So with DKIM alone, spammers can still send forged email from your domain. This is where Domain-based Message Authentication, Reporting, and Conformance (DMARC) steps in.
DMARC policy requires that all email from the domain pass both SPF and DKIM authentication checks. Unsigned mail from spammers would be rejected or placed in quarantine.
Can a domain have multiple DKIM records?
Yes, a domain may have multiple DKIM records. Each DKIM record publishes the public key for a different private key.
Multiple DKIM records are common. DKIM uses “selectors” to allow multiple DKIM records (see RFC 6376 section 3.1).
There are two reasons why a domain might have multiple DKIM records:
- Multiple email providers: A domain may use more than one email provider, for example, MailChimp and Google Workspaces. Each provider will have their own private and public keys for DKIM.
- Key rollover: It is a good security practice to periodically roll the DKIM key for a domain. When keys are rolled, there will be a short period of time when the old key and the new key are both published in different DKIM records.
The DKIM record format
Where are DKIM records stored?
DKIM records are stored as TXT records, although a CNAME record is sometimes used as an intermediate “hop”. We will discuss how CNAMEs can be used in DKIM a bit later.
DKIM records are stored in the DNS for a domain using the label _domainkey preceded by an optional selector. If no selector is being used, the DKIM record for example.org would be at _domainkey.example.org.
However, a DKIM record at _domainkey.example.org would be unusual. DKIM records are usually published with an additional label called a selector. A DKIM selector is a short text string that identifies, or “selects”, among multiple DKIM records.
The selector is the first label in the name where the DKIM record is stored in the DNS. If the selector for one of the DKIM records for example.org is blue then the DKIM record would be at blue._domainkey.example.org.
How are CNAME records used in DKIM?
DKIM records are stored in TXT records, but an intermediate CNAME record is often used.
Many email providers who support DKIM instruct their customers to insert a CNAME record instead of a DKIM record into the DNS zone for the domain. The target of the CNAME is a DKIM record in TXT format, usually in a DNS zone owned by the email provider.
This is done because DKIM records can change, for example when the DKIM keys are rolled. If the customer uses a CNAME, then the customer’s domain doesn’t have to be changed at all. The key rollover DKIM record change can be performed by the email provider. This greatly reduces the administrative burden on the customer.
DKIM format
DKIM records are TXT record that contain tag/value pairs. The tag’s name is followed by an equals sign and then the tag’s value. Tags are separated by semicolons. This format is identical to the format used in DMARC records.
Below is a current DKIM record for Google. This DKIM record has the selector 20210112. This is probably the date the key was generated. The “k” tag says that this is an RSA key. All mail servers must support the “rsa” key type. The long key string is omitted for brevity:
20210112._domainkey.google.com. 3600 TXT "v=DKIM1; k=rsa; p={key string omitted}"This DKIM record will be applied to any email message sent by Google whose DKIM-Signature specifies the 20210112 selector.
DKIM tags
DKIM tags specify attributes of a DKIM key, including the public key itself. Every DKIM record must begin with the version tag “v”. Its value must be “DKIM1”. More versions may be added in the future. All other tags are optional and may appear in any order. DKIM is case-insensitive. Either upper- or lower-case may be used.
The Internet Assigned Numbers Authority (IANA) maintains the official registry of DKIM tags. The current set of DKIM tags are:
- “v” Version. The value must be “DKIM1”. This tag must appear first in every DKIM record.
- “k” Key type. Most often “rsa”, which is the default, but “ed25519” was added in RFC 8032.
- “p” Public key data. This tag is required in every DKIM record. It contains the public key in base64 format.
- “h” Acceptable hash algorithms. A colon-separated list of the hash algorithms that might be used to sign messages.
- “n” Notes. Human-readable text containing notes for administrators.
- “s” Service type. The type of service this key may be used for, may be “*” for all services or “email”. Not to be confused with the “s” tag that can appear in the DKIM-Signature field of an email header!
- “t” Flags. A colon-separated list of flags. Valid flag values are “y” and “s”. Use “y” to indicate that DKIM is in testing mode. Use “s” to indicate that the domain in the DKIM-Signature must exactly match the domain the message was sent from (and must not be a subdomain).
Finding DKIM records for a domain
Like SPF and DMARC, DKIM records are stored as TXT records in the DNS. So the dig or nslookup command line tools with query type TXT can be used.
Unlike SPF and DMARC, however, a little more information is needed to know what DNS name to use for the TXT lookup because DKIM often uses selectors.
You can use the “show original” option in Gmail (or a similar option in your mail client) to view a raw email message and find the DKIM-Signature. Here is an example from a recent email sent by Google:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=to:from:subject:message-id:list-id:feedback-id:list-unsubscribe :precedence:reply-to:date:mime-version:from:to:cc:subject:date; bh=20sEX7VfkwWYovzA9s67DASRk/vrLDfnoMIxPqE3RWY=; b=dOpodEh2qKx2TzLIxvtjCG4NHbdWHUcAC4pw018ABPS2rEGXCIhBD5nbX0kUMrLJ6E NMCX7p5qW+HfBghAxWTk1q2dWbnMNtalpBYFgNdxgU6DtEuwiuZIrMGJUl32pfgttbzq /CnNS6z6nLkEoUWXpwXNMBmYhPpC7/26MFF324A6l71bAKUQDfb/QNWsYyAuRwNHnHnS CgTB1dERPMdgl9YJb6PiB3UIV8PlOsA3jYq1AHzMEICBaqK/Qr6SfwNA6x0gwkdfszlt LMwNVR8i7/VZkUjSHEZPbB8tYiQedg6oW+0eCB/GYia2V3qqFIfudg3pYAYkG+jugbtZ HVmg==
The DKIM-Signature is long and includes many fields, including the header fields that were signed and a digital signature of the message.
But only the “s” and “d” tags are needed to find the DKIM record. The “s” tag gives the selector and the “d” tag gives the domain. So in this example, the DKIM selector is 20210112 and the DKIM domain is google.com. Combine these two strings with _domainkey in between to determine the DNS lookup name for the DKIM record: 20210112._domainkey.google.com.
This name can be looked up using dig with query type TXT to find the DKIM record for this message:
dig +short txt 20210112._domainkey.google.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtnbQAeqvEP2pG2L540W9JvVU7qy767Zs83Hjw34PCkZ9/9dWE6cK+CYaMNIQqTGfwq4uUe3diBuz3Uikkr+WPMj9AuxtxJqUAO8PsZ2Y5DneFpz5kVesC9/rtXgCwgYOmO" "9UjSy4IN11ewXUBuCH+zp2v5Abv5T0Lol/nWl8wLgRI1IesstingY4cnSfo3Pq3U0I1GAxdNFCK2FPedPpg4sdPpHqtxVvRLMLamRKoUfySBMjpXuMNL0UeCizmFfdUL73ZdiS+MNxGECzFNmeCngFBscLQN++urvfB9OqHQrbxLIwNyni3KMbE/E+cxPkx4KxhyGHSU2klV1vvIAHfwIDAQAB"On operating systems that support nslookup, you could use the following:
nslookup -type=TXT 20210112._domainkey.google.com.Once you have the selector and domain, you can also find the DKIM record using our TXT lookup tool, or by entering it here:Domain nameFind TXT records
You may also need DMARC and SPF
DKIM is only part of the story for securing email. There are three pillars of email security:
- Sender Policy Framework (SPF): SPF ensures that only authorized mail servers can send mail for a domain.
- Domain-keys Identified Mail (DKIM): DKIM uses public key cryptography to validate the sender’s authenticity and to protect email messages from tampering.
- Domain-based Message Authentication, Reporting, and Conformance (DMARC): DMARC adds policy and reporting. It prevents spammers from abusing the Return-Path field to evade SPF and enforces DKIM-signed email. DMARC also allows administrators to control how messages that fail SPF and DKIM checks should be treated.
While adding DKIM to your domain is a good start, consider adding SPF and DMARC to protect your domain and brand from abuse.
Read my next article to learn the difference between MX, SPF, DKIM, DMARC and BIMI.