Rotate DKIM to 2048-bit Keys Safely

If your domain still signs email with a 1024-bit DKIM key, your mail is not broken today. Gmail accepts keys of 1024 bits or longer for personal Gmail accounts, but Google's own sender guidelines recommend a 2048-bit key if your domain provider supports it.

The DKIM standard says the same thing more firmly. RFC 8301 says signers MUST use RSA keys of at least 1024 bits and SHOULD use keys of at least 2048 bits.

A careful selector overlap can avoid verification failures when your mail provider lets you publish a new selector before switching signing. Managed providers differ, so this is a procedure to verify, not a zero-downtime guarantee. Follow the provider's current console instructions and keep a rollback path.

By the end of this guide you will be able to check your current key length, publish a 2048-bit key next to the old one, switch over, and prove from a real email header that it worked.

What does DKIM key length actually mean?

DKIM (DomainKeys Identified Mail) is a signature your mail server adds to every message it sends. The server signs with a private key that stays secret. Receiving servers check that signature with a public key that you publish in DNS as a TXT record (a plain text record anyone can look up).

Key length is the size of that key in bits. A longer key is much harder to crack. RFC 8301 explains why this matters: short RSA keys more easily give in to offline attacks, where someone works on breaking your key on their own machines for as long as they like.

Think of it like a combination lock with more digits. You know the code, so it opens just as easily for you, while a stranger has far more guessing to do.

Why this matters: if someone cracks your private key, they can sign fake email that looks like it really came from your domain. Receivers would see a valid DKIM signature and trust it.

What is a selector?

A selector is a short name that points receivers to one specific public key. Your mail server writes it into every signature in the s= tag, next to your domain in the d= tag.

Receivers then look up a DNS name built from those two values. RFC 6376 says all DKIM keys are stored under a subdomain called _domainkey, so a selector called google2026 on example.com lives at google2026._domainkey.example.com.

This is the whole secret of a safe upgrade. RFC 6376 says selectors exist so a domain can have several public keys at the same time. During a change of keys, both keys are published together, and the old one is removed only at the end of the transition.

Before you start

Give yourself a calm half hour for the work, plus waiting time for DNS.

• DNS access: you can log in to the place where your domain's DNS records are managed, and you can add a TXT record.
• Current mail provider: you know who actually sends your mail, for example Google Workspace or your cPanel hosting server.
• Admin access at that provider: for Google Workspace, Google says you need to sign in as a super administrator.
• A backup of your current DKIM record: you will make this in Step 2 below.
• A test inbox: a Gmail address that is different from the one you send from.
• A terminal with dig and openssl installed.
• Risk level: low, as long as you never delete the old record before the new one is proven. The old selector is your safety net.

Quick tip: if you have not set up SPF, DKIM and DMARC together before, read our guide on setting up SPF, DKIM and DMARC for small business email first. This guide assumes DKIM is already working with the old key.

The safe upgrade, step by step

Made-up example: Sana runs a small online bakery on example.com with an old 1024-bit DKIM key under the selector google. Her provider supports overlapping selectors, so she can use the generic sequence below. Google Workspace users must also read the provider-specific caveat later in this guide.

Step 1: Read your current DKIM record

First, find out which selector you use today. Open an email from your domain in a Gmail inbox other than your own, then click More beside Reply and choose Show original. Google's help page says the full header opens in a new window.

Look for the DKIM-Signature header in that window. Find the s= value (your selector) and the d= value (your signing domain).

This command asks DNS for the public key published under the selector google on example.com.

dig +short TXT google._domainkey.example.com

You should see one line of text in quotes that starts with v=DKIM1;, followed by k=rsa; and a long p= value. RFC 6376 says v=DKIM1 must be the first tag, k= is the key type with a default of rsa, and p= holds the public key in base64 (a way of writing binary data as letters and numbers).

If you get no output at all, check that you used the exact selector from the header.

Step 2: Back up the current record

Before you change anything in DNS, save what is there now. If your DNS host has an export button for the whole zone, use it and keep the file somewhere safe.

