DKIM Key: Best Length, DNS Setup, and Rotation

Your dkim key is one of the DNS records standing between normal delivery and silent failure. If it’s too weak, malformed, or stale, mailbox providers stop trusting your mail fast. That matters more now because Gmail has been enforcing sender authentication requirements since February 2024 and tightened enforcement again starting November 2025. If you’re still cleaning up DNS basics, start with business email and then come back here.

Here’s the short answer. Use a 2048-bit RSA dkim key. Publish it correctly in DNS, which usually means splitting the TXT value into multiple quoted strings. Rotate it on a schedule with selectors. Keep the old selector live for a few days after the cutover. That’s the operator-safe path.

If you’re setting up a new domain, pair this with create email with your domain and TrekMail’s required DNS records checklist so DKIM, SPF, and DMARC go live together.

What is a DKIM key?

A dkim key is the public half of your DKIM signing setup. Your mail server signs outgoing mail with a private key, and receiving servers fetch the public dkim key from DNS to verify the message wasn’t altered and really came from an approved sender for your domain.

DKIM stands for DomainKeys Identified Mail. In practice, the private key lives on the sending system and the public key lives in DNS under a selector, usually something like s1._domainkey.example.com.

When a message arrives, the recipient server checks the DKIM signature in the headers, looks up your dkim key in DNS, and validates the signature. If that works, the receiver knows two things:

• The message body and signed headers weren’t changed in transit.
• The sender had access to the private key for that domain and selector.

That doesn’t guarantee inbox placement. It does give your mail a trusted cryptographic signal, which is exactly what modern filtering systems expect.

What DKIM key length should you use?

Use a 2048-bit RSA dkim key in 2025 and 2026. The standards baseline still allows 1024-bit RSA, but the current practical recommendation is 2048-bit because it gives you stronger protection without the DNS headaches and compatibility risk that come with 4096-bit keys.

The formal baseline comes from RFC 8301: signers must use at least 1024-bit RSA keys and should use at least 2048-bit RSA keys. That “should” matters. It reflects where real-world operations have landed.

If you inherit an older mail stack, don’t assume the dkim key is fine. Older control panels and mail systems often generated 1024-bit keys by default. That was acceptable years ago. It’s not where you want to be now.

Google’s sender documentation is the operational proof point here. Gmail requires DKIM for bulk senders, and its FAQ documents rate limits when DKIM authentication fails. See Google’s email sender guidelines FAQ.

Why a 2048-bit DKIM key breaks in DNS

A 2048-bit dkim key often breaks because DNS TXT strings have a 255-character limit per quoted chunk. The full public key is longer than that, so if your DNS panel expects one long pasted value, it may reject it, truncate it, or store it incorrectly.

This is the part that trips people up. The problem usually isn’t the crypto. It’s the DNS UI.

The public value in the p= tag for a 2048-bit RSA dkim key is long enough that many providers need it split across multiple quoted strings inside a single TXT record. DNS resolvers stitch those strings back together during lookup. If your provider does not do that correctly, validation fails.

Common failure modes:

• The DNS panel chops the record at 255 characters.
• The panel adds stray spaces or line breaks into the key.
• You publish multiple TXT records instead of one TXT record with multiple quoted strings.
• You remove part of the v=DKIM1; k=rsa; p= prefix while trying to shorten it.

If you mess this up, you don’t get a weak dkim key. You get a broken dkim key.

How to publish a 2048-bit DKIM key correctly

Publish one TXT record for one selector, and split the long value only at the DNS string level. The receiving server will concatenate the strings. Your job is to keep the record syntactically valid and then verify the exact DNS response with command-line lookups.

Zone-file style syntax looks like this:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

Many DNS web interfaces want the same record on one line:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

Then verify it from the outside. Don’t trust the UI preview.

dig txt s1._domainkey.example.com +short

You want to see the TXT response returned cleanly. Two quoted strings are fine. That’s normal. Missing chunks, weird escaping, or partial output means the dkim key in DNS is wrong.

If you’re using TrekMail, the easiest route is to follow managed TrekMail SMTP plus the DNS wizard. Paid plans include managed SMTP, and TrekMail publishes the domain-specific DKIM record value you need in the dashboard. Starter begins at $3.50 per month, and paid plans come with a 14-day free trial that requires a credit card. The Nano plan stays free and uses your own SMTP.

Conceptual example: You generate a 2048-bit dkim key, paste it into a registrar that silently truncates long TXT values, and mail still leaves your server. Nothing looks broken until Gmail starts rating the traffic as unauthenticated. That’s why you verify from the outside.

