Fix DKIM Key Too Short Warning (1024-bit Deprecated)

What's happening

RFC 8301 (published 2018) updates RFC 6376 to require RSA keys of at least 1024 bits and recommends 2048-bit. Modern receivers including Microsoft 365 actively flag 1024-bit and shorter keys as a deliverability concern, and several specs in development push the minimum toward 2048 universally.

When a receiver evaluates a short key, it may pass DKIM but log a warning, or in stricter configurations it may treat the signature as invalid. Headers show k=rsa with p= containing a 1024-bit key (approximately 215 base64 characters in p=) — the visible signal of the problem.

Short keys are also vulnerable to factoring attacks. Academic research has demonstrated practical 1024-bit RSA key recovery for well-funded adversaries, and 768-bit keys (still found in legacy configurations) have been broken since 2010. A short DKIM key is a phishing risk because attackers who recover the private key can send signed mail as your domain.

Why it matters

Microsoft 365 explicitly flags short DKIM keys in Defender for Office 365 reports and may apply a small antispam score penalty. Gmail does not currently fail short keys but treats them as a soft signal in domain reputation.

Procurement and security reviews routinely flag 1024-bit DKIM as a finding. SOC 2 auditors and CISO-led security questionnaires increasingly include DKIM key length as a checklist item.

Cryptographic risk: a forged DKIM signature lets attackers send phishing mail that passes DKIM and DMARC, bypassing your strongest authentication layer entirely. Rotation is the only defense.

Common causes

• Legacy ESP onboarding from before 2018 generated 1024-bit keys by default.
• Self-hosted OpenDKIM/rspamd configured with 1024-bit at install time.
• Manual key generation with openssl genrsa 1024 instead of openssl genrsa 2048.
• ESP that defaults to 1024 unless the operator explicitly chooses 2048.
• Inherited DNS zone from a domain transfer where the old key was preserved.

Detect this on your site

Run a quick scan with the Email Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Inventory selectors and key lengths

   List every DKIM selector for your domain (DKIM-Signature s= values from recent sent mail). For each, run dig +short TXT s=selector._domainkey.example.com and count base64 characters in the p= field. 1024-bit keys are roughly 215 chars of base64; 2048-bit are roughly 392 chars.

2. 2

   Generate a 2048-bit replacement at the ESP

   Most ESPs (SendGrid, Mailgun, Postmark, Resend, AWS SES) have a "rotate DKIM" or "regenerate DNS records" button that produces a fresh 2048-bit key. Generate the new key but do not yet enable it for signing — the ESP holds it pending DNS publication.

3. 3

   Publish the new key under a new selector

   Use a dated selector (2026a._domainkey, k2026._domainkey, or vendor-specific s2._domainkey). Add the TXT record with v=DKIM1; k=rsa; p= at TTL 3600. Do not touch the old selector yet — it stays live for backward compatibility during rotation.

4. 4

   Verify and switch signing to the new selector

   Run dig +short TXT 2026a._domainkey.example.com to confirm propagation, then click Verify in the ESP. Once verified, switch the ESP to sign all outbound mail with the new selector. Send a test and confirm the DKIM-Signature header shows s=2026a.

5. 5

   Wait for in-flight mail to drain, then delete the old selector

   Mail signed with the old key may still be in transit or quarantined at receivers for several days. Wait 7 days, then delete the old selector TXT record at your DNS provider. This finalizes the rotation and removes the cryptographic risk.

6. 6

   Self-hosted: regenerate OpenDKIM keys

   If you run your own MTA, run opendkim-genkey -s 2026a -d example.com -b 2048 -D /etc/opendkim/keys/example.com/. Update KeyTable to point to the new private key, restart opendkim, and follow steps 3-5 above for DNS.

Example

# Generate a 2048-bit DKIM key with OpenDKIM
opendkim-genkey -s 2026a -d example.com -b 2048 -D /etc/opendkim/keys/example.com/

# Result: 2026a.private (signing key) and 2026a.txt (DNS TXT record content)
cat /etc/opendkim/keys/example.com/2026a.txt

# Verify the published TXT record
dig +short TXT 2026a._domainkey.example.com

OpenDKIM key generation for self-hosted MTAs. ESP users use the dashboard-provided key instead.

Related fixes