DKIM Keys — Length, Algorithm and Signed Headers

A passing signature is not necessarily a good one

The DKIM check answers a binary question: does the signature match the key in DNS? This page answers the second, more awkward one: is the signature worth anything? A signature using a 1024-bit key that covers only the subject line and carries an l= tag formally counts as pass — and still protects almost nothing.

All of this sits in the message's DKIM-Signature header and in the TXT record at <selector>._domainkey.<domain>. The report reads both and puts them side by side.

What AnalyzeMy.Email checks

• Selector from the s= tag — the name under which the public key is published. It is the reason DKIM can only be verified with a real message and not from DNS alone.
• Signature algorithm from a= — rsa-sha256 is the standard, rsa-sha1 is obsolete and explicitly forbidden by RFC 8301. ed25519-sha256 is the modern alternative with a very short record.
• Key length from the record's p= tag, computed from the actual key material.
• Signed headers from h= — which header fields the signature actually covers.
• Body length tag l= — if set, the signature covers only the first n bytes of the message body.
• Canonicalization from c= — relaxed/relaxed survives minor reformatting in transit, simple/simple does not.

The record is reassembled correctly from multiple TXT strings along the way: a 2048-bit key does not fit into the 255 bytes a single character string holds, so it necessarily arrives split.

Where the weaknesses are

1024 bit. RFC 8301 sets 1024 as the absolute minimum and recommends 2048. Plenty of systems still sign with 1024 because the record then fits neatly into a single TXT string. That is not a sound reason — splitting across strings is standard and works everywhere.

The l= tag. It limits the signature to the first n bytes of the body. Anything after that can be appended by an attacker without breaking the signature — the message stays pass while carrying someone else's text at the bottom. No use case justifies that risk.

Too few signed headers. If From is not in h=, the signature is worthless for DMARC, because alignment refers to exactly that header. It is also worth covering Subject, Date, To and Message-ID. A header listed twice in h= is deliberate rather than a mistake: it prevents anyone from adding a second copy of that header.

Recommendations

• 2048-bit RSA as the default, rsa-sha256 as the algorithm.
• Do not set l=. If your mailer adds it by default, turn that off.
• h= must include from — without it DKIM contributes nothing to DMARC.
• Ed25519 only in addition: not every receiver supports it. If you use it, sign twice and keep RSA as the fallback.
• Rotate keys regularly — across two selectors, so messages already in transit still verify.