How DKIM Works and Why Your Domain Needs It

DomainKeys Identified Mail (DKIM) is a cryptographic email authentication standard defined in RFC 6376. It allows a sending domain to digitally sign outgoing messages so that receiving servers can verify the message has not been altered in transit and that it was authorized by the domain owner. DKIM is one of the three pillars of modern email authentication, alongside SPF and DMARC.

The Problem DKIM Solves

SMTP, the protocol that moves email across the internet (RFC 5321), was designed without built-in authentication. Any server can claim to send mail from any domain. SPF addresses part of this by validating the sending IP, but it cannot detect message tampering after the email leaves the originating server. DKIM fills this gap by providing cryptographic integrity verification tied to the signing domain.

How DKIM Signing Works

DKIM relies on public key cryptography. The process involves two phases: signing by the sender and verification by the receiver.

Signing Phase

1. The domain owner generates an RSA (or Ed25519) key pair: a private key and a public key.
2. The private key is installed on the outgoing mail server or email service provider.
3. When the server sends a message, it selects specific header fields (typically From, To, Subject, Date, and MIME-Version) and the message body.
4. The server computes a hash of the selected headers and body, then encrypts the hash using the private key.
5. The resulting signature is added to the message as a DKIM-Signature header field.

A DKIM-Signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1;
  h=from:to:subject:date:mime-version;
  bh=base64encodedBodyHash;
  b=base64encodedSignature

Key fields in this header:

• d= -- The signing domain.
• s= -- The selector, which identifies which public key to retrieve from DNS.
• h= -- The list of signed header fields.
• bh= -- The hash of the canonicalized message body.
• b= -- The actual cryptographic signature.
• c= -- The canonicalization method (simple or relaxed) for headers and body.

Verification Phase

1. The receiving server extracts the d= and s= values from the DKIM-Signature header.
2. It queries DNS for a TXT record at selector._domainkey.domain.com.
3. The TXT record contains the public key (the p= tag).
4. The server uses the public key to decrypt the signature and compares the result against its own hash of the received headers and body.
5. If the hashes match, DKIM passes. If they differ, the message was modified in transit or the signature is invalid.

You can verify any DKIM record using the InboxTooling DKIM verification tool.

Selectors: Managing Multiple Keys

The selector mechanism allows a domain to publish multiple DKIM keys simultaneously. This is essential for several reasons:

• Multiple sending services. If you use Google Workspace for corporate email and SendGrid for transactional email, each service uses a different selector (e.g., google._domainkey and s1._domainkey).
• Key rotation. You can publish a new key under a new selector, transition your sending infrastructure to sign with the new key, and then remove the old selector from DNS.
• Testing. You can deploy a new key without disrupting existing mail flow.

A DKIM DNS record takes this form:

selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

The k= tag specifies the key type (RSA is most common; Ed25519 is gaining adoption). The p= tag contains the base64-encoded public key. If the p= tag is empty, the key has been revoked.

Canonicalization

Email messages can be subtly modified in transit by mail relays. Whitespace may be added or removed, line endings may change, and headers can be rewritten. DKIM uses canonicalization algorithms to normalize the message before hashing, reducing false failures.

RFC 6376 defines two canonicalization modes:

• Simple -- Almost no normalization. Even trivial changes to whitespace or header case will break the signature.
• Relaxed -- Tolerant of whitespace and header case changes. This is the recommended setting for most deployments.

The c= tag in the DKIM-Signature header specifies the mode for headers and body separately (e.g., c=relaxed/relaxed).

Key Rotation

DKIM private keys should be rotated periodically to limit the impact of key compromise. The recommended rotation process:

1. Generate a new key pair.
2. Publish the new public key in DNS under a new selector.
3. Wait for DNS propagation.
4. Configure your sending infrastructure to sign with the new private key and selector.
5. Monitor for verification failures using the header analyzer or DMARC aggregate reports.
6. Once all mail is signing with the new key, remove the old public key from DNS.

RSA keys should be at least 1024 bits, though 2048 bits is the current best practice. Keys shorter than 1024 bits are rejected by most major providers, including Gmail and Microsoft.

DKIM and DMARC Alignment

DKIM alone does not enforce policy. A failed DKIM check results in a header annotation, but the message is still delivered. DMARC changes this by requiring that the domain in the DKIM signature (d= tag) aligns with the domain in the visible "From" header. When DMARC is configured with p=quarantine or p=reject, messages that fail both SPF and DKIM alignment are quarantined or rejected.

This is why DKIM is critical even if you already have SPF. In forwarding scenarios, SPF often breaks because the forwarding server's IP is not in the original domain's SPF record. DKIM signatures, however, survive forwarding intact (assuming the message body and signed headers are not modified). A valid DKIM signature becomes the only path to DMARC alignment in those cases.

Verifying Your DKIM Configuration

Use the DKIM verification tool to check that your public key is published correctly and that the key length meets current standards. The header analyzer can parse the DKIM-Signature from an actual email to confirm the signature verifies end-to-end. For a comprehensive check of all authentication layers, run a full domain analysis.

FAQ

How does DKIM signing work?

DKIM signing works by generating a cryptographic hash of selected email headers and the message body, then encrypting that hash with a private key held by the sending mail server. The encrypted hash is added to the email as a DKIM-Signature header. The receiving server retrieves the corresponding public key from the sender's DNS records and uses it to decrypt and verify the hash, confirming that the message was not altered in transit.

How often should I rotate DKIM keys?

Best practice is to rotate DKIM keys every 6 to 12 months, or immediately if you suspect a key has been compromised. Rotation involves publishing a new public key under a new selector in DNS, configuring your mail server to sign with the new private key, and then removing the old public key after a transition period. Use the DKIM Verify tool to confirm that your new key is published and working correctly before removing the old one.

What does a DKIM selector mean?

A DKIM selector is a label that allows a domain to publish multiple DKIM public keys simultaneously. The selector appears in the DKIM-Signature header's s= tag and tells the receiving server which DNS record to query for the public key. For example, a selector of google means the public key is published at google._domainkey.yourdomain.com. Different selectors let you use separate keys for different sending services or facilitate key rotation without downtime.

Does DKIM survive email forwarding?

DKIM signatures generally survive email forwarding as long as the forwarding server does not modify the signed headers or the message body. This is a significant advantage over SPF, which breaks on forwarding because the forwarding server's IP is not in the original domain's SPF record. However, some mailing lists and forwarding services alter subject lines or append footers, which will break the DKIM signature. In those cases, ARC (Authenticated Received Chain) headers can help preserve authentication results.

How do I test if DKIM is set up correctly?

Use the DKIM Verify tool to check that your public key is published in DNS with the correct selector and that the key meets minimum length requirements (2048 bits recommended). To verify end-to-end signing, send a test email and examine the Authentication-Results header using the Full Report tool. A passing result confirms that your private key is signing correctly and the public key in DNS matches.

---

Stay on top of your email infrastructure. Sign up for the InboxTooling newsletter for deliverability tips, tool updates, and best practices.