1024-bit vs 2048-bit DKIM keys

14 June 2026 · 12 min read

Why DKIM key length is a decision worth getting right

DKIM signs your outbound email with a private key, and publishes the matching public key in DNS so receivers can verify the signature. The maths behind that signature is RSA, and RSA security scales with key size. A 1024-bit key was the original default across most of the email industry, and for years it was good enough. It is no longer. A 2048-bit key is now the baseline that every serious mailbox provider, from Google to Microsoft to Yahoo, expects to see, and several have started flagging or distrusting shorter keys outright.

The catch is that a 2048-bit public key is roughly twice as long as a 1024-bit one, and it does not fit inside a single DNS TXT string. If you copy and paste it the way you would a 1024-bit key, your DNS provider will either reject it or silently truncate it, and your DKIM will fail verification on every message. That single mechanical problem, splitting a long key across DNS correctly, is where most 2048-bit migrations go wrong.

This guide explains the real security trade-offs between 1024-bit and 2048-bit keys, why the DNS limit exists and exactly what it is, how to publish a 2048-bit key correctly with chunked TXT strings, and how to verify that what you published actually works before it matters. If you would rather not touch any of this by hand, our done-for-you DKIM service generates, publishes and rotates 2048-bit keys for you, but you should understand the mechanics either way.

What the key length actually protects

DKIM uses asymmetric cryptography. There is a private key that lives on your sending infrastructure (or your provider's), and a public key published in DNS at a selector record like selector1._domainkey.example.com. When you send a message, the sending server hashes selected headers and the body, then signs that hash with the private key. The receiver pulls the public key from DNS and checks that the signature matches. If it does, the receiver knows two things: the message genuinely came from a system holding your private key, and the signed parts were not altered in transit.

The key length is the size of the RSA modulus, measured in bits. It governs how hard it is for an attacker to derive your private key from the public key, or to forge a signature without the private key. With 1024 bits, that work is now within reach of well-resourced attackers, and the trend only goes one way: factoring large numbers gets cheaper every year as hardware and algorithms improve. With 2048 bits the search space is astronomically larger, and there is no credible public path to breaking it with current or near-term technology.

The practical risk of a weak DKIM key is targeted forgery. If an attacker recovers your private key, they can sign mail as your domain that passes DKIM, passes DMARC alignment, and lands in inboxes looking completely legitimate. That is the worst-case email security failure: a fully authenticated phishing message wearing your brand. Key length is the lock on that door.

The case for 2048-bit, plainly

The reasons to use a 2048-bit key are short and decisive.

• It is the published recommendation. RFC 8301 sets 1024 bits as the minimum and recommends 2048 bits, and explicitly says signers should rotate up. The industry has moved.
• Major receivers expect it. Google's bulk-sender guidance calls for keys of at least 1024 bits and recommends 2048. Several providers treat sub-1024 keys as invalid, and some now downgrade trust on 1024-bit signatures over time.
• The cost is essentially zero. A 2048-bit signature takes marginally more CPU to generate and verify, but on modern hardware this is unmeasurable in real sending. There is no deliverability penalty for a longer key. There is a penalty for a key receivers consider weak.
• It future-proofs the record. Rotating a key is real work and a real risk window. Publishing 2048 bits now means you are not forced into an urgent migration when 1024-bit support is finally withdrawn.

The only genuine argument for 1024 bits was the DNS publishing problem, and that problem has a clean solution that we will walk through. So the answer is not nuanced: use 2048 bits for every selector. The interesting part is publishing it without breaking anything.

Why a 2048-bit key does not fit in one TXT string

DNS TXT records have a structural limit that trips people up because it is invisible until you hit it. A TXT record is made of one or more character strings, and each individual character string can be at most 255 bytes long. This is defined in the DNS standard itself (RFC 1035): the length of each string is stored in a single leading byte, and a single byte cannot count higher than 255.

A 1024-bit DKIM public key, base64-encoded and wrapped in the DKIM record format (v=DKIM1; k=rsa; p=...), comes in comfortably under 255 bytes, so it fits in one string and nobody notices the limit exists. A 2048-bit key's p= value is around 216 characters of base64 on its own, and once you add the v=, k= and surrounding syntax the whole record runs to roughly 400 to 420 bytes. That is well over 255. It physically cannot be a single character string.

This is not the same as the total record size. A single TXT record can hold multiple character strings, and the total can run to several hundred bytes (the practical ceiling before you risk truncation or TCP fallback is usually quoted around 512 bytes for a comfortable UDP response). The 255-byte limit is per string, not per record. So the fix is to split the long key into several strings inside one TXT record, each string under 255 bytes. This is called chunking or splitting.

Crucially, when a receiver reads a multi-string TXT record, the DKIM verifier (and DNS resolvers generally) concatenate the strings back together with no separator. There is no space, no comma, no newline inserted between chunks. So as long as you split at the right syntax and let your DNS provider store each chunk as its own quoted string, the reassembled value is byte-for-byte identical to the original key. Get the concatenation rules wrong, though, and you get a corrupted key and silent DKIM failure.

How chunking looks in practice

Say your generated 2048-bit record is this single logical value:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...lots more base64...QIDAQAB

To publish it, you break it into strings of up to 255 bytes and present each as a quoted string. In the canonical zone-file form that BIND-style DNS uses, the record looks like this:

selector1._domainkey  IN  TXT  ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAfirst-half-of-base64..."
  "...second-half-of-base64...QIDAQAB" )