How to rotate a DKIM key without breaking mail

Rotate a dkim key by adding a new selector, publishing the new public key, switching signing to that selector, and leaving the old selector online for a grace period. Never overwrite the old key in place. Selector-based rotation avoids DKIM failures on delayed or retried mail.

This is the safe workflow:

1. Generate a new 2048-bit dkim key pair.
2. Assign it a new selector, like s2.
3. Publish s2._domainkey.example.com in DNS.
4. Switch your outbound signing config to s2.
5. Keep s1 published for at least several days.
6. Remove s1 only after the old signed mail has aged out.

A practical grace period is 7 days. That covers delayed delivery, queue retries, and the usual DNS cache noise.

Don’t replace the old dkim key at the same selector unless you control every signing and delivery edge case. Most teams don’t. Selectors exist for a reason. Use them.

If you run multiple sending systems, document which selector belongs to which system. That matters when you’re debugging failures from a CRM, ticketing platform, web app, and human mailbox provider all using the same domain.

When should you rotate a DKIM key?

Rotate a dkim key on a fixed schedule and also after any private-key exposure, vendor change, or sending-platform migration. A six-month cadence is a sane default for most teams. High-risk environments may rotate faster, but random one-off rotations are worse than a predictable policy.

Here’s the operator rule: if a private key might have leaked, rotate immediately. If nothing is wrong, rotate on schedule anyway.

Good triggers for early rotation:

• You moved outbound mail from one provider to another.
• You offboarded a vendor that had signing access.
• You exported keys through an insecure workflow.
• You found an old shared admin account no one can explain.

Bad triggers:

• “We’ll do it later when we have time.”
• “The current dkim key still passes, so it’s fine.”
• “We don’t remember where the private key lives.”

If you manage lots of client domains, this turns into an operations problem, not a crypto problem. That’s where multi domain email hosting starts to matter. One domain is manual work. Fifty domains is process debt.

Should you use Ed25519 for a DKIM key?

Ed25519 gives you a much shorter dkim key and avoids the TXT-length mess that comes with RSA-2048. The catch is receiver compatibility. It was standardized for DKIM in RFC 8463, but RSA-2048 is still the safer default when you need broad, boring interoperability.

The main operational advantage is size. An Ed25519 public key is tiny compared with an RSA dkim key, so DNS publishing is simpler and less fragile.

The main operational downside is support variance. Some receivers and tools handle it well. Others still behave inconsistently. If you need universal compatibility, sign with RSA-2048. If your platform supports dual signing and you know your downstream path, testing Ed25519 alongside RSA can make sense.

For most operators, this is the decision:

• Use RSA-2048 as the default dkim key.
• Use Ed25519 only if you understand receiver compatibility and can test it properly.
• Don’t switch to Ed25519-only just because the DNS record looks cleaner.

Old way vs new way: managing DKIM at scale

The old way is hand-editing TXT records, pasting giant public keys into random registrar panels, and hoping nobody forgets rotation. The new way is delegated, repeatable DNS and signing management, where the dkim key lifecycle is part of your mail platform instead of a recurring ticket.

Old way:

• Every domain has a different DNS UI.
• Each dkim key rotation is a calendar reminder somebody ignores.
• One typo in one registrar breaks mail for one client and nobody notices until deliverability drops.

New way:

• One workflow for many domains.
• Managed SMTP signs mail consistently.
• You stop wasting time debugging long TXT records and auth drift.

This is where TrekMail fits. It’s built for flat-rate multi-domain email hosting, not per-user billing gymnastics. You get pooled storage, IMAP mailboxes, built-in IMAP migration, catch-all, forwarding, BYO SMTP on Nano, and managed SMTP on paid plans. If you’re already juggling forwarding rules, the failure mode is usually authentication drift, which is why forward domain email to Gmail matters too.

For teams and agencies, the win isn’t that TrekMail makes DNS magical. It’s that it removes repeatable failure from a task that should never have been manual in the first place. Pricing starts at $3.50/month on Starter.

Final answer on the DKIM key

Your dkim key should be RSA-2048, published correctly in DNS, verified with real lookups, and rotated by selector on a schedule. That’s the clean answer. If you’re still on 1024-bit keys, move. If your DNS panel mangles long TXT values, fix the publishing method or move the responsibility to a platform that handles it properly.

And don’t look at DKIM in isolation. A working dkim key helps most when SPF, DMARC, and sending infrastructure are aligned too. TrekMail’s docs on required DNS records and the blog guide on create email with your domain are the right next steps if you’re tightening up the whole stack.