A 1024-bit DKIM key fits in a single DNS TXT string. A 2048-bit key does not, and that one fact explains most of what goes wrong when a domain upgrades: the record has to be published as several quoted strings that a verifier joins back together, and the tooling in between does not always cooperate. The key that comes out the other side is shorter than the one you generated, and nothing in your mail flow says so.
RFC 8301 named this out loud in 2018. It requires signers to use at least 1024 bits and recommends at least 2048, and it explains in the same document why the stronger keys stayed rare: DNS provisioning software that handles only one 255-byte string in a TXT record cannot hold them.
The key length is the p= value, and only the p= value
A DKIM record is a TXT record at <selector>._domainkey.<domain> holding a public key. The p= tag carries it, base64-encoded, and its length is the key's length. Nothing else in the record states the strength: there is no bits tag, no algorithm size, no field a DNS panel could show you.
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
For an RSA key, p= holds a SubjectPublicKeyInfo structure: a nested container carrying the algorithm identifier and then the modulus and exponent. The bit length is the width of that modulus, which is why reading it means parsing the structure rather than measuring the string.
That matters more than it sounds, because the string length and the key length come apart the moment anything truncates the value.
2048 bits does not fit in one DNS string
A DNS TXT record is made of character-strings, each at most 255 bytes. Longer values are published as several quoted strings that a receiver concatenates with no separator between them. Measured on freshly generated keys, here is what each size actually costs.
| Key | base64 p= value | Whole record | DNS strings needed |
|---|---|---|---|
| RSA 1024 | 216 characters | 234 | 1 |
| RSA 2048 | 392 characters | 410 | 2 |
| RSA 4096 | 736 characters | 754 | 3 |
| Ed25519 | 44 characters | 66 | 1 |
RFC 8463's own example record publishes an RSA key across four quoted strings, and a verifier concatenates them with nothing in between. That is correct DNS, and a verifier handles it without difficulty.
The failure is upstream of the verifier. A provisioning panel that accepts only one string silently keeps the first 255 characters. A panel that accepts the whole thing but inserts a space or a newline where the quotes were produces a base64 value with a character that is not in the alphabet. An export and re-import through a zone file can lose the quoting entirely. Every one of these produces a record that still starts with v=DKIM1; k=rsa; p= and still looks right in a browser.
A truncated key reads as a confident 2048 to anything that trusts the record
This is the part worth being careful about, because it decides whether a checker is useful.
The length of an RSA modulus is declared inside the key structure. A reader that trusts the declared length finds the modulus header, reads the number of bytes it claims, and reports the size those bytes would represent. If the value was cut off after that header, the declared length is still 2048 bits' worth even though the bytes are not there, so the reader answers "2048" with no hesitation. Cut a real key at every byte offset and the overwhelming majority of those cuts are reported as an intact key of the intended size.
Our own DKIM checker requires every nested length in the structure to end exactly where its parent ends. A key truncated anywhere, or carrying trailing garbage, fails to parse rather than reporting a shorter or an intended size, and an unparseable key is reported as a failure rather than as an absent one. A key that verifies nothing and a key that is not published are different problems with different fixes, and a checker that reports them the same way sends you to the wrong place.
Across the domains we test for the Unspam 2026 Email Deliverability Benchmark, 90% sign with a working DKIM key, so this is not a gap in adoption. It is a category of quiet breakage inside the 90%.
An empty p= is a revocation, not a missing key
v=DKIM1; k=rsa; p= with nothing after the equals sign is a valid record, and it means the key has been revoked. RFC 6376 defines it that way deliberately, so a compromised key can be withdrawn without deleting the record and leaving verifiers to guess whether the name simply failed to resolve.
Treat the difference as real. A revoked selector is a decision somebody made; a missing selector is a rollout that did not finish. They look almost identical in a DNS lookup and they call for opposite responses.
The same applies to a rotation. Selectors exist so a domain can carry several keys at once, and s1._domainkey and s2._domainkey being live together is how a rotation happens without a gap. The signature names the selector it used, and a verifier looks up only that one, so publishing the new key before switching the signer is the safe order, and removing the old one before the last message signed with it has been delivered is the unsafe one.
Ed25519 keys are 32 raw bytes, not a key structure
RFC 8463 added Ed25519 signing, and the record for it is not shaped like the RSA one. With k=ed25519, the p= value is the raw 32-byte public key, not a SubjectPublicKeyInfo, which is why it encodes to 44 base64 characters and always fits in one DNS string.
The practical consequence is that any other length is not a key. A 30-byte stub, a truncated value, or an entire RSA key left behind under an ed25519 tag are all unusable, and a checker that reports "Ed25519, present" for any non-empty value tells you nothing. Verify the length, not the presence.
Adoption is still thin enough that Ed25519 is usually published alongside RSA rather than instead of it, because a verifier that does not support it treats the signature as unverifiable rather than falling back.
t=y makes the signature count for nothing, whatever the key is
The t tag carries flags, and t=y means the domain is testing. RFC 6376 tells a verifier it "MUST NOT treat messages from Signers in testing mode differently from unsigned email", which is stronger than ignoring failures: the signature contributes nothing at all, so DKIM cannot align, and a domain relying on DKIM alignment gets no DKIM pass while the flag is set.
Test flags are supposed to come off at the end of a rollout, and often do not. If a domain publishes a perfect 2048-bit key, signs every message, and still sits at DMARC failures it cannot explain, check this tag before anything else.
The other flag in the same tag is quieter. t=s forbids the signing identity from being a subdomain of d=, which is a deliberate tightening rather than a fault, and also the difference between a signer that works and one that stops the day somebody points a subdomain at the same key.
What to check on a key you already published
Six checks, in the order that finds problems fastest.
- The key parses at all. Not that a record exists at the selector, but that the value inside it is a complete key. This is the check that catches a truncated upgrade.
- The strength is at least 1024 and preferably 2048. Below 1024 a verifier must not treat the signature as valid; between 1024 and 2048 it is valid and below what RFC 8301 recommends.
p=is not empty, unless you revoked it on purpose.- No
t=y. If the rollout is finished, the testing flag should be gone. - Every platform that sends as you has its own live selector. Your ESP, your CRM, your helpdesk and your invoicing tool each publish one, and they are added at different times by different people.
- The selector in the signature resolves. A key published under a name the signer does not use is invisible.
DKIM passing is necessary and not sufficient, because DMARC needs the signing domain to align with the address in your From header, and a message can be signed perfectly by a platform's own domain and still fail. Our guide to DKIM signatures covers the record format, our guide to email authentication covers how the three records depend on one another, and the same shape of quiet failure on the SPF side is the subject of our guide to the SPF include mechanism.
To see the key a receiver actually reads, next to the signature result on a real message, run a free spam test.
