DKIM signatures explained: what makes a signature trustworthy

What is DKIM and how does a signature work?

DKIM (DomainKeys Identified Mail, RFC 6376) lets a sending system sign each message with a private key. The receiving server fetches the matching public key from DNS and checks the signature. If it verifies, the receiver knows that the signing domain took responsibility for the message and that the signed parts have not changed since.

The signature travels in a DKIM-Signature header that the sending system adds. A typical one looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=selector1; t=1767225600; h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR...

d= is the signing domain and s= the selector, which together tell the receiver where to find the key. a= is the algorithm, c= the canonicalisation, h= the list of signed headers, bh= a hash of the body and b= the signature itself. Optional tags such as l=, t=, x= and i= change what the signature covers and how long it is valid, and they are where most weak signatures go wrong.

Where is the DKIM public key published?

The public key is a TXT record at the selector name under _domainkey on the signing domain. For the signature above, the receiver looks up selector1._domainkey.example.com:

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

k= is the key type (rsa when it is left out) and p= the public key in base64. A 2048-bit RSA key is longer than the 255 characters one TXT string may hold, so it is published as several quoted strings in the same record, which receivers join together. Each selector must resolve to exactly one key record. If the selector is missing, or two key records answer at the same name, no receiver can reliably verify the signature.

The key record can also carry flags. An empty p= means the key has been revoked, and signatures made with it will not verify. t=y marks the key as being tested, which tells receivers to ignore verification failures, so nothing is enforced while it is set. Remove it once signing works. t=s means the i= identity in a signature must use exactly the d= domain and not a subdomain of it.

Why must the DKIM domain match the From domain?

DKIM on its own only proves something about the d= domain, which can be any domain the sender controls. DMARC adds the link to the address the recipient sees: a DKIM pass only counts for DMARC when the d= domain is aligned with the domain in the From header.

With relaxed alignment, the default, the d= domain and the From domain must belong to the same organisational domain, so a signature with d=mail.example.com aligns with From: news@example.com. With strict alignment (adkim=s in the DMARC record), the two must be identical.

This is why third-party senders matter. A newsletter tool or CRM that signs with its own domain produces a valid signature that does nothing for your DMARC result. Ask each provider to sign with your domain. They usually call it custom DKIM or a branded sending domain, and you publish the key or a CNAME they give you under your own _domainkey name.

Which DKIM algorithm and key length should I use?

• rsa-sha256 is the standard choice and is verified by every receiver.
• rsa-sha1 is obsolete. RFC 8301 removed SHA-1 from DKIM because collisions are practical, and receivers increasingly refuse such signatures. Treat it as a failure and move to SHA-256.
• ed25519-sha256 (RFC 8463) gives short keys and strong security, but not every receiver verifies it yet. Use it as a second signature alongside an RSA one, not instead of it.
• RSA keys should be 2048 bits. A 1024-bit key still verifies but is a legacy key to replace at the next rotation. Keys shorter than 1024 bits are not allowed by RFC 8301, and several large receivers refuse them.

The key type in DNS must match the algorithm in the signature. An ed25519-sha256 signature cannot be verified against an RSA key, and the other way around, so publish each key under its own selector.

Which headers should a DKIM signature cover?

The h= tag lists the headers the signature protects. From is the one that must be there. RFC 6376 requires it, and a signature that does not cover From proves nothing about the sender the recipient sees, so it cannot support a DMARC pass however strong the cryptography is.

Beyond From, signing Subject, Date, Message-ID, To, MIME-Version and Content-Type narrows what can be changed after sending. Some headers are legitimately rewritten in transit, so leaving one of them unsigned is not a fault in itself.

As advanced hardening, you can oversign sensitive headers by listing their names one more time than they appear in the message:

h=from:from:subject:subject:date:to:message-id

The extra entry signs the absence of a second copy, so anyone who adds another From or Subject header breaks the signature. Not every mail platform lets you configure this.

What are the risks of the l=, x= and t= tags?

• l= limits the signature to the first so many bytes of the body. Anything appended after that point does not break the signature, so added text, or a different message entirely, inherits your domain's authentication. Remove l= so the whole body is signed.
• x= sets an expiry time. Leaving it out is normal. If it is set, a signature that has expired is treated as a failure, and delayed or queued mail is hit hardest. A lifetime of more than about 30 days is worth shortening, because anyone who later gets hold of the private key can replay messages that still verify.
• t= records when the message was signed. A timestamp more than about an hour in the future usually means the signing system's clock is wrong, and some receivers reject such signatures.

The i= tag can name a user or subdomain on whose behalf the message was signed. Leaving it out is normal. If it is set, its domain must be the d= domain or a subdomain of it, and only the d= domain itself when the key sets t=s. Otherwise the signature fails verification.

Is relaxed canonicalisation less secure than simple?

No. Canonicalisation (the c= tag) decides how headers and body are normalised before they are signed and verified. Simple tolerates almost no changes. Relaxed tolerates the harmless changes mail systems make in transit, such as different whitespace and refolded header lines.

Relaxed is not a weaker choice. It is what lets signatures survive normal delivery, and relaxed/relaxed is a sound production setting. Any of the standard combinations is fine. When c= is left out, simple/simple applies. Only an unrecognised value is a problem, because receivers are likely to ignore it.

How do I rotate DKIM keys without breaking mail?

Rotating means replacing the key pair, which limits the damage if a private key leaks. The safe way uses two selectors, so there is never a moment when mail is signed with a key that is not published:

1. Generate a new key pair and publish the public key under a new selector, such as selector2._domainkey.example.com.
2. Wait until the record has spread through DNS, at least the record's TTL.
3. Switch the sending system to sign with the new selector.
4. Keep the old selector published for a few days, until mail that was signed and queued with the old key has been delivered.
5. Revoke the old key by publishing it with an empty p=, or remove the record.

Many providers handle this for you: you publish two CNAME records once, and they rotate the keys behind them. DNS does not let anyone list the selectors under _domainkey, so an outside check of one message only sees the selector that message used. Confirm with each provider that a second selector is in place and that keys are replaced on a schedule.

DMARC Vision's free Email Security Check reads the DKIM signature on a message you send to it, looks up the published key, and reports on the points in this guide that one message can show.