Three quoted strings, wrapped in parentheses so the zone file treats them as one record. When resolved, they concatenate with no gaps into the exact original value. The split points are arbitrary as far as DNS is concerned: you can split in the middle of the base64 blob, because the verifier just glues the pieces back. What you must not do is introduce any character that was not in the original, including a stray space at a join.

Where this gets provider-specific is that almost nobody edits raw zone files any more. You are using a web dashboard, and each dashboard handles long TXT values differently. That is the source of most failures.

How each DNS provider wants you to enter it

The single most important rule: do not invent the chunking yourself unless the provider requires it. Many modern DNS UIs accept the full unquoted key in one box and split it into 255-byte strings for you behind the scenes. If you manually pre-split and the UI also splits, you double-split and corrupt the record.

Here is how the common providers behave.

• Cloudflare. Paste the entire record value, unquoted, into a single TXT content field. Cloudflare automatically segments anything over 255 bytes into valid chunks. Do not add quotes and do not pre-split.
• Route 53 (AWS). Route 53 requires you to add the quotes yourself. Enter the value as multiple quoted strings on separate lines in the value box, each string under 255 bytes, for example "v=DKIM1; k=rsa; " on one line and the "p=..." halves on the next lines. Route 53 stores them as a multi-string TXT record.
• Google Cloud DNS. Accepts the full value; for very long values you provide multiple segments, each enclosed in quotes, and it concatenates them.
• GoDaddy, Namecheap, and many registrar-bundled DNS panels. These are the riskiest. Some silently truncate at 255 characters, some strip quotes, some reject the entry. Where a panel truncates, you must split the value into separate quoted strings yourself, and if even that fails, the practical workaround is to host DNS somewhere that handles long TXT properly.
• Microsoft 365 / Outlook DKIM. Microsoft does not have you publish the key at all in the normal flow: you publish two CNAME records pointing at Microsoft-hosted selectors, and Microsoft holds the 2048-bit key on their side. The chunking problem disappears because you are never pasting a key.

The reliable workflow regardless of provider is: generate the key, read your provider's TXT documentation for whether it auto-chunks or needs manual quoting, enter it the matching way, then verify the published result rather than trusting the form.

Generating a correct 2048-bit key

If your sending platform generates DKIM for you (Google Workspace, a transactional provider, a marketing platform), let it: it will hand you the public-key record to publish, already sized at 2048 bits in most modern setups. Check the offered size and pick 2048 if there is a choice.

If you are generating your own, you can produce a 2048-bit RSA keypair with OpenSSL:

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -outform der 2>/dev/null | openssl base64 -A

The first line creates the private key your mail server will use to sign. The second extracts the public key, in the DER form DKIM expects, and base64-encodes it as a single line. That base64 blob is what goes after p= in your DNS record. Keep dkim-private.pem secret and access-controlled: it is the secret half of the whole scheme, and a leaked private key means anyone can sign as your domain until you rotate.

Prefer not to handle OpenSSL or the chunking at all? Our DKIM generator produces a correct 2048-bit record and shows you exactly how to publish it for your provider, and the DNS record splitter takes any long value and chunks it into valid 255-byte strings you can paste directly.

Verifying the published key actually works

Publishing is only half the job. A record that looks right in the dashboard can still be broken by truncation, an inserted space at a chunk boundary, or a provider that re-encoded your quotes. Always verify the live DNS before you rely on it.

