Two numbers govern DKIM key choice, and they pull in opposite directions. One is a security floor. The other is a transport ceiling that has nothing to do with cryptography and everything to do with how big a UDP DNS answer can be.
The floor: 1024 bits
RFC 6376 section 3.3.3, "Key Sizes," states it directly: signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 to 2048 bits, and MAY handle larger.
Read those two sentences together and the design intent is clear. The spec forbids issuing weak keys, but requires accepting them, because a verifier cannot control what a stranger publishes. So a 2048-bit signer is compliant, a 1024-bit signer is compliant, and a 512-bit signer is out of spec but must still be tolerated on the receiving side.
The ceiling: 512 bytes of UDP
The same section lists the factors that should influence key size, and the first one is not about security at all:
The practical constraint that large (e.g., 4096-bit) keys might not fit within a 512-byte DNS UDP response packet
This is why "use 4096 bits, it is more secure" is incomplete advice. A DKIM public key is published as a TXT record containing a base64-encoded DER blob. A 2048-bit key fits comfortably. A 4096-bit key produces a much larger record, and if the answer exceeds the UDP payload limit the resolver has to fall back to TCP — which some resolvers, firewalls, and middleboxes handle badly or not at all. The failure mode is a DNS timeout, which a verifier reports as a temporary lookup error, which in turn becomes a signature that could not be checked.
The RFC acknowledges the shape of the trade-off in the remaining bullets: keys below 1024 bits are subject to off-line attack, larger keys impose higher CPU cost to verify and sign, and keys can be rotated on a regular basis so their lifetime can be relatively short.
The remaining considerations, ranked
Given a floor of 1024 and a practical ceiling around 2048, the decision collapses to:
- 2048 — the default. Fits in UDP, well above the floor, CPU cost negligible for any modern verifier.
- 1024 — acceptable per spec, and appropriate where an old verifier is known to be in the path. Old but not broken.
- 4096 — rarely justified, and actively risky if the publishing domain's DNS does not handle TCP fallback cleanly. Test the resolver path before committing.
- 512 — out of spec for signing. Only relevant as a verifier requirement.
Selector rotation, the part people skip
DKIM keys live at a selector: <selector>._domainkey.<domain>. That selector is the whole reason rotation is cheap. You publish a second selector, start signing with it, wait for the DNS TTL and for in-flight mail to be verified, then retire the old one. No coordination with receivers, no flag day.
A practical rotation cadence is annual for a 2048-bit key, and immediately on any suspicion of private-key exposure. What breaks rotation is not cryptography but process: signing code that hardcodes the selector, or a key published but never actually used to sign, leaving a stale public key that reads as sloppy to anyone auditing.
How this shows up in testing
If you are testing a sending integration and signatures fail to verify, check in this order: does the selector resolve at all, is the published key the one that signed the message, did the message body change in transit (a footer injected by a relay breaks the body hash), and did the DNS answer time out. The last one is the 512-byte problem, and it looks identical to a missing record from the verifier's side.
The takeaway
Publish 2048-bit RSA at a named selector, keep the private key out of the repository, rotate annually by publishing a second selector first, and do not chase 4096 unless you have validated that the DNS path to your zone handles the larger answer. The spec's floor is 1024, its practical ceiling is what fits in a DNS packet, and everything between is a rotation and process problem rather than a crypto one.