DKIM Key Length: 1024 vs 2048 Bits, and What to Publish

The DKIM 1024 vs 2048 key length question comes down to one trade-off: a 2048-bit key is cryptographically stronger, while a 1024-bit key is smaller and easier to publish in DNS. For almost every sender today, 2048 bits is the right answer — it is what Amazon SES creates by default and what Google recommends.

The reason 1024-bit keys are still everywhere is not security. It is that a 2048-bit public key is long enough to run past a DNS record limit that used to trip people up. This guide covers what each length actually buys you, why the DNS constraint existed, how the major providers handle 2048-bit keys now, and how to move up cleanly.

The verdict: publish a 2048-bit key#

Use a 2048-bit RSA DKIM key. It roughly doubles the effort an attacker needs to forge your signature, most managed providers now default to it, and the one historical reason to avoid it — publishing a longer key in DNS — is a solved problem.

Keep a 1024-bit key only in two cases: your DNS host genuinely cannot store a value longer than 255 characters and offers no workaround, or you are mid-migration and need a working signature while you roll the new key. Both are temporary. A 1024-bit key still meets Gmail's minimum, so mail keeps flowing either way — this is a security and future-proofing choice, not an all-or-nothing deliverability one.

1024 vs 2048 at a glance#

Both lengths produce a valid DKIM signature that Gmail, Outlook and other major receivers accept. They differ on strength, on how they publish in DNS, and on what your provider generates by default.

Why 1024-bit keys became so common#

For years, 1024-bit DKIM keys were the practical default, and the reason was DNS, not cryptography. A DKIM public key is published as a DNS TXT record, and a single TXT string can hold at most 255 characters. A 1024-bit RSA public key, base64-encoded and wrapped with the v=DKIM1; k=rsa; p= prefix, comes to roughly 230 characters — comfortably inside one string.

That made 1024-bit keys trivial to publish: paste one value into one field, done. A 2048-bit key does not fit. It runs to about 400 characters, past the 255-character limit, so it has to be entered as more than one string. Plenty of DNS control panels handled that badly, and some registrars capped a single value field at 255 characters and rejected anything longer.

There was also an older worry about packet size. RFC 6376 notes that larger keys may not fit inside a standard DNS UDP response, which historically meant falling back to EDNS0 or TCP — something a few old resolvers and middleboxes mishandled. In 2026 that is rarely a problem: EDNS0 is standard and every major DNS host supports long TXT records. The 255-character string limit is the only constraint you still work around, and it has a clean answer.

Where 2048-bit keys win#

The case for 2048 bits is straightforward. A longer RSA key is far harder to factor, so it holds up much better against an attacker trying to forge signatures for your domain or recover your private key. For a signature you expect to leave in place for months or years, that headroom matters.

The ecosystem has also moved. Amazon SES creates 2048-bit keys by default, Google recommends 2048 in its sender guidelines, and the tooling to publish a split record is built into most DNS hosts now. Choosing 1024 today means choosing the weaker option to dodge a problem that is already solved.

• Stronger against forgery and key-recovery attacks than a 1024-bit key of the same age.
• Matches what Amazon SES and other managed senders now generate by default.
• Aligns with Google's published recommendation for sending to Gmail.
• Future-proof: if a receiver ever raises its minimum above 1024 bits, you are already above it.

How a 2048-bit key splits a DNS TXT record#

A DNS TXT record is not one continuous blob of text. Its data is made of one or more character-strings, and each string can be at most 255 bytes — a limit set by the DNS wire format, not by any single provider. A record can hold several strings back to back, and a resolver joins them together with no separator when it answers a query.

That is exactly how a 2048-bit key gets published. You split the roughly 400-character key value into two quoted strings inside the same TXT record. The DNS server serves both, the receiving mail server concatenates them, and it reads one continuous public key. Many DNS dashboards do the split for you when you paste a long value; others make you add the quotes yourself.

The rule to get right: split anywhere in the base64, but add no spaces, line breaks or extra characters between the pieces. The two strings are joined character-for-character. A stray space or a missing chunk changes the key, and the signature quietly fails to verify.

