What is DKIM, and how does the signature work?

What does a DKIM signature actually sign?

RFC 6376 defines DKIM around a DKIM-Signature header the sending server adds to the message before it leaves. That header carries several tags: v=1 for the version, a= for the signing algorithm, d= for the domain claiming responsibility, s= for the selector (covered below), h= for the list of headers that were signed, bh= for a hash of the message body, and b= for the signature itself. RFC 8301 tightened the algorithm requirement in 2018: signers must use rsa-sha256, and rsa-sha1 must not be used for signing or verifying at all.

Verification works backward from that header: the receiving server reads d= and s=, fetches the matching public key from DNS, and checks whether the signature in b= is valid for the headers and body the message actually contains. If anything covered by the signature changed after signing, even a single character, verification fails.

Where is the public key published, and what is a selector?

The public key lives in a DNS TXT record at selector._domainkey.domain, where selector is whatever short name the domain chose when it set up that particular key. RFC 6376 gives the example of a signature with d=example.com and s=foo.bar - the verifier queries foo.bar._domainkey.example.com. The record's value follows a tag=value syntax: v=DKIM1 for the version, k=rsa for the key type, and p= holding the base64-encoded public key itself (an empty p= value means the key has been revoked).

A domain can publish several selectors at once, each pointing at a different key, and different services often use different selectors. Google Workspace signs with the selector google, giving a record at google._domainkey.yourdomain. Microsoft 365 uses two fixed selectors, selector1 and selector2, though it publishes them as CNAME records pointing at Microsoft's own DKIM infrastructure rather than a raw TXT value, so key rotation happens on Microsoft's side without the domain owner touching DNS at all.

Why does key rotation use selectors instead of replacing a key in place?

Rotating a signing key by overwriting the existing DNS record is risky: any message still in transit, or any receiving server holding a cached copy of the old record, fails verification the moment the new key replaces the old one at the same name. Selectors avoid that by giving the new key its own DNS name. The usual sequence is to publish the new key under a new selector while the old selector and its record stay in place, switch the signing system over to the new selector once the new record has had time to propagate, and only remove the old selector's DNS record some time after nothing is signing with it anymore. Because each selector is an independent DNS name, old and new keys coexist for as long as needed with no verification gap.

Which headers get signed, and why does that matter?

The h= tag lists exactly which header fields are covered by the signature, and RFC 6376 requires that the From header always be among them. Beyond that mandatory minimum, signers commonly also cover To, Subject, Date, Message-ID and Content-Type, plus the message body through the separate bh= hash. Any header not listed in h= can be added, removed or reordered after signing without breaking the signature, which is why From being mandatory matters: it is the one field DKIM guarantees was not swapped out after the domain signed the message. A header that is listed but then gets modified in transit, or a body that changes after the hash was computed, breaks verification.

Why does DKIM survive forwarding when SPF does not?

SPF authenticates the connection - the IP address of whichever server is currently talking SMTP to the recipient. DKIM authenticates the message content instead, through a signature that travels inside the message itself rather than depending on where it came from. A message forwarded through an intermediate server keeps its original headers and body intact in most simple forwarding setups, so the same DKIM signature that was valid when the message was first sent is still valid when it arrives at its final destination, regardless of which server relayed it along the way. This is the main reason DKIM and SPF are used together rather than either alone: SPF breaks the moment a message changes hands, while DKIM keeps working as long as the signed content is not altered. A mailing list or forwarding service that rewrites the subject line or adds a footer to the body can still break DKIM, since that changes content covered by the signature - just not for the same reason SPF breaks.

How do you find a domain's DKIM selector when you do not know it?

The most direct source is a message the domain actually sent: open its raw headers and look for the DKIM-Signature line, then read the value after s=. That is the exact selector the domain used for that message. When no sample message is available, checking the well-known selectors of common providers is a reasonable next step - google._domainkey for Google Workspace, selector1._domainkey and selector2._domainkey for Microsoft 365 - by looking up the TXT (or CNAME) record directly:

dig TXT google._domainkey.example.com +short

A record with a v=DKIM1 value confirms the selector is active; no answer means that particular selector is not in use, and a different one, or a different provider, is signing the mail.

DKIM is one piece of a wider setup: see what an SPF record is for the sender-authorization check that runs alongside it, and what DMARC is for how a receiving server ties SPF and DKIM together into one pass-or-fail decision. The free MX lookup tool lists a domain's mail servers from HostTracker's network of checkpoints, useful alongside a DKIM check when confirming a domain's overall mail setup.

Frequently asked questions

Does DKIM encrypt the email?

No. DKIM only signs the message to prove its integrity and origin; anyone who intercepts the message can still read its contents. Encryption is a separate concern DKIM does not address.

Can a domain use more than one DKIM key at the same time?

Yes. Different selectors can hold entirely different keys, which is exactly how multiple sending services - a support desk platform and a marketing tool, for instance - each sign with their own key under the same domain without conflicting.

What key length should a DKIM key use?

RFC 6376 requires at least 1024 bits for a long-lived key, and RFC 8301 recommends going further: signers should use at least 2048 bits, while verifiers must be able to check signatures anywhere from 1024 up to 4096 bits. Most providers issuing new keys today default to 2048 bits.

What happens if a message fails DKIM verification?

DKIM itself does not reject or quarantine anything - it only reports pass or fail. What a receiving server does with a failed result is a policy decision made elsewhere, most often through the DMARC record covered in the next guide.

Is DKIM required for every outgoing message by protocol?

No, DKIM is optional at the protocol level. In practice, major inbox providers weigh its absence heavily enough in spam filtering that sending mail without any DKIM signature at all routinely lands in a spam folder even when nothing else about the message looks suspicious.