DNSVerdictAll toolsGuidesHow it works

DKIM key length: 1024 vs 2048 bits (and Ed25519)

Published · Updated

Publish a 2048-bit RSA key if your mail service and DNS host allow it. 1024 bits is the floor: RFC 8301 §3.2 says verifiers “MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures”, so a 512-bit or 768-bit key makes DKIM fail at every receiver that follows the RFC. The same section says signers “SHOULD use RSA keys of at least 2048 bits”. If the DKIM checker reports a key that is too short, generate a new, longer key under a new selector and switch signing to it.

What the RFCs require

RFC 6376 §3.3.3 (2011) told signers to use RSA keys of at least 1024 bits for long-lived keys, while verifiers had to handle keys from 512 to 2048 bits. That is why 512-bit keys once worked. RFC 8301 (2018) changed this in §3.2:

Short keys fail because they can be factored offline, after which an attacker can sign mail as your domain. A 2048-bit key moves that out of practical reach for now.

Key size to verdict

Key sizeVerdictWhat happens
512, 768 bitsFailSignature is invalid under RFC 8301; replace the key
1024 bitsPass, weakMeets the minimum; fine as a fallback when the DNS host cannot store 2048
2048 bitsPass, recommendedMatches the RFC 8301 SHOULD; verifiers must support it
4096 bitsValid, rarely worth itVerifiers must handle it, but the record is long and some hosts reject it
Ed25519 (k=ed25519)Valid, extra signature onlySmall key; use alongside RSA, not instead of it

Why a 2048-bit record looks “split”

A single DNS character-string holds at most 255 bytes. A 2048-bit public key encoded in base64 is longer than that, so the TXT record carries two or more quoted strings. RFC 6376 §3.6.2.2 says strings in a TXT record “MUST be concatenated together before use with no intervening whitespace”. Seeing a record in pieces is normal:

mail2026._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                                           "...remaining base64..." )

Many DNS panels split the value for you. Where a panel rejects the long value, enter it in chunks of up to 255 characters without inserting a space inside the key. Google also notes that some domain providers limit TXT record length. If your host cannot do either, fall back to 1024 bits, accepting the weaker key. The DNS lookup shows what resolvers return; the DKIM checker joins the strings before judging the key.

Rotate to 2048 bits

Rotate under a new selector so messages in transit still verify against the old key (RFC 6376 §3.1). Each provider’s steps below come from its own documentation.

Google Workspace. In the Admin console, go to Apps > Google Workspace > Gmail > Authenticate email, select the domain, click Generate New Record, and choose a 2048 key bit length. Google’s page says to choose 1024 only if your DNS host does not support 2048-bit keys. The default prefix selector is google; if your domain already has a key with that prefix, enter a different one. Publish the TXT record, then click Start authentication.

Microsoft 365. Microsoft publishes two CNAME selectors (selector1, selector2) that point at keys it holds, so you change the size in Exchange Online PowerShell, not in DNS:

Rotate-DkimSigningConfig -Identity example.com -KeySize 2048

Valid values are 1024 and 2048. The size change applies only to the selector that is not currently active. Microsoft’s documentation says that after a rotation you run the command again to upgrade the other selector. Check that signing is enabled afterward and that both CNAMEs still resolve.

Zoho Mail. In the Admin Console open Domains, select the domain, then Email Configuration > DKIM. Add a selector and select a key length of 1024 or 2048 bits, copy the generated TXT value into your DNS host, then click Verify and enable DKIM. Use a new selector name so the old key keeps working until you switch.

After any change, send a test message and paste its headers into the email header analyzer. Confirm the DKIM-Signature shows the new s= selector and that the result is dkim=pass. The provider setup check tests the selectors published for providers in our database. For the basics of selectors and revocation, see How DKIM works and how to publish a DKIM record.

Ed25519 and dual signing

RFC 8463 adds the ed25519-sha256 algorithm. The key record uses k=ed25519, and p= holds the public key in base64, 44 characters, so no string splitting is needed:

ed2026._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=<44-character base64 key>"

RFC 8463 §6 describes signing each message twice, with the old and new algorithm. Because a selector holds one key record, the two signatures must use different selectors, for example mail2026 for RSA and ed2026 for Ed25519. The RFC says verifiers MUST implement Ed25519-SHA256. We could not verify how widely major receivers do so in practice, and Microsoft’s Rotate-DkimSigningConfig documentation states that Ed25519 keys are not supported. So an Ed25519 signature on its own is a risk: a receiver that ignores it sees an unsigned message. Keep an RSA signature on every message and treat Ed25519 as an addition.

FAQ

Will a 1024-bit key make my mail fail? No. It meets the RFC 8301 minimum. Prefer 2048 bits because RFC 8301 recommends it, and keep 1024 only when your DNS host cannot store the longer record.

My 2048-bit key shows up as two quoted strings. Is it broken? No. A DNS character-string is limited to 255 bytes, and verifiers join the strings with no whitespace in between (RFC 6376 §3.6.2.2).

Can I change the key size without changing the selector? You can overwrite the record, but RFC 6376 §3.1 advises new selectors for new keys. A new selector lets mail signed with the old key verify until you remove it.

Sources

Tools used

DKIM Record CheckerEmail Provider Setup CheckEmail Header Analyzer