What each provider defaults to — and how to check#

Managed senders differ on what they generate out of the box, so the honest answer to 'what should I use' partly depends on who signs your mail. The table below reflects each provider's own documentation as of August 2026. Defaults change, so confirm the current behaviour on the vendor's own page before you rely on it.

How to upgrade an existing key to 2048#

Upgrading is a key rotation, not a flip of a switch: you publish a new 2048-bit key, let receivers pick it up, then retire the old one. Never delete the old key the moment you add the new one — mail already in transit was signed with it. The exact clicks differ by provider and consoles change, so verify each on the vendor's current page.

1. 1

   Google Workspace

   In the Admin console, go to Apps, Google Workspace, Gmail, then Authenticate email. Generate a new DKIM record and choose the 2048-bit length. Add the new TXT record at the selector in your DNS, wait for it to resolve, then click Start authentication.

2. 2

   Microsoft 365

   In Exchange Online PowerShell, run Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048. Microsoft signs through CNAMEs you already delegated, so there is usually no DNS edit. Note that the first rotation updates only the next active selector; run the rotation again later so both selectors reach 2048.

3. 3

   Amazon SES

   New identities are already 2048-bit. For an existing identity, change the DKIM signing key length in the SES console or API, then publish the updated CNAMEs. SES rate-limits key-length changes — not to the same length, and generally no more than once per 24 hours — so plan the switch rather than toggling it.

4. 4

   Verify before you retire the old key

   Query the new selector and confirm the full public key resolves, then send a test message to a mailbox that shows authentication results and check for dkim=pass signed with the new selector. Only once the new key verifies should you let the old selector expire.

Who each key length is genuinely for#

For most senders this is not a close call, but the edge cases are real. Pick by your DNS host and how long the key will live.

• Choose 2048-bit if you are setting up DKIM now, you run your domain on a modern DNS host, or the key will stay in place for months. This is almost everyone.
• Keep 1024-bit if your DNS provider cannot store a value over 255 characters and offers no split-string workaround — a genuine but shrinking set of hosts.
• Use 1024-bit temporarily if you need a valid signature immediately while you sort out publishing the longer 2048-bit record. Treat it as a bridge, not a destination.
• Go below 1024 bits: never. Keys under 1024 bits fail the standard's floor for long-lived keys and are rejected or ignored by major receivers, Gmail included.

A third option: Ed25519 keys#

RSA is not the only signing algorithm DKIM allows. RFC 8463 adds Ed25519-SHA256, published with k=ed25519. Its public keys are tiny — 256 bits, only about 44 characters in base64 — so an Ed25519 key drops into a single DNS TXT string with room to spare while offering strong security in far less space than RSA.

The catch is support. Not every receiver verifies Ed25519 signatures yet, so it is not a drop-in replacement for RSA. RFC 8463 plans for this: a sender can publish both an RSA and an Ed25519 signature, using a different selector for each, so a receiver that understands Ed25519 uses it and everyone else falls back to the RSA signature. If your provider supports it, adding Ed25519 alongside a 2048-bit RSA key is a reasonable step. For most people, a well-published 2048-bit RSA key remains the practical answer.

Where AI Emaily fits — and where it doesn't#

Choosing and publishing a DKIM key is a job for whoever sends your mail — your email provider, your ESP, or your DNS host. AI Emaily is a mail client, not an ESP, a DNS host, or a deliverability tester. It does not generate your DKIM key, choose its length, or sign your outbound mail; your provider does that, and this decision sits entirely on their side. If publishing the record is your task, use the provider steps above.

Where we do the adjacent work is on the mail arriving in your inbox. DKIM is how a receiving server checks that a message really came from the domain it claims, and AI Emaily reads those same DKIM and alignment results on your inbound mail — so its spam and phishing protection can flag a spoofed sender whose signature failed or did not align with the visible From address. Connecting a Gmail, Outlook or IMAP mailbox needs no new DNS records, because your outbound keeps flowing through your provider's authenticated servers. We build AI Emaily, and it comes with a 7-day free trial on the Pro and Autopilot plans.