The email hit my inbox at 6am on a Tuesday. Subject: "weak DKIM key length detected." Sender: our domain monitoring script. I'd set that alert up two years ago and promptly forgot about it.

Turns out, the DKIM key I'd generated in 2021 was 1024-bit. Worked fine for years. But Gmail's bulk-sender requirements (February 2024) and the general tightening across mailbox providers have made 1024-bit keys a yellow flag. Not a hard failure — yet — but enough of a signal that spam filters notice.

We're the JustEmails team, built by Velocity Digital Labs. DKIM key rotation is one of those tasks that looks simple in documentation and gets complicated in practice. The tricky part isn't generating a new key. It's switching without breaking authentication for mail that's already in transit. This guide covers the dual-selector method — the safe way to rotate DKIM keys without dropping messages.

Why 1024-Bit DKIM Keys Are Getting Flagged

RFC 6376 (the DKIM spec) doesn't mandate a key length. It just says RSA keys should be "at least 1024 bits." For years, 1024 bits was standard. Every email provider defaulted to it.

That's changed. Here's the shift:

Gmail and Yahoo's 2024 bulk-sender requirements recommend 2048-bit DKIM keys. They don't reject 1024-bit outright, but they log it. And anything logged can feed into spam scoring. (For a deeper dive on bulk sender requirements, see our email authentication compliance guide.)

Enterprise spam filters (Proofpoint, Mimecast, Barracuda) increasingly flag "weak cryptography" in their admin dashboards. IT teams see that warning and start asking questions.

The practical risk isn't that someone's going to factor your 1024-bit key tomorrow. RSA-1024 is still computationally hard to break. But mailbox providers are using key length as a reputation signal. Longer key = sender who pays attention to security = less likely to be a spammer.

Strong opinion: if you're still on 1024-bit, rotate. The cost is an hour of DNS work. The benefit is one less thing for receiving servers to side-eye.

What We're Building

By the end of this, you'll have:

A new 2048-bit DKIM key published under a new selector
Your mail server signing with the new key
The old selector kept alive (temporarily) so in-flight mail doesn't fail
A removal timeline for the old key once DNS has propagated

Total DNS records touched: 1 new, 1 old (eventually deleted). Downtime: zero, if you follow the steps.

Prerequisites

Before you start:

Access to your domain's DNS (you'll be adding a TXT record)
Access to your mail server's DKIM configuration (or your email provider's dashboard)
Your current DKIM selector name (check your existing DNS: dig TXT selector._domainkey.yourdomain.com)
15-30 minutes

If you're using JustEmails, we auto-generate 2048-bit keys and handle rotation — you can skip this guide. For teams comparing email hosting options, we wrote a detailed Google Workspace alternatives comparison. If you're on Google Workspace, Zoho, or self-hosted Postfix/Dovecot, keep reading.

Step 1: Find Your Current DKIM Selector and Key Length

First, confirm what you're working with. Your DKIM selector is the prefix before ._domainkey in DNS. Common selectors: default, google, selector1, s1, or a timestamp like dkim202103.

Pull your current key:

dig TXT default._domainkey.yourdomain.com +short

You'll see something like:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

That p= value is the public key. A 1024-bit RSA key encodes to about 216 characters in base64. A 2048-bit key is about 392 characters. Quick eyeball test: if the p= value fits on one line in your terminal, it's probably 1024-bit.

For certainty, decode it:

echo "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..." | base64 -d | openssl rsa -pubin -inform DER -text -noout

Look for "RSA Public-Key: (1024 bit)" or "(2048 bit)" in the output.

Step 2: Generate a New 2048-Bit Key Pair

Generate the new key. I use OpenSSL, but any RSA key generator works:

openssl genrsa -out dkim-private-2048.pem 2048
openssl rsa -in dkim-private-2048.pem -pubout -out dkim-public-2048.pem

Now extract the public key in DNS format. The public key file has header/footer lines and newlines you need to strip:

grep -v "PUBLIC KEY" dkim-public-2048.pem | tr -d '\n'

That outputs a single base64 string. This goes in your DNS TXT record as the p= value.