This command saves the current DKIM record for the google selector into a text file on your computer.

dig +short TXT google._domainkey.example.com > dkim-backup-google.txt

Open dkim-backup-google.txt and check that it contains the v=DKIM1 line.

Step 3: Check how long your current key is

The p= value does not say its length out loud, so you decode it. Copy only the long base64 text after p=, without the quotes or the trailing semicolon.

This command decodes the public key and asks OpenSSL to print its details. Replace PASTE_P_VALUE_HERE with your copied value.

echo "PASTE_P_VALUE_HERE" | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1

You should see a line like Public-Key: (1024 bit) or Public-Key: (2048 bit). If it already says 2048, you are done. I tested this exact command with OpenSSL 3.0.13.

Step 4: Generate a new 2048-bit key under a new selector

Now create the new key at your mail provider. Pick a selector name you have never used on this domain, such as google2026. The exact clicks depend on your provider, so jump to the matching section below and then come back here.

• Google Workspace: see "Google Workspace variant" below.
• cPanel hosting: see "cPanel variant" below.
• Anything else: see "Other mail providers" below.

Whatever the provider, you will end up with two things: a DNS host name like google2026._domainkey and a TXT value that starts with v=DKIM1; k=rsa; p=.

Step 5: Publish the new record next to the old one

Log in to your DNS host and add a new TXT record. Do not edit the old record. You are adding a second one beside it.

This is what the new record looks like, written in standard zone file form with a placeholder where your real key goes.

google2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PASTE_THE_FULL_KEY_FROM_YOUR_PROVIDER"

In most DNS panels you will type the name part into a field called host or name, and paste the full value into the value field. Copy the value straight from your provider's screen, in one go, so nothing gets cut off.

Step 6: Confirm the new record is live before you switch

This command looks up the new selector you just published.

dig +short TXT google2026._domainkey.example.com

You should see the new v=DKIM1 line. Run the decode check from Step 3 on this new p= value and confirm it prints Public-Key: (2048 bit).

Then check the old one is still there, because receivers may still need it.

dig +short TXT google._domainkey.example.com

If both selectors return a record, you are in the safe zone.

Step 7: Switch signing to the new selector

Only now do you tell your mail provider to sign with the new key. On Google Workspace this is the Start authentication step. On other providers it may be called activate or switch.

Why this matters: a message signed a few minutes ago with the old key, or one still sitting in a queue, needs the old public key when it is checked. Keeping both published makes the switch invisible.

Step 8: Clean up the old selector later, not today

Once new mail consistently shows dkim=pass with the new selector, keep the old public key for a reasonable validation interval before retiring it. RFC 6376 explains that messages can be in transit or verification can be deferred; it does not define one universal waiting period. Your provider's retry queues and retention guidance decide the interval. An empty p= value revokes the key.

This is what a revoked record looks like if you choose to keep the name but empty the key.

google._domainkey.example.com. IN TXT "v=DKIM1; p="

Deleting the record works too. Either way, anything still signing with the old selector will fail.

Google Workspace variant

Google's setup page offers a 2048-bit option, but do not assume the generic overlapping-selector sequence is guaranteed to be interruption-free. The documented flow is Generate New Record, publish the DNS record, then Start authentication. Google does not promise zero interruption during a rotation, so schedule the change, capture the current record and selector first, and keep rollback access.

1. Sign in to the Admin console as a super administrator.
2. Go to Menu > Apps > Google Workspace > Gmail, then click Authenticate email.
3. In Selected domain, choose your domain.
4. Click Generate New Record.
5. Under key length, choose 2048. Google says to pick this if your domain provider supports 2048-bit keys.
6. In the prefix selector field, enter a new prefix such as google2026. Google says the default prefix is google, and if your domain already uses that prefix you should enter a different one.
7. Click Generate, then copy the DNS host name and the TXT record value. The value follows the format v=DKIM1; k=rsa; p= followed by the key.
8. Do not start authentication yet. Google's page says this in plain words: "Do not click Start Authentication yet."
9. Publish the record at your DNS host, as in Step 5, and confirm it with dig, as in Step 6.
10. Return to Authenticate email, select the domain, and click Start authentication. Google says success shows "Authenticating email with DKIM" at the top of the page.

