DKIM Key Length: How to Choose 1024 vs 2048 vs 4096

Upgrading your DKIM key should strengthen email security. In practice, it often leads to authentication failures caused by incorrect DNS configuration.

Many organizations still run 1024-bit DKIM keys without realizing it. Others move to 2048-bit to meet modern security recommendations, only to discover that larger keys create new publishing requirements. A single mistake when adding the public key to DNS can cause DKIM verification to fail, even while email continues to send normally.

The challenge is choosing the right key length, publishing it correctly, and maintaining it over time without disrupting email authentication.

This guide explains how DKIM key length affects security, deliverability, and compliance in 2026. You’ll learn the differences between 1024-bit, 2048-bit, 4096-bit, and Ed25519 keys, how to check your current deployment, avoid common DNS publishing errors, and rotate keys safely.

What Is DKIM Key Length?

DKIM key length is the size, in bits, of the RSA key pair that signs and verifies email under the DKIM standard (RFC 6376). The private key signs each outgoing message at the mail server, and the matching public key sits in a DNS TXT record so receiving servers can confirm the signature. 

Longer keys are harder to break. A 2048-bit key resists forgery far better than a 1024-bit one. However, key length is a trade-off, affecting cryptographic strength, DNS record size, and compatibility with receivers all at once. 

The public key is published under a selector, the label (such as selector1._domainkey.example.com) that tells a receiver which key to use, since one domain can run several keys at the same time. 

DKIM Key Length Options Compared

Not all DKIM keys are equal. Some are outdated, some are the current standard, and some solve one problem while creating another. Here’s how 1024-bit, 2048-bit, 4096-bit, and Ed25519 compare in practice.

1024-bit RSA

1024-bit RSA was the original DKIM standard, and it is now the weakest option still permitted. The standards have moved past it. RFC 8301 (2018) sets 1024 bits as the minimum acceptable key size but recommends at least 2048 bits for signing. It also requires verifiers to treat keys below 1024 bits as invalid. 

NIST SP 800-131A Rev. 2 goes further, disallowing RSA keys below 2048 bits for generating digital signatures and classifying 1024-bit RSA as legacy-use cryptography. Google’s sender guidelines still accept 1024-bit DKIM keys as a minimum requirement for Gmail delivery, but recommend 2048-bit keys for stronger security.

Despite all the recommendations, 1024-bit keys remain common. Many hosting panels and older mail platforms still generate them by default, leaving organizations on 1024-bit RSA without realizing it.

A 1024-bit RSA key is weaker than current cryptographic recommendations, which is why standards bodies and mailbox providers have moved toward 2048-bit deployments. However, organizations still running 1024-bit DKIM are generally better served by planning and validating a controlled migration than by making rushed changes that introduce authentication failures. 

2048-bit RSA

2048-bit RSA is the current DKIM standard. RFC 8301 recommends RSA keys of at least 2048 bits for signing, NIST SP 800-131A Rev. 2 classifies RSA keys of 2048 bits or more as acceptable for generating digital signatures, and Google’s sender guidelines recommend 2048-bit keys for security. A 2048-bit key meets current industry, provider, and compliance requirements.

Most DKIM failures involving 2048-bit keys are not cryptographic failures. They are DNS publishing failures. A 2048-bit public key is roughly 392 base64 characters long, while a single DNS TXT string is limited to 255 bytes. The key cannot be published as a single string. It must be split into multiple quoted strings within the same TXT record, which DNS automatically reassembles during lookup.

If the key is published incorrectly, DKIM verification fails even though the record appears to exist and the mail server continues signing messages normally. 

4096-bit RSA

4096-bit RSA is the largest key length most receivers will verify. RFC 8301 requires verifiers to validate keys from 1024 to 4096 bits and only optionally beyond that, so a key larger than 4096 risks not being verified at all. PowerDMARC Hosted DKIM supports key lengths up to 4096-bit.

For most organizations, 4096-bit is unnecessary. It offers no meaningful security gain over 2048-bit, which already meets the NIST SP 800-131A Rev. 2 minimum and Google’s sender guidelines, while producing a larger DNS record and adding a small amount of overhead during signature verification.

Use 4096-bit only in high-security or heavily regulated environments where an internal policy or an auditor specifically calls for it.