Important: Keep the private key secure. It goes on your mail server. Never commit it to a repo or paste it in Slack. If you leak it, anyone can sign mail as your domain. For broader security practices, the VDL engineering blog covers key management across multiple products.

Step 3: Choose a New Selector Name

Your new key needs a different selector than your current one. This is what makes the dual-selector method work — both keys coexist in DNS during the transition.

Naming conventions that work:

Timestamp-based: dkim202607 (year + month)
Sequential: selector2 if current is selector1
Descriptive: primary2048 or new2048

I like timestamps because they're self-documenting. Six months from now, dkim202607 tells you when you rotated. (I learned this the hard way after staring at selector2 in three different domains and having no idea which was current.)

Don't reuse the old selector name. That defeats the entire purpose. You'd be overwriting the old key, creating a propagation gap.

Step 4: Publish the New Key in DNS

Add a TXT record for your new selector. If your new selector is dkim202607:

dkim202607._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

The full record looks like:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx7X3p5yN..."

Some DNS providers (Cloudflare, Route53) automatically handle TXT record quoting. Others require you to wrap the value in double quotes yourself. If the record is over 255 characters (2048-bit keys always are), you may need to split it:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx7X3p5yN..."
"...rest of the key continues here..."

Most modern DNS providers handle this automatically. If yours doesn't, split at roughly 250 characters and concatenate with a space between quoted strings.

Verify the record is live:

dig TXT dkim202607._domainkey.yourdomain.com +short

Give it 5-15 minutes if you just added it. Some resolvers cache longer.

Step 5: Update Your Mail Server to Sign With the New Key

This is the part that varies by mail server. The goal: configure your server to sign outgoing mail using the new private key and selector.

Postfix with OpenDKIM:

Edit /etc/opendkim.conf:

Selector    dkim202607
KeyFile     /etc/opendkim/keys/yourdomain.com/dkim-private-2048.pem

Restart OpenDKIM:

systemctl restart opendkim

Google Workspace:

Google manages DKIM for you, but you can rotate manually: Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record. They'll give you a new selector (usually google with a timestamp suffix). Add it to DNS, then click "Start authentication" in the console.

Postmark, SendGrid, Mailgun:

These providers manage DKIM signing infrastructure. If you set up custom DKIM years ago, log into their dashboard and check whether you're on their current signing infra. Some have a "Regenerate DKIM" or "Rotate keys" option. They handle the dual-selector dance internally — you just update the DNS CNAMEs they give you.

Rspamd:

Edit your DKIM signing configuration (usually /etc/rspamd/local.d/dkim_signing.conf):

selector = "dkim202607";
path = "/var/lib/rspamd/dkim/yourdomain.com.dkim-private-2048.pem";

Reload Rspamd:

systemctl reload rspamd

