2048-bit DKIM: Do You Need It for Email Delivery?

The short answer: use 2048-bit DKIM when you can

Do you need 2048-bit DKIM? For a new domain, new selector, or provider migration, the practical answer is yes: choose a 2048-bit RSA DKIM key if your sending platform and DNS provider support it.

That does not mean every 1024-bit DKIM key is broken, rejected, or urgently unsafe. A correctly configured 1024-bit key can still validate successfully, can still support DMARC alignment, and is not prohibited by the major mailbox-provider sender requirements. The more useful distinction is between acceptable today and the better default for a new configuration.

RFC 8301 requires DKIM signers using RSA to use keys of at least 1024 bits and says signers should use keys of at least 2048 bits. It also requires verifiers to be able to validate RSA keys from 1024 through 2048 bits. In other words, 1024-bit RSA is the protocol floor; 2048-bit RSA is the preferred operational baseline. (datatracker.ietf.org)

If you are deciding whether to interrupt healthy sending solely to replace a 1024-bit key, usually do not make that change as an emergency. First confirm that DKIM passes for the actual mail stream, that its signing domain aligns with the visible From domain for DMARC, and that every application or provider using the domain is accounted for. A rushed rotation that leaves one system unsigned is worse than a stable, validated 1024-bit configuration.

What DKIM key length actually changes

DKIM, short for DomainKeys Identified Mail, allows a sending system to apply a cryptographic signature to a message. The receiving system retrieves the public key from DNS and verifies that the selected headers and body content match the signature.

A DKIM signature is visible in the message headers and commonly includes fields such as these:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=s2025; t=1735689600;
 h=from:to:subject:date:mime-version:content-type;
 bh=base64-body-hash;
 b=base64-signature

The important fields for troubleshooting are:

• a=: The signing algorithm. rsa-sha256 is the usual RSA DKIM algorithm.
• d=: The signing domain, such as example.com.
• s=: The selector, such as s2025.
• h=: The headers covered by the signature.
• bh=: A hash of the signed body content.
• b=: The signature value itself.

The receiver looks up the key at this DNS name:

<selector>._domainkey.<d-domain>

For the example above, that lookup is:

s2025._domainkey.example.com

The private key stays with the system that signs mail. The public key is published in DNS. Key length refers to the RSA key pair used in that process, not the size of the DKIM-Signature header, the size of your email, or the strength of your SMTP password.

A 2048-bit RSA key provides a larger security margin than a 1024-bit RSA key. The tradeoff is operational rather than conceptual: its public key is longer, which can complicate DNS publication in systems with poor support for long TXT records.

DKIM is not a general-purpose encryption system. It does not hide message content, protect mail at rest, or prove that a human recipient wanted the email. It creates a verifiable domain-level assertion that the signing domain took responsibility for the message and that signed portions were not changed after signing. (datatracker.ietf.org)

1024-bit versus 2048-bit DKIM

Why 2048-bit is the recommended default

For new selectors, 2048-bit RSA is generally the sensible choice for four reasons.

First, it follows the stronger recommendation in the current DKIM cryptographic guidance. Second, it avoids creating a technical-debt task that your team will need to schedule later. Third, it is widely supported by modern DNS providers and email platforms. Finally, it makes security reviews simpler: a 2048-bit key is the answer most security teams expect when they ask about DKIM key strength.

The improvement is about cryptographic resilience, not a magical inbox-placement boost. Changing a valid 1024-bit key to a valid 2048-bit key does not, by itself, move messages from spam to the inbox. Mailbox providers assess many signals, including authentication, domain reputation, recipient engagement, complaint rates, sending consistency, content, and list quality.

When 1024-bit is still acceptable

A 1024-bit key remains reasonable as a temporary or provider-constrained choice when all of the following are true:

1. The key is currently validating as dkim=pass on real messages.
2. The DKIM d= domain aligns with the visible From domain where DMARC alignment is needed.
3. Your provider or DNS host cannot reliably publish a 2048-bit key yet.
4. You have a documented plan to move to 2048-bit when the limitation is removed.
5. You are not using the key length question as a substitute for fixing a larger authentication issue.