Ed25519 (Future Direction)

Ed25519 is a DKIM signing algorithm standardized by RFC 8463 (2018). Its biggest advantage is key size. An Ed25519 public key encodes to a 44-octet base64 string, allowing the entire DNS key record to fit within a single TXT string. Unlike RSA-2048 and RSA-4096, it does not require DNS record chunking and works with systems that cannot publish multi-string TXT records. RFC 8463 also describes Ed25519 as providing strong cryptographic security with significantly shorter keys than RSA.

The challenge is adoption. RFC 8463 requires verifiers to support Ed25519-SHA256, but only recommends support for signing with it. In practice, support across mail platforms, MTAs, and email providers remains inconsistent. An Ed25519-only deployment can result in DKIM verification gaps at receivers that do not support the algorithm.

For that reason, Ed25519 is best deployed alongside RSA-2048. RFC 8463 explicitly supports dual-signing, allowing a message to carry both an RSA-SHA256 and an Ed25519-SHA256 signature. Since a selector can publish only one public key, each signature must use a different selector, while sharing the same signing domain. Receivers verify the signature they support, providing compatibility while allowing organizations to adopt Ed25519.

How to Check Your Current DKIM Key Length

Before planning a DKIM key upgrade, verify the key size currently published in DNS.

1. Identify your DKIM selector

Open the headers of a signed email and locate the DKIM-Signature field. The value of the s= tag is your selector. You can also find the selector in your email provider’s DKIM configuration settings.

2. Look up the DKIM record

Query selector._domainkey.yourdomain.com using a DKIM lookup tool or DNS query tool to retrieve the published TXT record.

3. Review the public key

Locate the p= tag in the record. This contains the DKIM public key. Most DKIM lookup tools will automatically identify the key length and report whether it is 1024-bit, 2048-bit, or another size.

4. Evaluate the result

If the domain is still using a 1024-bit key, plan a migration to 2048-bit RSA. If a 2048-bit key is already deployed and functioning correctly, no immediate action is typically required.

The PowerDMARC DKIM Checker fetches your published record and auto-detects the selector for major providers, so you can confirm your key length in seconds instead of decoding base64 by hand. Try it for free 

The 2048-bit DNS Chunking Problem (And How to Avoid It)

One of the most common causes of DKIM failures after a 2048-bit key upgrade is incorrect DNS record publishing.

The issue stems from DNS TXT record limitations. A single TXT string can contain a maximum of 255 bytes, while a 2048-bit RSA public key encoded in base64 is typically around 392 characters long. As a result, the key cannot be published as a single string. If a DNS provider truncates the record or rejects the entry, DKIM verification fails.

To publish a 2048-bit key correctly, split the public key across multiple quoted strings within the same TXT record. DNS automatically concatenates the strings during lookup.

selector1._domainkey.example.com.  IN  TXT  (

  “v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1xN8s9k2”

  “Qp7Yv3RwL0fHmZ2bKct5oXn8eW4uV1aA9dGqB6sT0pJrN3mC2hF7lYxoZ4kP1wIDAQAB”

)

Support for long TXT records varies by DNS provider. Some platforms require administrators to enter multiple quoted strings manually, while others automatically split and reassemble long values. Always review your provider’s DNS record formatting requirements before publishing a DKIM key.

Keep the following points in mind:

After publishing a new DKIM key, validate the DNS record and confirm that receiving servers can retrieve the complete public key without errors.

When and How to Rotate DKIM Keys

DKIM key rotation reduces the risk associated with long-term key exposure and is a common requirement in security and compliance programs. While there is no universal rotation schedule defined by the DKIM standard, many organizations rotate signing keys every 6 to 12 months as part of routine security maintenance.

A safe DKIM rotation process involves introducing a new selector before retiring the existing one. This ensures continuous DKIM validation throughout the transition.

1. Step 1: Generate a new DKIM key pair and assign it a new selector. Many organizations use date-based selector names to simplify tracking and auditing. 
2. Step 2: Publish the new public key in DNS under the new selector. If using a 2048-bit RSA key, ensure the DNS record is published correctly. 
3. Step 3: Wait for DNS propagation based on the record’s TTL. 
4. Step 4: Update the mail server or email service provider to sign messages with the new selector. 
5. Step 5: Keep the previous selector active until messages signed with the old key have cleared normal delivery paths and DNS caches have expired. 
6. Step 6: Remove the old selector and its associated DNS record once it is no longer in use. 