After updating, send a test email to a Gmail account. (If you're running analytics on your email performance, JustAnalytics can track open rates and delivery metrics across domains.) Open the message, click "Show original," and look for:

DKIM-Signature: ... s=dkim202607; d=yourdomain.com; ...

Confirm s= matches your new selector and the dkim=pass line shows in the Authentication-Results header.

Step 6: Verify With Gmail and External Tools

Check Google Postmaster Tools if you're sending volume to Gmail. The DKIM status should stay green after the switch. If it dips, something's misconfigured.

External validators:

Mail Tester: Send an email to mail-tester.com and check the DKIM section
MXToolbox DKIM Lookup: Enter dkim202607:yourdomain.com and verify the key is found
DMARC aggregate reports: If you're running DMARC (and you should be — see our DMARC ramp guide), your daily aggregate reports will show DKIM pass/fail by selector

Step 7: Wait, Then Remove the Old Selector

Here's where people rush and break things. Your old selector is still in DNS. Mail servers that cached your old key can still verify old signatures. Leave it there.

Wait at least 72 hours. Some DNS resolvers cache aggressively. Some mail is delayed in queues for days before final delivery. If a message signed with the old key is delivered 48 hours after you remove the old DNS record, DKIM verification fails.

After 72 hours, check your DMARC reports. If you see no DKIM failures on the old selector and consistent passes on the new one, you're safe to delete the old TXT record:

# Delete this after 72+ hours
default._domainkey.yourdomain.com.  IN  TXT  ...

Some teams keep the old selector for a week. There's no real cost — it's just a DNS record. Remove it when you're confident.

Common Errors

I've hit all of these at least once. Frustrating every time.

"DKIM signature length does not match key length" in headers:

dkim=neutral (bad format)

You probably pasted the key incorrectly. Check for stray whitespace, newlines, or missing characters in the p= value. The base64 string must be continuous (or properly split with quotes if over 255 chars).

New selector not found after adding DNS record:

dig TXT dkim202607._domainkey.yourdomain.com
# returns NXDOMAIN

DNS hasn't propagated yet, or you added the record to the wrong zone. Double-check you're editing the correct domain's DNS panel. Some registrars have multiple DNS sections.

DKIM signature header missing entirely:

Your mail server isn't signing. Check that the new private key file path is correct and readable by the mail process. On Linux, permissions issues are common: chown opendkim:opendkim /path/to/key.pem && chmod 600 /path/to/key.pem.

Verification passes locally but fails at Gmail:

Clock skew. This one drove me nuts for an hour. DKIM signatures include timestamps. If your mail server's clock is significantly off from reality, signatures fail validation. Run ntpdate pool.ntp.org or check your time sync daemon.

Next Steps

Once you're on 2048-bit, add a calendar reminder to rotate again in 12-18 months. Key rotation isn't a one-time fix — it's hygiene. Some orgs rotate quarterly; annual is fine for most.

Related guides:

Set up MTA-STS and TLS-RPT for encrypted mail delivery
DMARC from p=none to p=reject if you haven't enforced yet
BIMI setup for your logo in Gmail — requires DMARC enforcement first

If you're managing multiple domains and tired of repeating this process per-domain, JustEmails handles DKIM key generation and rotation automatically across unlimited domains for $49/year. Check our pricing page for full details. For click fraud on your paid campaigns, ClickzProtect catches bot traffic before it drains your budget.

Questions about DKIM key rotation or hitting a weird edge case? support@justemails.app. We answer email.

Frequently Asked Questions

Why is my 1024-bit DKIM key suddenly a problem?

It's been a slow-moving problem for years, but 2024-2025 enforcement changed the math. Gmail and Yahoo's bulk-sender requirements explicitly recommend 2048-bit keys. Some enterprise spam filters now log 1024-bit keys as "weak cryptography" warnings, which can contribute to spam scoring. The practical risk isn't that 1024-bit keys are being factored today — it's that mailbox providers are using key length as a sender-reputation signal. Longer key = more serious sender.

Can I just replace my 1024-bit key in place without the dual-selector dance?

You can, but you'll have a gap. DNS propagation takes anywhere from minutes to 48 hours depending on TTLs and resolver caching. During that window, mail signed with the new key will fail DKIM verification at receivers still seeing the old DNS record. If you're at p=reject on DMARC, that mail bounces. The dual-selector approach avoids this by keeping the old key alive until DNS has fully propagated.

How do I know when the old selector is safe to remove?

Wait at least 72 hours after switching your mail server to the new selector. Monitor DMARC aggregate reports during that window — look for any DKIM failures on the new selector. If you see none after 72 hours and your TTL was under 24 hours, you're clear. Some teams keep the old selector around for a week just to be safe. There's no cost to leaving it in DNS temporarily.

Does key length matter for transactional email providers like SendGrid or Postmark?

Yes, but they manage it for you. When you enable custom DKIM on SendGrid, Postmark, or similar, they generate and rotate keys on their infrastructure. Check their dashboard for the current key length — most have moved to 2048-bit by default. If you set up custom DKIM years ago, your CNAMEs might still point to an older key; re-verify in their dashboard that you're on their current signing infrastructure.

Try JustEmails

Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.

Start your 7-day free trial → · How it compares

Fix a DKIM Key That Is Too Short: Rotating From 1024-Bit to 2048-Bit