Your DKIM key may be fifteen years old

by Francis Rozange | Sep 8, 2026 | Email Marketing

Abstract 3D render: a long weathered glass key beside a small freshly cut luminous one

DKIM signs your messages. It is the only one of the three authentications that survives a forward, the only one Yahoo requires before telling you who complained, and the only one without which your one-click unsubscribe button does not appear.

It is also the one you install once, usually when the mail server goes live, and never read again.

Since then, the standard has moved twice.

The base, and its two updates

DKIM is defined by RFC 6376, published in September 2011. It is one of the rare texts in the email ecosystem to hold Internet Standard status, the IETF’s highest normative level. For comparison, DMARC only reached the lower Proposed Standard status in May 2026.

That base was updated twice in 2018, and it is those two updates that matter today.

RFC 8301, in January 2018, tightened the cryptographic rules. RFC 8463, in September 2018, added a new signature algorithm.

What the rule in force says about your keys

The 2011 text asked for at least 1024 bits for long-lived keys, and required verifiers to be able to validate from 512 to 2048 bits.

RFC 8301 replaced that wording with a sharper rule, in section 3.2: “Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits.”

And above all, it closed the door from below: “Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures.”

A 512-bit key, perfectly acceptable in 2011 and still present in many older configurations, therefore no longer produces a valid signature. The message goes out, the signature is there, it does not count.

Yahoo restates exactly that rule in its sender requirements: 1024 bits minimum, 2048 recommended.

SHA-1 is forbidden, not discouraged

On the hash algorithm, RFC 8301 leaves no margin: “Due to the recognized weakness of the SHA-1 hash algorithm […] the SHA-1 hash algorithm MUST NOT be used.”

And in section 3.1: “Signers MUST sign using rsa-sha256. Verifiers MUST be able to verify using rsa-sha256. rsa-sha1 MUST NOT be used for signing or verifying.”

An rsa-sha1 signature is today a void signature. It nonetheless still appears, produced by mail appliances that have not been updated since 2017, and whose outbound headers nobody reads.

Ed25519, and why it does not replace RSA

RFC 8463 introduced a second signature algorithm, ed25519-sha256. Its public key is 256 bits, making it vastly more compact than a 2048-bit RSA key: it fits comfortably in a TXT record, where a long RSA key sometimes forces splitting contortions.

The temptation is therefore to switch. It would be premature, and the RFC itself sets out the approach, in section 6: “For backward compatibility, signers can add multiple signatures that use old and new signing algorithms.”

It states the associated technical constraint: each signature must use a different selector, since a selector carries only one key in DNS, even if the d= and i= identifiers stay the same.

Signing in Ed25519 only means betting that all your verifiers support it. Signing with both, each under its own selector, costs a few header bytes and removes the bet. That is our reading of the text, and it counts as an engineering judgement, not a normative obligation.

What breaks a signature, and what is not your fault

A DKIM signature covers a message body and a list of headers, named in the h= field. Anything that modifies either after signing breaks it.

The most frequent case is not a configuration error: it is a mailing list that prefixes the subject, appends a footer, or rewrites the links. The message stays legitimate, the signature becomes worthless, and DMARC alignment disappears with it.

ARC, the authenticated received chain defined by RFC 8617 in July 2019, exists to carry the original authentication verdict across those intermediaries. It has remained at Experimental status, which describes the situation rather well: the problem is identified, the solution is not standardised.

What to do tomorrow morning

Take a message you have just sent and read the DKIM-Signature header. Three fields matter.

a= must be rsa-sha256 or ed25519-sha256. If it says rsa-sha1, your signature has been worthless since 2018.

s= gives you the selector: query the corresponding TXT record and measure the public key size. Below 1024 bits, it is void.

h= gives you the list of covered headers. Check for List-Unsubscribe and List-Unsubscribe-Post if you send marketing messages.

The whole thing takes fifteen minutes and requires buying no tool. It is also what Sestaro does before a send: checking your SPF, DKIM and DMARC records, without ever generating a key on your behalf, because a signing key that is not yours signs in your name.

Sources

LaFactory works email on the evidence: headers, DNS records, rejection logs. No open rate promises, ever. Get in touch for a deliverability audit.