For example, an application may send password reset messages through a legacy relay that exposes only a 1024-bit signing option. Replacing that relay during an incident could create delivery failures for security-critical mail. In that case, keep the validated key in place, document the exception, and plan a controlled migration rather than disabling or destabilizing signing.

What major sender rules actually require

The important requirement is normally DKIM authentication, not a specific 2048-bit key length. Google’s published requirements state that all senders to personal Gmail accounts need SPF or DKIM, while senders that send more than 5,000 messages per day to Gmail accounts need SPF, DKIM, and DMARC. Google’s public guidance does not set a separate 2048-bit DKIM key-length mandate in those requirements. (support.google.com)

That means a passing, aligned 1024-bit DKIM signature can satisfy the DKIM portion of a sender-authentication requirement. It does not mean that key length is irrelevant forever. It means you should prioritize the operational requirements in the order that affects real delivery:

1. Make sure every legitimate sender authenticates.
2. Make sure DKIM passes on sent mail.
3. Make sure SPF and DKIM are aligned appropriately for DMARC.
4. Publish and monitor DMARC.
5. Improve key length and rotate selectors without risking coverage.

The DNS record for a 2048-bit DKIM key

A self-managed RSA DKIM public key is normally published as a DNS TXT record. Its exact public-key value must come from the system that generated the matching private key. Do not copy the abbreviated example below into production; it is only a syntax model.

s2025._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvExamplePublicKeyOnly...IDAQAB"

The meaningful pieces are:

Do not add a trailing period to a TXT value. Do not include PEM wrapper lines such as -----BEGIN PUBLIC KEY-----. Do not insert spaces or line breaks inside the public-key material unless your DNS provider specifically uses quoted-string splitting to represent one continuous value.

Why long TXT records cause trouble

DNS TXT data is stored as one or more character strings, and each individual string is limited to 255 octets. A 2048-bit RSA DKIM public key often exceeds the practical length of one string once the v=DKIM1; k=rsa; p= prefix is included. DNS software represents a longer TXT value as adjacent quoted strings, which resolvers concatenate. (datatracker.ietf.org)

A correctly split zone-file style record looks like this:

s2025._domainkey.example.com. 3600 IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvFirstPart"
  "SecondPartOfTheSamePublicKeyWithoutAnInsertedSpaceOrSemicolonIDAQAB"
)

The two quoted strings are not two DKIM records and not two separate keys. They are parts of one TXT record. DNS resolvers concatenate them before a receiver interprets the DKIM key.

In a DNS dashboard, the UI may ask for the complete value as one input and split it automatically. Another dashboard may require you to paste the quoted chunks exactly as provided. A third may reject quotation marks because it adds them itself. Follow your DNS provider’s input rules, but validate the final published result with a DNS lookup rather than assuming the dashboard saved what you intended.

TXT versus CNAME records

Many email platforms ask you to create a TXT record containing the public key. Some hosted systems instead give you a CNAME record under your selector, delegating the public-key record to their DNS infrastructure.

A generic CNAME pattern can look like this:

s2025._domainkey.example.com. 3600 IN CNAME s2025.example.provider-dkim.net.

Do not infer the right CNAME target from this example. Publish the exact hostname your provider supplies. A CNAME-based configuration can make key rotation easier for the provider, but it still needs to resolve to a valid DKIM public key and the message still needs to be signed with the expected selector and domain.

Microsoft 365, for example, documents CNAME-based DKIM records for custom domains, while other systems commonly publish public keys directly through TXT records. That difference is an implementation detail, not a difference in what recipients verify. (learn.microsoft.com)

DKIM key length does not equal DMARC alignment

A common mistake is to see dkim=pass and conclude that DMARC must also pass. DKIM verification and DMARC alignment are related, but they are not identical.

Consider this message:

