DKIM Key Length and Rotation: 1024 vs 2048-bit, Measured

Use a 2048-bit RSA key for DKIM. The standard requires at least 1024 bits and recommends 2048, and Google and Yahoo say the same. Rotate keys at least every six months by publishing the new key under a new selector, switching signing to it, and retiring the old key with an empty p= value after a week or more.

That much is settled. What surprised us was how many large companies haven't done it. We measured.

What we found in published keys

DKIM public keys are in public DNS, so anyone can check their length. On 1 October 2026 we looked up the google._domainkey selector, the default for Google Workspace, on a set of well-known domains that publish one, and decoded each key with openssl.

Domain	Selector	Key length
github.com	google	2048
atlassian.com	google	2048
canva.com	google	2048
theguardian.com	google	2048
gitlab.com	google	1024
stripe.com	google	1024
shopify.com	google	1024
netflix.com	google	1024
spotify.com	google	1024
airbnb.com	google	1024
uber.com	google	1024
zoom.us	google	1024
figma.com	google	1024

Nine of these 13 Workspace keys are 1024-bit. Other selectors we checked showed a similar mix: the microsoft.com selector that currently resolves to a key (selector2) is 1024-bit, as is Mailchimp's k1, while HubSpot's hs1 and hs2 are 2048. Yahoo publishes both a s1024 and a s2048 selector.

This is a small sample of selectors we could guess, not a survey. Many of these companies sign their marketing mail through other platforms under other selectors. But it shows the pattern clearly: keys get created once at setup, and nobody goes back.

You can check your own with this, replacing the selector and domain:

dig +short TXT google._domainkey.example.com | tr -d '" \n' \
  | sed 's/.*p=//' | base64 -d 2>/dev/null \
  | openssl pkey -pubin -inform DER -noout -text | head -1

The output reads Public-Key: (2048 bit) or (1024 bit). Our DKIM checker does the same lookup in a browser.

What the standards and providers require

Source	Minimum	Recommendation
RFC 8301 (updates DKIM)	"Signers MUST use RSA keys of at least 1024 bits"	"Signers SHOULD use RSA keys of at least 2048 bits"
Google sender guidelines	1024 bits for personal Gmail	"we recommend using a 2048-bit key if your domain provider supports this"
Yahoo FAQ	"1024 bits or greater"	"a 2048-bit key length for improved security, if possible"
M3AAWG rotation BCP (2019)		Calls 1024-bit keys "at the edge of attack" and 2048-bit "immune to cracking in today's computing environment"

RFC 8301 also says verifiers must not treat signatures with keys under 1024 bits as valid, so a 512-bit key isn't weak, it's a failure.

Why so many keys are still 1024

Defaults. The two biggest business mail platforms both still offer 1024:

• Google Workspace lets the admin choose 2048 or 1024 when generating a key, with 1024 described as the option "If your domain host doesn't support 2048-bit keys." Whatever was chosen at setup stays until someone generates a new key.
• Microsoft 365: in Microsoft's own DKIM configuration documentation, the -KeySize parameter of New-DkimSigningConfig lists 1024 as the default. Upgrading means running Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048.

Nothing breaks when a key is 1024-bit, so nothing prompts anyone to change it.

The 255-character problem

The practical reason people end up on 1024 is DNS. A single string inside a TXT record can be at most 255 characters. A 1024-bit key fits, and a 2048-bit key (about 392 base64 characters) does not, so the record has to be split into several quoted strings:

google._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
                           "...remaining part of the key...IDAQAB" )

Receivers join the strings back together. Your DNS panel decides whether you have to split it yourself:

DNS panel behaviour	What to do
Splits long values automatically	Paste the whole key
Accepts multiple quoted strings	Paste it pre-split, each part under 255 characters, in quotes
Rejects anything over 255	Use a CNAME to a provider-hosted key if offered, or move DNS hosting

After publishing, look the key up and decode it with the command above. If the decode fails, the split went wrong, usually a stray space or a missing quote at the join.

How rotation works

Rotation means replacing the key pair you sign with. The reasoning in the M3AAWG Best Common Practice is that a key can be stolen or cracked over time, and limiting how long one key is in use limits the damage. M3AAWG revised its recommendation in 2019 from quarterly to "at least every six months", suggesting fixed months such as April and October.

The method relies on selectors. Because the selector is named in every signature (s=), you can have several public keys published at once and switch between them without a gap.

1. Generate a new key pair and publish the public key under a new selector. Don't reuse old selector names. M3AAWG strongly discourages it because messages signed with the old key will then fail re-validation.
2. Wait for DNS to propagate, then check the new key resolves and decodes.
3. Switch signing to the new private key.
4. Keep the old public key published for 7 to 30 days (M3AAWG's range), so mail already in transit or queued can still be verified.
5. Retire the old key by publishing its record with an empty p=. Don't delete it. RFC 6376 defines an empty p= as "this public key has been revoked", which tells anyone checking that you retired it deliberately.

Google does exactly this on its own domain. The selectors on gmail.com are named after dates. On 1 October 2026, 20251104._domainkey.gmail.com held a 2048-bit key, while 20230601, 20221208, 20210112 and 20161025 were all still published with an empty p=. Date-named selectors are also what M3AAWG suggests, because they make audits easy.

Rotation on Microsoft 365

Microsoft handles the mechanics with two CNAME selectors (selector1 and selector2) that point at keys it hosts. Only one is active at a time. When you rotate, from the Defender portal or with Rotate-DkimSigningConfig, Microsoft's documentation says "It takes four days (96 hours) for the new private key to start signing messages." Check RotateOnDate and SelectorAfterRotateOnDate in Get-DkimSigningConfig to see where you are. Microsoft also notes there is no automatic rotation for the *.onmicrosoft.com domain.

Rotation on Google Workspace

On the Authenticate email page of the Admin console, generate a new record and choose 2048. Google's help page says that if your domain already uses a key with the google prefix, you should enter a different prefix. A new prefix (a date, for example) also gives you the overlap window the steps above describe. Google notes the console may keep showing a "You must update the DNS records" message for up to 48 hours after you have.

Rotation through an ESP

Most email platforms either host the key for you behind a CNAME and rotate it themselves, or don't rotate at all. Ask which. If the platform rotates through CNAMEs, you have nothing to do. If it gave you a TXT record to paste, nobody is rotating it.

What about Ed25519?

RFC 8463 added Ed25519 as a DKIM algorithm in 2018. Its keys are 256 bits and fit easily in one TXT string. We couldn't find current published statements from Gmail, Yahoo or Outlook.com confirming they verify Ed25519 signatures, so we wouldn't sign with Ed25519 alone. If your mail server supports it, add it as a second signature alongside RSA rather than instead of it.

The practical takeaway

Look up your selectors today. If any are 1024-bit, generate a 2048-bit key under a new selector, switch to it, and revoke the old one with an empty p= after a week. Put the next rotation in the calendar six months out. This won't change your inbox placement tomorrow, but it removes a weakness that is easy to find, because anyone can read your key from public DNS. Our deliverability audit checks DKIM alongside SPF and DMARC in one pass.