What is the recommended key length for DKIM? I'm currently thinking about a 1024-bit key vs. a 2048-bit one.

From the crypto point of view for RSA, 2048 or 4096 bits is clearly recommended--no discussion on that point. Having glanced over various posts, it seems there may be some trouble at the mail or DNS level with keys of 2048-bit length.

Moreover, using 1024-bit keys seems to be the current trend.

Which key length is best for DKIM?

  • $\begingroup$ I'm not sure that page shows any conclusive trend. In 2013, 2k keys were clearly fewer than in 2016, but after that (latest page version is from 2020), the numbers vary from 8% to 54% from one month to the next, seemingly at random. Another page, <dmarc.org/stats/dkim>, is also rather variable (particularly the latest year, 2021), but also shows that 2k is getting more common. For what it's worth, I am newly setting up DKIM and a 4k key is not accepted ("dkim=permerror key too large") by the second receiving email server I tried :/ so 2k it is $\endgroup$
    – Luc
    Commented Aug 17, 2023 at 10:27

3 Answers 3


Nobody has publicly announced that they've broken 1024-bit RSA (other than via implementation defects that can happen with any key size), but it's not out of the question. I can't find a recent estimate, but when RSA-768 was broken in 2009, the researchers estimated that RSA-1024 would be “about a thousand times harder” and that there was “little doubt about the feasibility by the year 2020 of a matrix required for a 1024-bit NFS factorization”. So 1024-bit RSA should certainly not be used to encrypt confidential data or to authenticate arbitrary entities.

However, DKIM is somewhat less demanding than most cryptography applications. Your adversary is not NSA, it's spammers and scammers. On the scale of how much money they make, the cost of breaking 1024-bit RSA would be totally prohibitive. Furthermore, the impact of a broken key is detectable and correctable: if someone manages to break a legitimate key and makes use of that, there will be emails bearing those traces. This may cause temporary harm, but the key can be revoked. In practice, it's a lot more likely that an adversary would impersonate a legitimate participant by exploiting some misconfiguration of the server than by breaking the cryptography.

So 1024-bit RSA is fine for DKIM at the moment. However, attacks only ever get better. It's possible than an improvement to factoring techniques will make it slightly easier to break RSA, and will bring 1024-bit RSA from “NSA can break it if they really want” to “$10k on AWS”. So you should have an upgrade path ready, which you should always have when it comes to cryptography anyway. You should make sure that your system accepts 2048-bit keys, but it's ok to use a 1024-bit key for now.

  • $\begingroup$ But practically speaking, signing and signature verification is rarely a bottleneck in systems like this even if using large RSA keys. I'd say it's worth it to at least use 2048 bit keys. And then you don't need to suddenly switch keys if anybody shows up out of the blue announcing that they cracked 1024 bit keys. $\endgroup$
    – Natanael
    Commented Aug 2, 2019 at 18:21
  • 1
    $\begingroup$ Given the 255-char limit of a single, self-contained DNS TXT record, is there anything that precludes using a value higher than 1024, but lower than 2048, that would fit comfortably within that limit? For example, a 1246-bit key produces a 252-character TXT record. $\endgroup$ Commented Oct 20, 2020 at 20:22
  • 2
    $\begingroup$ @RoyceWilliams In principle, RSA can work with keys of any size (not even necessarily a whole number of bytes), but not all implementations support this. Most implementations support powers of 2 and often at least 3*2^n, so 1536 bits is widely supported. $\endgroup$ Commented Oct 21, 2020 at 11:12
  • 1
    $\begingroup$ @RoyceWilliams The solution being implemented is for DKIM to support Ed25519. $\endgroup$
    – Paul
    Commented Jan 18, 2022 at 0:30
  • 1
    $\begingroup$ @RoyceWilliams The OpenDKIM project added support for it in 2018 and dkimpy supports it. So popular tools support it, so that's something. I am a (very minor) contributor to Mail-in-a-Box, and I am going to submit for the upcoming migration to Jammy to support Ed25519 both signing and authenticating, if accepted that's >20k new, mostly small, servers adopting it. $\endgroup$
    – Paul
    Commented Jan 18, 2022 at 2:24


We use G Suite and our DNS is AWS.

Upgrading our DKIM from 1024 to 2048 caused a lot of e-mail, both internal and external, being labelled as spam.

I contacted Google and they suggested to lower the DKIM length to 1024.


  1. Because "[...] your DKIM record is pretty long to be used in your domain's DNS settings" (we use AWS, are you serious?)
  2. "[...]If your DKIM is not recognized properly then your outbound messages will not be authenticated properly [...] the recipient's server can get your messages as coming from unknown sources [...] Then the spam classification is triggered."

Therefore we ended up using 1024. We are in 2020 and G Suite has been sponsoring DKIM 2048 since 2016. But the problem was AWS which is using 1024-bit DKIM key by default.

CONCLUSION: You can use 1024 which is still fairly good or 2048 if you want to feel safer. Keep in mind that 1024 is still the standard and before you choose 1024 or 2048 check your DNS provider and see what length of DKIM key is supported because they need to match.

  • $\begingroup$ I had the same experience. GMail and most large mailing systems support 2048-bit keys just fine, but plenty of older ones are still failing to validate emails due to key length issues. $\endgroup$
    – mae
    Commented Jul 22, 2020 at 5:22

Bulk e-mail provider emarsys is using a 1024 bit key. It might be worth cracking, as they tell their clients to put their public key in the clients own DNS as a TXT record. And to only create one record. It is big companies that uses them.

All other mail providers tells customers who do not use their own keys, to create a CNAME to the providers, and tells customers to setup 2 selectors, so that they can change a key, and switch over to the secondary while they update the first. This allows them to mitigate away from breached keys in a week or so. emarsys can't do that. They need all their customers to update their TXT record, or at least create new CNAME records.

1024-bit is OK to use if you publish 2 selectors, if you sign for customers, then have the customers create CNAME records for both selectors. Then you can change in a week (or less - Not sure how long time you should give old mail to be delivered / verified).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.