This approach allows both selectors to coexist during the transition, preventing DKIM verification failures caused by DNS propagation delays or cached records.

Organizations managing multiple domains, selectors, or email services may find manual rotation difficult to maintain consistently.

DKIM Key Length Requirements by Platform and Compliance Framework

DKIM key length requirements vary across email providers, security standards, and compliance frameworks. While some frameworks define explicit cryptographic requirements, others align with broader industry guidance and best practices.

Compliance and Provider Requirements

Platform Support and Defaults

Across major mailbox providers, security frameworks, and enterprise environments, 2048-bit RSA remains the recommended DKIM key length. It satisfies current security guidance, broad compatibility requirements, and compliance expectations while avoiding the deployment challenges associated with larger RSA keys.

How to Generate a 2048-bit DKIM Key

Generating a 2048-bit DKIM key pair can be done using a DKIM key generation tool or directly from the command line.

Method 1: Use a DKIM Key Generator

The PowerDMARC DKIM Generator creates a 2048-bit DKIM key pair and provides the public key in a DNS-ready format along with the corresponding private key for your mail server or email platform.

Method 2: Generate a Key Pair with OpenSSL

# Generate a 2048-bit private key

openssl genrsa -out dkim_private.key 2048

# Extract the matching public key

openssl rsa -in dkim_private.key -pubout -out dkim_public.key

After generating the key pair, follow these best practices:

After the key is published and DNS propagation is complete, update your mail platform to begin signing messages with the new selector.

Managing DKIM Key Length Correctly in 2026 

A correctly generated, published, and maintained 2048-bit key provides stronger protection against forgery without creating deliverability issues. An incorrectly published key, however, can break DKIM verification regardless of its cryptographic strength.

Before making any changes, verify your current DKIM deployment. If you’re still using a 1024-bit key, plan a controlled migration to 2048-bit RSA. If you’re already on 2048-bit, validate your DNS record configuration, establish a key rotation process, and monitor your authentication results regularly.

Strong email authentication depends on more than choosing the right key length. It depends on managing the entire DKIM lifecycle correctly, from key generation and DNS publishing to rotation and ongoing validation.

FAQs

Does Google require 2048-bit DKIM in 2026?

Google’s bulk sender rules accept 1024-bit as a minimum but strongly recommend 2048-bit. Because NIST disallows 1024-bit RSA for generating digital signatures, 2048-bit is the practical standard regardless of Google’s limitation.

What happens if I use a 1024-bit DKIM key?

Your mail will still authenticate at receivers that accept 1024-bit, including Gmail. But it falls below NIST’s 2048-bit minimum, may fail compliance audits, and is breakable by well-resourced attackers. 

How do I split a 2048-bit DKIM key in DNS?

A 2048-bit public key (~392 characters) exceeds the 255-byte TXT string limit, so you split it into quoted strings inside the same TXT record. DNS concatenates them automatically. Validate with a DKIM lookup tool after publishing.

Is Ed25519 DKIM supported by Gmail and Outlook?

Support is improving but inconsistent across receivers and ESPs as of 2026. Don’t sign with Ed25519 alone. Dual-sign with RSA-2048 plus Ed25519 so receivers that don’t support Ed25519 fall back to RSA.

How often should DKIM keys be rotated?

Every 6 to 12 months is the widely cited best practice. Use a parallel-selector method so an old key stays valid until the new one propagates, keeping mail signed throughout the swap

• About
• Latest Posts

Milena Baghdasaryan

Content Specialist at PowerDMARC

Milena is a skilled writer and content creator with 7+ years of experience in crafting engaging content on IT, cybersecurity, virtual events, and more. She has a proven track record of delivering high-quality work for international magazines and is a graduate of prestigious institutions such as New York University Abu Dhabi, UWC China, and the College of Europe.

Latest posts by Milena Baghdasaryan (see all)

• DKIM Key Length: How to Choose 1024 vs 2048 vs 4096 - July 9, 2026
• What Is ClickFix (and FileFix)? - July 8, 2026
• How to Choose an Email Service Provider: A Security-First Evaluation Framework - July 1, 2026