From: Billing <billing@example.com>
DKIM-Signature: d=mailer.vendor.example; s=prod; a=rsa-sha256; ...
Authentication-Results: mx.google.com;
       dkim=pass header.d=mailer.vendor.example

The signature may be cryptographically valid. However, if your DMARC policy is for example.com, the DKIM domain mailer.vendor.example may not align with example.com depending on the organizational-domain relationship and the configured alignment mode. A signature from an unrelated provider domain almost certainly will not align.

For a cleaner setup, a transactional sender commonly signs with your domain or a subdomain you control, such as:

From: Acme <receipts@example.com>
DKIM-Signature: d=example.com; s=tx2025; ...

Or:

From: Acme <receipts@mail.example.com>
DKIM-Signature: d=mail.example.com; s=tx2025; ...

The second pattern can be useful for separating transactional traffic from marketing traffic, but it adds DNS and DMARC-management responsibilities. Use subdomains deliberately rather than creating them only because a provider suggested one.

A 2048-bit unaligned signature does not repair DMARC. Conversely, an aligned 1024-bit signature can still enable a DMARC pass if it verifies successfully and satisfies the domain’s alignment policy. This is why changing key length should never be the first response to a DMARC failure.

When you should upgrade to 2048-bit DKIM

Treat the following situations as strong reasons to choose or migrate to 2048-bit DKIM:

• You are setting up a sending domain for the first time.
• You are creating a new DKIM selector during routine rotation.
• You are moving email infrastructure or replacing an old relay.
• Your DNS provider now supports long TXT records correctly.
• A security review, customer questionnaire, or compliance process requires a stronger modern baseline.
• Your provider can offer 2048-bit domain signing with no loss of coverage.

The best time to make the change is during a normal rotation, not after a delivery outage. DKIM supports multiple selectors, so you can publish a new selector before using it for outbound signing. Messages signed with the old selector continue to validate as long as the old public key remains in DNS.

A safe rotation sequence

Use this sequence whether you send through an SMTP relay, a REST email API, an on-premises MTA, or a combination of systems.

1. Inventory all senders. Include application mail, support platforms, invoices, CI notifications, CRM mail, marketing systems, and employee mail if the same domain is used.
2. Inspect actual message headers. Record each active d= and s= combination. Do not rely only on DNS records because unused selectors can remain published for years.
3. Generate or request a new 2048-bit selector. Use a descriptive selector such as tx2025, app1, or a date-based convention your team can maintain.
4. Publish the new DNS record. Confirm that public resolvers return exactly the intended TXT record or CNAME chain.
5. Enable signing with the new selector. Make this change in the sending platform, MTA, or provider configuration.
6. Send controlled test mail. Test Gmail, Outlook, and other important receiving environments if possible.
7. Confirm dkim=pass and DMARC results. Verify the selector, signing domain, and alignment, not merely the existence of a signature header.
8. Monitor production. Watch bounces, delivery events, authentication results, and DMARC aggregate reports.
9. Retire the old selector later. Leave the old public key available long enough to accommodate delayed mail, queued retries, and messages that recipients may verify after delivery.

The exact overlap period depends on your retry behavior and operational risk tolerance. The key idea is that DNS publication must precede signing, and old public keys should not be removed at the same moment you change signing behavior.

How to verify that your DKIM record and signatures work

Verification has two distinct parts: DNS correctness and message correctness. Passing only one is not enough.

Check DNS directly

On macOS, Linux, or Windows with appropriate DNS tools installed, query the exact selector name:

dig +short TXT s2025._domainkey.example.com

You can also use:

nslookup -type=TXT s2025._domainkey.example.com

A 2048-bit record may appear as multiple quoted strings in the response. That is normal. What matters is that the result contains one complete v=DKIM1 record and the expected p= value once the strings are concatenated.

If you use a CNAME-based provider configuration, query both the selector and the target:

dig +short CNAME s2025._domainkey.example.com
dig +short TXT s2025.example.provider-dkim.net

