Why defend DKIM key size and what key sizes do ESP's support?
Michael Ko
Co-founder & CEO, Suped
Published 24 Jul 2025
Updated 15 Aug 2025
6 min read
When you're dealing with email deliverability and security, the topic of DKIM key size often comes up. Many organizations adopt 1024-bit DKIM keys, which has been a standard for a long time. However, as security standards evolve, some customers or internal security teams might request larger key sizes, specifically 2048-bit keys.
This can lead to questions about why a particular key size is chosen, whether it's truly sufficient, and what capabilities email service providers (ESPs) offer in this regard. Understanding the cryptographic implications, the industry standards, and the practical aspects of implementation is essential for making informed decisions and addressing any concerns.
DKIM, or DomainKeys Identified Mail, is a critical email authentication standard that allows an organization to claim responsibility for transmitting a message. This process helps verify the sender's identity and detect any unauthorized changes to the email content during transit. At its core, DKIM relies on cryptographic key pairs to create digital signatures, with the public key published in your domain's DNS records.
The length of this cryptographic key, typically 1024-bit or 2048-bit, directly impacts the strength of the encryption. A longer key size generally means a more complex mathematical problem for an attacker to solve, thereby increasing security. The choice of key size is a balance between cryptographic strength and practical considerations like performance and DNS record limitations.
A 2048-bit DKIM key is considered a powerful security measure, offering enhanced protection against potential cryptographic attacks and impersonation. While 1024-bit keys have historically been sufficient, the move towards 2048-bit keys reflects an industry trend towards stronger encryption in response to evolving threat landscapes.
1024-bit vs. 2048-bit DKIM keys: a comparison
The debate between 1024-bit and 2048-bit DKIM keys is a frequent one in email security discussions. While 2048-bit keys offer theoretically stronger encryption, 1024-bit keys are not inherently insecure or deprecated for most current uses. There haven't been widely known successful collision attacks against 1024-bit DKIM keys in the wild, indicating they still provide a reasonable level of security for email authentication.
However, the perception of security is just as important as the reality. Many security audits and compliance frameworks now recommend or mandate larger key sizes for all cryptographic elements, including DKIM. This pushes organizations to adopt 2048-bit keys even if the immediate risk with 1024-bit keys is low. For a deeper dive into the technical details, you can explore the pros and cons of 1024-bit versus 2048-bit DKIM keys.
1024-bit DKIM keys
Security: Still considered cryptographically secure for current threats.
Performance: Slightly faster for signing and verification due to smaller key size.
DNS records: Typically fits within a single DNS TXT record string without issues.
Performance: Marginally slower verification, but negligible impact for most email systems.
DNS records: May require multiple DNS TXT record strings, increasing complexity.
While 2048-bit keys are widely accepted by internet service providers (ISPs), it's important to note that the immediate benefits in terms of email deliverability are often minimal if 1024-bit keys are already properly configured. The primary driver for larger keys is typically internal security policy or compliance rather than a direct deliverability improvement.
What email service providers support
The capabilities of email service providers (ESPs) regarding DKIM key sizes can vary significantly. Many ESPs, like SendGrid, have traditionally defaulted to 1024-bit keys, citing sufficient security for the vast majority of their users and ease of implementation. Some providers might offer 2048-bit keys as an option, often through API configurations rather than a direct UI setting.
For example, SparkPost supports 2048-bit keys, but their cloud sending default is 1024-bit, and the option to change it is often found in API documentation rather than the user interface. This highlights that while the underlying Mail Transfer Agents (MTAs) may support larger keys, integrating this into a scalable, user-friendly platform requires significant development effort for ESPs.
Other ESPs like Mailgun might explicitly offer 2048-bit as a straightforward option for cloud sending. If your customer requires 2048-bit keys and your current ESP doesn't seem to support it, it's worth checking their API documentation or directly contacting their support, as the option might be available but not immediately visible in the UI. Keep in mind that DNS provider limitations on TXT record length can also play a role, as longer keys might require multiple strings.
How to address customer concerns
When faced with a customer or internal stakeholder demanding 2048-bit DKIM keys, even if your ESP defaults to 1024-bit, the key is to manage expectations and provide clear, technically accurate information. First, confirm with your ESP if 2048-bit key support is available, even if it's via an API or a non-default setting. If it is, that resolves the issue directly.
If 2048-bit support isn't readily available, you can emphasize that 1024-bit DKIM keys are still considered secure by current standards and widely accepted by major email providers. Highlight that there are no known practical attacks against 1024-bit DKIM in the wild. You can also point to broader email authentication strategies, such as DMARC, which offers an additional layer of protection by instructing recipient servers on how to handle emails that fail SPF or DKIM checks. Understanding the relationship between DMARC, SPF, and DKIM can further strengthen your argument.
Ultimately, the discussion should center on risk assessment and practical implementation. While 2048-bit keys are preferable for long-term cryptographic strength, the operational complexities and the lack of immediate, widespread threats to 1024-bit DKIM should be part of the conversation. Focus on the overall email security posture rather than fixating on a single component.
Views from the trenches
Best practices
Always check your ESP's API documentation for hidden DKIM key size options.
Prioritize overall email authentication (SPF, DKIM, DMARC) over just key size.
Implement DMARC with a strong policy to mitigate risks even with 1024-bit keys.
Common pitfalls
Assuming your ESP doesn't support 2048-bit keys without thorough investigation.
Over-emphasizing key size when other authentication mechanisms are weak or missing.
Neglecting to explain the real-world impact (or lack thereof) of different key sizes.
Expert tips
A 2048-bit key might require multiple DNS TXT record strings, potentially increasing DNS lookup errors.
While 2048-bit is theoretically stronger, 1024-bit DKIM keys haven't seen successful collision attacks.
Consider the broader software platform and UI updates required for ESPs to support larger keys at scale.
Marketer view
Marketer from Email Geeks says that if an ESP's cloud sending only supports 1024-bit keys, and 2048-bit is an on-premise feature, it's often a hidden API parameter.
2020-09-30 - Email Geeks
Expert view
Expert from Email Geeks says that 1024-bit DKIM isn't deprecated, and there are no known collision attacks against it. Larger keys might introduce DNS record splitting issues.
2020-09-30 - Email Geeks
Summary of key sizes and ESP support
Understanding DKIM key sizes, their implications for security and deliverability, and what your ESP offers is crucial for maintaining a robust email program. While 2048-bit keys represent a stronger cryptographic standard, 1024-bit keys remain widely accepted and secure for current email authentication practices.
The key is to have a comprehensive email authentication strategy that includes SPF, DKIM, and DMARC, rather than focusing solely on key length. By communicating clearly with stakeholders and leveraging all available tools, you can ensure your email program is both secure and effective.
SendGrid, have traditionally defaulted to 1024-bit keys, citing sufficient security for the vast majority of their users and ease of implementation. Some providers might offer 2048-bit keys as an option, often through API configurations rather than a direct UI setting.
SparkPost supports 2048-bit keys, but their cloud sending default is 1024-bit, and the option to change it is often found in API documentation rather than the user interface. This highlights that while the underlying Mail Transfer Agents (MTAs) may support larger keys, integrating this into a scalable, user-friendly platform requires significant development effort for ESPs.
Mailgun might explicitly offer 2048-bit as a straightforward option for cloud sending. If your customer requires 2048-bit keys and your current ESP doesn't seem to support it, it's worth checking their API documentation or directly contacting their support, as the option might be available but not immediately visible in the UI. Keep in mind that DNS provider limitations on TXT record length can also play a role, as longer keys might require multiple strings.