Google confirms that you can switch from 1024 to 2048 bits when the DNS provider supports the longer record. Verify a fresh external message after Start authentication; if the new selector does not pass, restore the previous documented state or follow Google Workspace support guidance.

cPanel variant

On cPanel hosting, DKIM lives in the Email Deliverability interface. The cPanel documentation says your hosting provider turns this feature on in WHM's Feature Manager, so if you cannot find it, ask your host.

1. Open Email Deliverability in cPanel.
2. Click Manage for the domain you want to check.
3. Read the DKIM section. If problems exist with the current record, cPanel shows a Suggested DKIM (TXT) Record with the correct values.
4. Compare the suggested record with what dig returns for your selector. Copy the record name and value exactly as cPanel shows them.
5. Run the decode check from Step 3 on that p= value to see the real key length.

The cPanel docs describe Generate Local DKIM Key as an option that generates a DKIM record if one does not exist. The same page does not state the key length or the selector name cPanel uses, so do not assume either one. Read the suggested record and check it yourself.

If your check shows 1024 bits and you want 2048, ask your host how they generate keys on that server. The private key lives on the server, so the change to signing has to happen there, even though you may publish the DNS record yourself.

Heads up: the cPanel page also has View the Private Key, and it warns that exposing the private key is a security risk. You never need it to publish DNS.

Other mail providers

Every email service that signs for your domain has its own DKIM page, so follow the provider's own instructions for the clicks.

• Generate the new key on the provider's page and choose 2048 bits if it offers a choice.
• Copy the selector name and the full TXT value from that page. Do not retype them by hand.
• Publish it as a new record, check it with dig, and only then press the provider's activate or switch button.
• Keep the old record until the new selector shows dkim=pass on real mail.

If you are not sure where your DNS is actually managed, our guide on connecting a domain to your hosting helps you work it out.

How to check it worked

Start with DNS. These two commands should both return a v=DKIM1 record while you are in the transition period.

dig +short TXT google2026._domainkey.example.com
dig +short TXT google._domainkey.example.com

If you want to ask one specific name server directly, the dig manual describes the @server form, where server is the name or IP address of the name server to query. This command asks your domain's own name server, shown here as the placeholder ns1.example.com, for the new record.

dig @ns1.example.com +short TXT google2026._domainkey.example.com

Next, send a real test message. Google says you cannot verify by emailing yourself, so send to a different Gmail or Google Workspace address.

Open the message in that inbox, click More beside Reply, and choose Show original. Find the Authentication-Results header.

This is an illustrative example of the line you want to see. Your exact header will have more text around it.

Authentication-Results: mx.google.com; dkim=pass header.d=example.com header.s=google2026

Read that line slowly. The DKIM result should be pass, header.d should be your domain, and header.s should be your new selector. RFC 8601 registers header.s as the value of the signature's s= tag.

In Sana's made-up case, the bakery's order emails would now show header.s=google2026 while the old google record quietly waits in DNS as her safety net.

Give it time. Google says DKIM can take up to 48 hours to start working after you add the key, and the Authenticate email page may show "You must update the DNS records" for up to 48 hours. If you added the key correctly, Google says you can ignore that message.

Troubleshooting

dig returns nothing for the new selector

Symptom: dig +short TXT google2026._domainkey.example.com prints an empty line.

Likely cause: the record was never saved, or the name was entered in a form your DNS panel did not expect.

Fix: compare the record name letter by letter with the host name your provider gave you. To test whether the domain got added twice, try this lookup.

dig +short TXT google2026._domainkey.example.com.example.com

If it appears there, fix the record name. Do not switch signing until the normal lookup in Step 6 works.

The header says dkim=fail after the switch

Symptom: Show original shows a DKIM result of fail with header.s=google2026.

