DKIM key is shorter than 1024 bits
The DKIM key is 1024 bits or shorter. Keys of that length are considered weak: they are within reach of a well-resourced attacker who could forge signatures that verify against your published key, and some receivers now discount or ignore signatures made with them. The fix is to rotate to a 2048-bit key, which every current platform supports.
Check your own domainDKIM checker
What causes this
RSA keys below 1024 bits are computationally feasible to break, which would let an attacker forge valid signatures for your domain. RFC 6376 requires verifiers to support 512 to 2048 bits, but modern receivers commonly refuse keys under 1024 outright.
What it breaks
Signatures may be treated as invalid, and a short key is a genuine forgery risk rather than a theoretical one.
What the receiving server does
A 1024-bit signature still verifies mathematically, so mail signed with one generally passes DKIM today. What changes is how much that pass is worth. Receivers increasingly treat key strength as a signal in its own right, and the industry has moved to 2048-bit as the minimum expectation. The risk being managed is forgery: if a key is factored, an attacker can produce signatures that verify against your domain, and DKIM stops distinguishing your mail from theirs.
Rotating without an outage
DKIM permits any number of selectors, and that is what makes rotation safe. Publish the new key alongside the old one, switch signing over, and only then remove the old record.
How to fix it
Rotate to a 2048-bit key.
- Generate a new 2048-bit DKIM key in your sending provider's console.
- Publish the new record at a new selector.
- Switch signing to the new selector.
- Revoke the old selector once no mail is signed with it.
If you send with
- Google Workspace
- The Admin console offers 1024 and 2048-bit keys, and older domains were often set up at 1024 because 2048 required DNS handling that some panels could not manage. Generate a new 2048-bit key, publish the record, and press Start authentication to switch signing over.
- Microsoft 365
- Microsoft issues 2048-bit keys and rotates them for you, provided you published the CNAMEs rather than static TXT records. A weak key here usually indicates a hand-entered TXT record from an older setup, which should be replaced with the CNAME pair.
Confirming the fix worked
- Generate a 2048-bit key at a new selector rather than replacing the existing record in place.
- Publish the new record and confirm it resolves before changing anything in the sending platform.
- Switch signing to the new selector, then send a test message and confirm the DKIM-Signature header shows the new selector.
- Leave the old record in place for a few days, then remove it.
Common questions
- Will a 1024-bit key stop working?
- Not abruptly. Signatures still verify, and most receivers still accept them. The direction is one way though: 2048 is the current expectation, and the practical risk is that a weak key can be forged rather than that it will be rejected.
- Can I rotate the key without breaking mail in transit?
- Yes, by publishing the new key at a new selector before switching. Messages already sent were signed with the old key and will be verified against the old record, which is why it should stay published until nothing is signing with it.
- Why were 1024-bit keys so common?
- Because a 2048-bit key does not fit in a single 255-character DNS TXT string, and many DNS panels historically could not split a record correctly. The shorter key avoided a formatting problem rather than reflecting a security judgement.
- How often should keys be rotated?
- Every six to twelve months is a reasonable cadence, and providers that manage keys through CNAMEs do it for you. The important thing is that rotation is possible and rehearsed, so a key can be replaced quickly if one is ever compromised.