DKIM Key Too Short: What It Means and How to Fix It

A weak DKIM key can break trust fast

If your DKIM key is 512 or 768 bits, fix it now. Under the current DKIM update in RFC 8301, RSA keys below 1024 bits must not be treated as valid signatures.

DKIM signs a message with a private key inside the service that sends your mail. The matching public key sits in DNS under a selector, such as selector1._domainkey.example.com. When Gmail, Outlook, or another receiver gets the message, it reads the DKIM-Signature header, looks at the d= domain and s= selector, fetches the DNS key, and checks whether the signed parts of the message still match.

A short key weakens that check. RFC 8301 says signers must use RSA keys of at least 1024 bits and should use at least 2048 bits. Google says mail sent to personal Gmail accounts needs a DKIM key of 1024 bits or longer, and recommends 2048 bits when your domain provider supports it.

Rotate the key, do not hand-edit it

The safe fix is to generate a new key in the system that signs the mail, publish the DNS record it gives you, then switch that system to the new selector.

• List every sender that uses your domain: Google Workspace, Microsoft 365, your email service provider, billing mail, support mail, and apps that send receipts, invites, alerts, or password resets.
• Open each sender's DKIM settings. Generate a 2048-bit RSA key when the option exists. Use rsa-sha256; RFC 8301 moved DKIM away from rsa-sha1.
• Publish the exact TXT or CNAME record from the provider. Long TXT records may be split into quoted chunks by the DNS host, but the full value must stay intact.
• Wait for DNS to publish, then enable or rotate DKIM in the sending service. Microsoft 365 commonly uses two CNAME selectors, so check both selectors during setup and rotation.
• Send a new test message. In the headers, look for dkim=pass, the expected d= domain, and the new s= selector.
• Keep the old selector in DNS while recent mail is still being rechecked or forwarded. Remove stale selectors after the new key has been stable.

If a provider only supports 1024-bit DKIM, it can still meet the common minimum. Ask for 2048-bit support before moving the stream, because the right choice depends on how important that mail is and how much control you have over the sender.

Check that DKIM passes DMARC

A longer key helps only when the signature passes and the signing domain lines up with the domain people see in the From address.

DMARC does not require both SPF and DKIM to pass. It passes when at least one of them passes and aligns with the visible From domain. For DKIM alignment, the d= domain must match the From domain or share the same organizational domain, unless you choose strict alignment. A message from billing@example.com can have dkim=pass for a vendor domain and still fail DMARC if SPF does not pass with alignment.

Publish DMARC at _dmarc.example.com. A common starting record is v=DMARC1; p=none; rua=mailto:dmarc@example.com. That lets you collect aggregate reports before enforcement. After every real sender passes and aligns, move toward p=quarantine or p=reject. Reports help find forgotten senders before a stricter policy blocks them.

SPF still matters. Keep one SPF TXT record for each sending domain or subdomain. Include only the services allowed to send for that domain, and stay within the RFC 7208 limit of 10 DNS lookups during SPF evaluation. Use ~all while you are still finding senders. Use -all only when you are confident the list is complete. Never use +all on a real sending domain.

Why mail can still land in spam

DKIM is one gate. Inbox placement also depends on reputation, complaints, message quality, authentication alignment, DNS, and past recipient behavior.

Google requires SPF or DKIM for all senders to Gmail, and SPF, DKIM, and DMARC for bulk senders. Google also says unauthenticated messages may be marked as spam or rejected. Microsoft has published similar rules for high-volume senders to Outlook.com, Hotmail.com, and Live.com accounts, including SPF, DKIM, and DMARC checks.

After you rotate DKIM, run a full domain check. Confirm MX records point to your real inbound provider. Check that sending IPs have forward and reverse DNS. Review major blocklists, but do not treat a clean blocklist check as proof of inbox delivery. Read DMARC reports to confirm your real mail is aligned. A free InboxRadar domain scorecard can read public DNS and flag weak DKIM, SPF, DMARC, MX, and blocklist issues in one pass.

Use the primary sources when a provider rule changes: RFC 6376 for DKIM, RFC 8301 for DKIM key sizes, RFC 7208 for SPF, RFC 7489 for DMARC, Google's sender guidelines, and Microsoft's sender guidance.