Likely cause: the public key in DNS does not match the private key your provider signs with, usually from a copy and paste slip or switching before the record was live.

Fix: copy the TXT value again from your provider and replace the DNS value. If you need mail working right now, switch signing back to the old selector, whose record is still published.

The p= value has a typo or was cut short

Symptom: the decode command in Step 3 prints an error instead of Public-Key:, or the header shows permerror or neutral.

Likely cause: a missing character or a value cut off when pasting. RFC 6376 says a key record that does not match the format makes the verifier return PERMFAIL (key syntax error).

Fix: delete the new record and add it again with a fresh copy. Then run the decode check before you switch. Google's page notes that some providers limit TXT record length, so check your provider's character limits if the value keeps getting cut.

The key still shows 1024 bits

Symptom: the decode check on the new selector prints Public-Key: (1024 bit).

Likely cause: the key was generated with the 1024 option. On Google Workspace this is a separate choice from 2048. Google offers 1024 for DNS hosts that do not support 2048-bit keys.

Fix: generate a new record with 2048 selected and a fresh selector name, then repeat Step 6. If your DNS host cannot store the longer value, 1024 still meets Gmail's minimum.

The signature still uses the old selector

Symptom: DKIM passes, but header.s and the s= tag still show google.

Likely cause: the new record is published but signing was never switched, or the change has not taken effect yet.

Fix: confirm you pressed the switch button, which on Google Workspace is Start authentication, then send a new test message. Old messages will always show the old selector.

dkim=temperror on a test message

Symptom: the header shows temperror for DKIM.

Likely cause: RFC 8601 says this result means a transient error, such as a temporary inability to get the public key from DNS.

Fix: wait a little and send another test. If it keeps happening, test your name servers with the dig @server command above.

Old mail started failing after cleanup

Symptom: after you removed or emptied the old record, some messages fail DKIM with the old selector.

Likely cause: something still signs with the old key, such as a second sending service or another server. RFC 6376 says a verifier returns PERMFAIL (no key for signature) when the key record does not exist, and PERMFAIL (key revoked) when p= is empty.

Fix: restore the old record from your Step 2 backup, find what still uses that selector, and move it to a new key.

Pro tips and security notes

• Never put the private key in DNS. DNS only ever holds the public key, the p= value.
• Never paste a private key into chat or a support ticket. If you ever did, treat that key as burned and replace it.
• Use selector names that tell you when you made them, like google2026. Next time you rotate, you will know which one is older.
• Keep the bigger picture in mind. At the time of writing (13 November 2026), Google's sender guidelines say that since 1 February 2024, all senders to Gmail accounts must meet its requirements, and senders of more than 5,000 messages per day face stricter ones. Google also asks you to keep spam rates in Postmaster Tools below 0.10% and avoid ever reaching 0.30% or higher.

When to ask your host

Ask your host or email provider if the DKIM page is missing from your control panel, or if your DNS host will not save the long value. On cPanel servers, the signing key lives on the server, so the host controls how it is generated.

The one message worth forwarding

If someone else manages your mail or DNS, send them this.

Hi, I'd like to upgrade our DKIM key for example.com from 1024 to 2048 bits without any failed signatures. Please:

1. Generate a new 2048-bit DKIM key under a NEW selector (for example google2026). Do not reuse or edit the current selector.
2. Publish the new TXT record at google2026._domainkey.example.com next to the existing one, and confirm it with: dig +short TXT google2026._domainkey.example.com
3. Only after the new record resolves, switch signing to the new selector.
4. Send a test email to an outside Gmail address and confirm Authentication-Results shows dkim=pass with header.s=google2026.
5. Keep the old selector's record published for a reasonable validation interval after the new selector passes, using the mail provider's retry and retention guidance. Then retire it.

Please do not send me or anyone else the private key. Thanks!

The takeaway: use a new selector when your provider supports it, verify DNS before switching, confirm real external mail, and retain the old public key for a reasonable validation interval. Treat managed-provider console instructions as authoritative.