DKIM (DomainKeys Identified Mail)

tips_and_updates
Key Takeaways

DKIM attaches a cryptographic signature to every outgoing email and lets receivers verify, via DNS, that the message was not tampered with in transit.

Each DKIM key is identified by a selector, which lets a single domain publish multiple active keys for rotation and per-service signing.

2048-bit RSA is the modern minimum — 1024-bit keys are still common but should be retired during your next rotation cycle.

DKIM survives most forwarding scenarios that break SPF, which is why DMARC alignment usually relies on DKIM in the wild.

What is DKIM (DomainKeys Identified Mail)?

DomainKeys Identified Mail (DKIM), defined in RFC 6376, is an email authentication standard that attaches a cryptographic signature to every outgoing message. The signing mail server uses a private key held on the server; receiving mail servers use the matching public key — published in the sending domain’s DNS — to verify both that the message originated from an authorized signer and that the body and selected headers were not modified along the way.

DKIM is a complement to SPF. SPF authenticates the connecting IP; DKIM authenticates the message itself. Crucially, a DKIM signature survives forwarding (as long as the body and signed headers are preserved), which is why most DMARC alignment in the wild leans on DKIM rather than SPF.

How DKIM signing and verification works

When a mail server sends a DKIM-signed message, it computes a hash of selected headers (typically From, To, Subject, Date, and Message-ID) plus the body, encrypts that hash with its private key, and adds the result to the message as a DKIM-Signature: header. Verification follows the reverse path:

The receiving server reads the s= selector and d= domain tags from the DKIM-Signature header.
It queries DNS for {selector}._domainkey.{domain} and retrieves the public key.
It recomputes the body and header hashes using the same canonicalization rules the sender used.
It decrypts the signature using the public key and compares the result against the recomputed hashes. Match = DKIM pass.

Publishing a DKIM record

A DKIM record is a DNS TXT record at the subdomain {selector}._domainkey.{your-domain}. The selector is an arbitrary label that lets you publish multiple keys on the same domain — most providers will give you the selector when they hand over the key. A typical record looks like this:

DKIM record example (selector: s1)

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

DKIM record tags reference

Every DKIM public-key record is a semicolon-separated list of tag/value pairs. The ones you will actually see are:

vVersion: Currently always DKIM1. If present, it must be the first tag in the record.
kKey type: The key algorithm. rsa is universally supported; ed25519 is emerging but still poorly implemented by older receivers.
pPublic key (required): The base64-encoded public key. Setting p= (empty) explicitly revokes the selector — useful when you retire a key but want existing signatures to continue failing closed.
tFlags: Optional flags. t=y marks the key as test-mode (receivers should not penalize failures); t=s requires strict alignment between the i= identity and the signing domain.
sService type: Restricts which services may use this key. Almost always * (all) or email.
hAllowed hash algorithms: Optional. Set to sha256 to forbid the older, weaker sha1 hash.
nNotes: Free-form human-readable notes. Ignored by verifiers; useful for documenting the key inside the record itself.

DKIM key rotation strategy

Rotating DKIM keys regularly limits the blast radius if a private key is ever exposed. The standard zero-downtime rotation pattern relies on the selector system:

Generate a new key pair and publish the public key under a new selector — for example, alongside s1._domainkey you publish s2._domainkey.
Wait at least one DNS TTL so the new record is globally visible.
Switch your mail server to sign new mail with the s2 selector. Old in-flight mail still verifies against s1.
Leave both selectors live for two to four weeks while message archives, forwarders, and mailing lists drain.
Revoke s1 by emptying its p= value. Keep the now-empty record in DNS for a further month so retroactive verifications fail closed instead of failing open.

Verifying your DKIM setup

A DKIM record is easy to publish incorrectly and hard to debug without the right tools. Run the DKIM validator on every selector that signs production traffic — it will fetch the public key, reconstruct the record syntax, confirm the key size, and flag the common mistakes:

Missing or unreachable record. The most common failure mode — usually a typo in the selector or a DNS host that strips quotes from TXT records.
Key too short. Anything below 2048 bits is considered weak today. Gmail and Outlook both treat 1024-bit keys with extra suspicion.
Malformed base64. Whitespace, quote escaping, and line-break handling vary by DNS host — even a single stray character invalidates the entire key.
Test-mode flag still set. The t=y flag is fine while you stage a deployment but must be removed in production, otherwise receivers will not enforce failures.

Next steps

With SPF and DKIM both in place, you have a cryptographically-signed sending stack. The final layer — DMARC — tells receiving servers what to do when one of them fails, and gives you visibility through aggregate reports.

tips_and_updates Key Takeaways