Use the hostname your provider actually gave you, not the placeholder above. A DNS lookup that returns NXDOMAIN, an empty answer, or an unexpected target means receivers cannot retrieve the key.

MXToolbox can provide a browser-based DKIM lookup and is useful when you need a quick second opinion. It is a diagnostic convenience, not the authoritative source; the authoritative result is the DNS record that receivers can resolve.

Check a real delivered message

Send a message from the production path to a mailbox you control. Then inspect the full message source and find Authentication-Results.

A healthy result often resembles:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s2025 header.b=abc123;
       spf=pass smtp.mailfrom=bounces.example.com;
       dmarc=pass header.from=example.com

The exact formatting varies by mailbox provider, but look for these outcomes:

• dkim=pass: The signature cryptographically validated.
• dkim=fail: A signature was found but could not validate.
• dkim=neutral: No conclusive result, often because a key was unavailable or the signature was not usable.
• dmarc=pass: SPF or DKIM passed with the required domain alignment.

A message can carry more than one DKIM signature. That is common when an email service signs with its own domain and also signs with your custom domain. For DMARC, focus on whether at least one aligned DKIM signature passes.

Services such as mail-tester.com can make this inspection easier by providing a test mailbox and a consolidated report. Use it for diagnostics, but do not overinterpret a single score: production inbox placement is based on recipient-specific reputation and behavior that a one-message test cannot reproduce.

Do not confuse submission success with authentication success

SMTP and HTTP acceptance codes only tell you that a particular system accepted a request at a particular stage.

For SMTP, a relay might respond with:

250 2.0.0 Queued as ABC123

That means the relay accepted the message for further processing. It does not prove the message was signed, delivered, accepted by the recipient mailbox, or placed in the inbox.

For a REST sending API, an HTTP 202 Accepted response commonly means the service accepted the request for asynchronous processing, not that final delivery has occurred. HTTP defines 202 as accepted for processing without guaranteeing completion. (rfc-editor.org)

This matters when you use an email platform through either a REST API or SMTP relay: test the production sending path, then inspect the received message headers. A successful API request plus a malformed DKIM record can still produce a later delivery or authentication problem. For implementation patterns and provider-specific integration details, use your platform’s email API setup guides alongside header-level verification.

Common 2048-bit DKIM mistakes

Publishing the wrong hostname

The record name is not just _domainkey.example.com. It must include the selector:

s2025._domainkey.example.com

Some DNS dashboards automatically append your root domain. If the dashboard is already scoped to example.com, entering the full hostname may accidentally create:

s2025._domainkey.example.com.example.com

After saving, always query the exact expected fully qualified name.

Adding line breaks, spaces, or PEM headers

Your p= value is a continuous base64 public-key value. Do not paste a PEM file directly. Do not retain BEGIN PUBLIC KEY and END PUBLIC KEY lines. Do not manually split the string with spaces between chunks.

Correct DNS chunking represents one continuous value:

"first-part-of-key" "second-part-of-key"

Incorrect manual editing changes the key:

"first-part-of-key second-part-of-key"

That inserted space becomes data and can cause verification to fail.

Replacing a live key in place

Do not overwrite the DNS public key for s2025 while some messages are still being signed with the old private key. Recipients that retrieve the new record will fail to validate messages signed by the old private key.

Use a new selector instead. For example, publish s2026._domainkey.example.com, begin signing with s=s2026, and retain s2025 until you are sure the old signing path is no longer in use.

Signing before DNS is visible

DNS propagation is not a single global event. Your authoritative DNS may show the record immediately while recursive resolvers continue using cached negative or old responses. Publish and resolve the new record before enabling the selector for live traffic.

Assuming an outbound gateway is harmless

An outbound security gateway, ticketing tool, or mail footer service may modify the body or headers after your application signs the message. If it modifies a signed part, DKIM can fail downstream.

