DKIM 1024 vs 2048 bits: what RFC 8301 actually requires before you rotate a selector

Read the raw signal before interpreting it

RFC 8301 updates DKIM crypto requirements: signers must use rsa-sha256, RSA keys must be at least 1024 bits, and 2048 bits is recommended. Verifiers must not treat signatures made with RSA keys below 1024 bits as valid.

Key length is only one part of DKIM validity, but it is an important baseline. RFC 8301 tightened DKIM cryptographic guidance: RSA keys below 1024 bits are not acceptable, and 2048-bit signing is recommended where DNS and software support it. A longer key does not improve inbox placement by itself; it improves the cryptographic strength of the identity assertion. Before rotating, confirm what the signing service can generate, whether the DNS provider can publish the public key correctly, and whether any downstream verifier has unusual constraints. Most modern hosted providers handle 2048-bit keys, but a migration plan still needs to account for selector publication and overlap.

A tempting conclusion to avoid

The bit length belongs to a key pair, not to the visible TXT string by itself. Replacing a public key in DNS without making the signer use the corresponding private key will make every new signature fail.

The common operational failure is not “2048 is too secure.” It is publishing the new public key incorrectly. Long DKIM TXT values may be displayed as multiple quoted strings by DNS interfaces; DNS concatenates those character strings within one TXT record, which is different from publishing multiple independent TXT records at the selector. Another mistake is replacing the old selector before the new signer is actually using the new one. That creates a window where messages carry a selector that receivers cannot resolve. Treat key strength, selector identity, DNS representation, and signer rollout as separate checks.

Test the same layer the receiver or server tested

Read a real DKIM-Signature to capture d=, s= and a=. Query selector._domainkey for the public key, identify the provider that owns the private key, and use provider tooling or a trusted parser to confirm key size.

Test the new selector before switching production signing. Query the selector TXT record from an external resolver and confirm the reconstructed `p=` value matches the key generated by the signing system. Send a message using the new selector to at least one external mailbox and inspect DKIM-Signature plus Authentication-Results. Keep the old selector published during a controlled overlap so delayed messages signed with the old key can still verify. Only after the new selector is consistently observed should you retire the old public key according to your queue and retention window.

Repair, then repeat the original test

Create a new selector with an appropriate key, publish and verify its public half, switch the signer to the new selector, then keep the old selector available long enough for previously signed mail to finish delivery.

A small sender gains more from a predictable rotation process than from frequent arbitrary key changes. Document selector names, key size, generation date, signing service, DNS owner, activation date, and planned retirement. Prefer 2048-bit RSA when the service supports it cleanly, but do not hand-edit a key into a format your provider does not expect just to satisfy a numeric target. After rotation, verify real messages rather than stopping at DNS lookup. The success criterion is a valid DKIM result using the intended signing domain and selector, with DMARC alignment still behaving as designed.

A realistic low-volume case

Moving from legacy1024._domainkey to mail2026._domainkey lets both public keys coexist during the cutover. Receivers verify each message using the selector written into that message; they do not guess the newest record.

Key rotation is a good time to check more than bit length. Confirm the selector is unique enough to distinguish rotations, the signing domain is the one you expect for DMARC alignment, and the private key never appears in DNS or source control. DNS publishes only the public key. If your provider offers an automated rotation workflow, prefer it over exporting private material. During overlap, old and new selectors can coexist because each message names the selector receivers should query. Retire the old public key only after queued and delayed messages signed with it no longer need verification. This creates a clean audit trail: “selector A, 1024-bit, retired on date X; selector B, 2048-bit, active from date Y.” The practical value is predictable authentication, not the cosmetic act of showing a larger number in a checker.

Operational telemetry to keep

Keep selector name, signing domain, algorithm, key length, first-seen date, last-seen date, and retirement date. That turns future key rotations into controlled changes instead of archaeology.

The safe stopping point

A 2048-bit key does not improve list quality or reputation by itself. Cryptographic hygiene is necessary for trustworthy authentication, but it cannot compensate for complaints, bad recipients, or sudden volume.

Field checklist

• Capture the raw evidence for DKIM 1024 vs 2048 RSA key length RFC 8301 before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using dkim-rfc, dkim-crypto-rfc rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for DKIM 1024 vs 2048 bits: what RFC 8301 actually requires before you rotate a selector and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.