The fastest manual check is a DNS query for the selector record:

dig +short TXT selector1._domainkey.example.com

What you want to see is the full record reassembled into one logical value, ending in the same trailing base64 (commonly ...QIDAQAB for a 2048-bit key) that you generated. dig shows multi-string records as separate quoted pieces; mentally concatenate them and confirm there is no gap, no missing tail, and no stray character at the joins. If the p= value is cut short, the provider truncated it. If it is empty (p=), the key was revoked or never stored.

Two failure signatures to recognise:

• Truncated key. The record exists but the base64 stops partway and does not end in the expected tail. Receivers will fail the signature. This is the classic 255-byte truncation: the provider stored only the first string.
• Wrong concatenation. The record contains the full key but a space or other character crept in at a chunk boundary, so the reassembled base64 is invalid and the key will not parse. Decode test it, or just let a checker do it.

Rather than eyeball base64, run the live record through our DKIM checker. It fetches the selector, reassembles the chunks the way a real verifier does, confirms the key parses, and tells you the key size it found. Seeing it report 2048-bit, valid is the confirmation that your chunking was correct end to end. Then send a test message to a mailbox you control and inspect the Authentication-Results header: a dkim=pass with your domain in header.d proves the whole path works, not just DNS.

Key length is one factor in a healthy DKIM setup

Getting to a valid 2048-bit key is the headline task, but a few neighbouring decisions matter for the whole thing to keep working.

• Selectors. Each DKIM key lives under a selector name, which lets you run multiple keys at once (for different services, or for rotation). Use distinct, descriptive selectors per sending source so you can manage them independently.
• Rotation. Even a strong key should be rotated periodically, and rotation is exactly where the chunking discipline pays off, because you publish a fresh 2048-bit record alongside the old one before switching signing over. The mechanics and a safe cadence are covered in DKIM key rotation.
• Alignment with DMARC. DKIM only helps your DMARC posture if the signing domain (d=) aligns with the From: domain. A perfect 2048-bit signature on the wrong domain does nothing for DMARC. If you are working towards enforcement, see how the pieces fit in DMARC alignment explained.
• The other records. DKIM is one of three authentication layers. Pair it with a correct SPF record and a DMARC policy. The starting points are what is SPF and what is DMARC, and you can check all of them from the free tools hub.

Common mistakes that break 2048-bit DKIM

A short field guide to the failures we see most, so you can avoid them.

• Pre-splitting on a provider that auto-chunks. You quote and split, the provider splits again, the key corrupts. On auto-chunking providers like Cloudflare, paste the whole unquoted value and leave it alone.
• Not splitting on a provider that truncates. The mirror image: you paste the full value, the panel silently keeps only the first 255 bytes, and DKIM fails. Verify the live record to catch this.
• A space at the join. When manually quoting, people add a trailing space inside a string to "be safe". DNS concatenates strings with no separator, so that space becomes part of the base64 and breaks the key. Split cleanly with no padding.
• Forgetting the v=DKIM1; k=rsa; prefix. Some flows give you only the p= blob. The record needs the version and key-type tags too, or strict verifiers may reject it.
• Leaving the old 1024-bit selector live and assuming you upgraded. Publishing a new selector does not retire the old one. Make sure your signing config actually points at the 2048-bit selector, and confirm with the Authentication-Results header.
• Trusting the dashboard over DNS. The form showing a tidy value is not proof. Only a live query, or a checker that performs one, tells you what receivers will actually fetch.

The practical takeaway

There is no real trade-off to agonise over: publish a 2048-bit DKIM key for every selector, on every domain, every time. The security gain over 1024 bits is large and the cost is negligible. The only thing 1024-bit ever had going for it was that it fitted in a single DNS string, and that convenience is not worth a weak signature.

The work that remains is mechanical and entirely solvable: split the longer key into valid sub-255-byte strings the way your DNS provider expects (auto-chunked on some, manually quoted on others), then verify the reassembled live record actually parses as a 2048-bit key before you trust it. Generate and split cleanly with the DKIM generator and DNS record splitter, confirm the result with the DKIM checker, and you are done.

If you would rather skip the OpenSSL, the chunking quirks and the rotation calendar entirely, our hosted DKIM service generates, publishes and rotates correct 2048-bit keys for you and keeps an eye on them, so a truncated record or an expired selector never quietly takes your email down.