Google specifically cautions that outbound gateways can interfere with DKIM when they modify outgoing messages, such as by adding a footer. If such a service must modify mail, sign after the modification point or configure the signing and canonicalization strategy appropriately. (support.google.com)

2048-bit DKIM and transactional email systems

For transactional email, the relevant question is not only which key size a provider offers. It is whether the entire sending architecture preserves authenticated, aligned mail.

A typical application stack may contain:

• A web application that calls a REST email API for receipts and password resets.
• A worker that sends notifications through SMTP.
• A support system that sends replies from the same visible domain.
• A marketing system that uses a subdomain or shared parent domain.
• A corporate mailbox service used for human replies.

Each of these may use a different selector, signing domain, return-path domain, and IP reputation pool. A 2048-bit key on one transactional platform does nothing for mail sent by another system with a missing or misaligned DKIM configuration.

A robust pattern is to separate mail streams by purpose while keeping ownership clear. For example:

Transactional From: receipts@example.com
Transactional DKIM d=: tx.example.com or example.com
Marketing From: news@example.com
Marketing DKIM d=: marketing.example.com or example.com
Support From: support@example.com
Support DKIM d=: example.com

There is no universally correct subdomain plan. The right design depends on how much operational separation you need, whether each provider supports custom-domain DKIM, and how your DMARC policy is managed. What matters is that you can answer three questions for every sender: what domain appears in From, what domain appears in DKIM d=, and does that signature pass and align?

If your email provider manages signing keys for your verified domain, you may never directly handle the private key or public-key text. That is fine. Your operational responsibilities are still to publish the supplied DNS record correctly, wait for verification, and test real mail after configuration changes.

A practical decision matrix

Use this matrix to decide what to do next.

The decision should be based on observed authentication results, not assumptions about the DNS zone. A record can look correct in a dashboard and still be published under the wrong name. A signature can be present in a message and still fail because the key does not match. A signature can pass and still fail DMARC because the wrong domain signed it.

Conclusion

Use 2048-bit DKIM for new deployments because it is the stronger, modern default and avoids carrying an avoidable migration task. But do not treat a working 1024-bit DKIM key as an automatic deliverability incident.

The priorities are clear: every legitimate mail stream should sign with DKIM, the public key must resolve correctly, the signature must pass on real delivered messages, and at least one passing identifier must align with the visible From domain for DMARC. Once those fundamentals are stable, rotate 1024-bit selectors to 2048-bit keys in a controlled change window.

A 2048-bit key is good email infrastructure hygiene. Reliable authentication coverage, accurate DNS, aligned domains, low complaint rates, and disciplined sending practices are what turn that hygiene into dependable delivery.

FAQ

Is 1024-bit DKIM still supported?

Yes. RFC 8301 sets 1024 bits as the minimum RSA key size that DKIM signers must use, and DKIM verifiers must be able to validate keys from 1024 to 2048 bits. A valid 1024-bit signature can still pass DKIM and support DMARC. (datatracker.ietf.org)

Does Gmail require 2048-bit DKIM?

Google’s published sender guidelines require authentication, including DKIM in the relevant cases, but do not state a separate 2048-bit DKIM key-length requirement. For bulk senders, the practical requirement is SPF, DKIM, and DMARC configured correctly. (support.google.com)

Will 2048-bit DKIM improve inbox placement?

Not by itself. It improves the cryptographic strength of the DKIM key, but inbox placement also depends on authentication alignment, reputation, recipient engagement, complaint rates, content, and sending behavior.

Why does my 2048-bit DKIM TXT record appear in two quoted strings?

Each individual DNS TXT character string is limited to 255 octets. DNS providers may split a long DKIM value into adjacent quoted strings that resolvers concatenate into one public key. That is normal when the published result remains one continuous DKIM record. (datatracker.ietf.org)

Can I replace an old DKIM key using the same selector?

You can, but it is risky. Messages signed with the old private key may fail verification after DNS begins returning the new public key. The safer approach is to publish a new selector, switch signing to it, verify live mail, and remove the old selector only after an overlap period.