Blog · Dkim
Can I Use 1024-Bit DKIM Keys? Security Risks, Vendor Constraints, and Your Real Options
You have everything set up correctly. SPF is tight. DMARC is at p=reject. Your DKIM record uses a 2048-bit RSA key. Then a vendor - an old ERP system, a third-party sending platform, an internal tool you cannot replace - tells you they only understand 1024-bit DKIM.
What do you do?
This is not a hypothetical. It is a common problem in enterprise email environments. And "just use 2048-bit" is not a useful answer when your vendor literally cannot generate one.
This article gives you an honest framework: what is actually risky about 1024-bit DKIM, what the standards say, and the realistic options available to you.
What is the actual risk?
DKIM uses RSA signatures. Larger RSA keys are harder to factor. A 1024-bit RSA key has been considered cryptographically weak for serious security work since the early 2000s, when researchers demonstrated that 512-bit RSA could be factored with modest computational resources. That work has only improved since. A determined attacker with access to sufficient computing resources can factor a 1024-bit key.
The practical consequence: if someone factors your 1024-bit DKIM private key, they can generate valid DKIM signatures for your domain. Those forged emails pass DKIM validation. Your DMARC policy provides a secondary check - but the attacker has bypassed your primary authentication mechanism.
This is not alarmism. RSA-1024 has been factored in academic and controlled settings. Major receivers (Google, Microsoft) have been progressively tightening which key sizes they accept. The direction of travel is clear: 1024-bit DKIM is being phased out.
What the standards say about key sizes
The original DKIM specification, RFC 6376 (2011), set 1024-bit as the minimum key size and recommended 2048-bit.
RFC 8301 (January 2018) - titled "Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail" - changed this significantly. Its abstract describes the original DKIM cryptographic requirements as "functionally obsolete and in need of immediate revision." The 2018 update strongly recommends 2048-bit RSA and marks 1024-bit as deprecated for new deployments.
The summary: 1024-bit DKIM is not a current best practice. You are not catastrophically wrong to run it today - but you are on the wrong side of a clear standards trajectory. Treat it as a known gap with a plan to close it.
Your options when 1024-bit is your only choice
Use 1024-bit as a temporary bridge
If a vendor is genuinely immovable in the short term and your threat environment is not high-risk, using a 1024-bit DKIM key for that specific sending path while you push for an upgrade is a defensible position. It is not ideal. It is not permanent. But sometimes "perfect" is the enemy of "working."
Document the limitation. Set a review date. Engage the vendor on an upgrade path.
Run two DKIM selectors at the same time
Many email receivers accept multiple DKIM signatures. If you publish two selectors - your 2048-bit key and the vendor's 1024-bit key - receivers that support DKIM generally validate the strongest key they can process. Your primary sending systems use the 2048-bit selector. The vendor uses 1024-bit.
The catch: both keys must share the same domain and DMARC alignment. Not all receivers handle multi-selector setups gracefully. You also now have two keys to manage, two DNS records to keep current, and two potential failure points. This works best as a temporary bridge, not a permanent architecture.
Push the vendor to upgrade
This is the right long-term answer in most cases. A vendor that has not updated DKIM key generation to at least 2048-bit is behind the current standard - and likely behind on other email security gaps too.
Frame the request in terms the vendor understands. Google and Microsoft are restricting 1024-bit DKIM acceptance in some contexts. RFC 8301 explicitly marks 1024-bit as deprecated. If their email deliverability depends on DKIM validation - and it does - they have a business problem if they do not change. Point them to the RFC 8301 abstract, which calls the original DKIM crypto requirements "functionally obsolete."
Give them a realistic timeline: enterprise vendors typically need 6 to 18 months to update DKIM key generation and testing. Start the conversation now.
Route through a re-signing proxy
A DMARC-aware email gateway or forwarding service can re-sign mail on your behalf. The vendor sends to the proxy. The proxy re-signs with your 2048-bit DKIM key and forwards to the destination. Your DKIM signature is clean. The vendor never touches your DNS record. DMARC alignment is preserved.
This is the right choice when the vendor is genuinely immovable and their current setup creates unacceptable risk. The tradeoff is added infrastructure, potential latency, and operational complexity. It solves the problem but does not remove it.
Isolate vendor mail under a subdomain
If the vendor's email can be separated from your primary sending domain - for example, a vendor portal that sends from a dedicated subdomain - publish a separate DMARC policy for that subdomain. Even if the subdomain uses 1024-bit DKIM, a compromise of that key does not affect your main domain's p=reject policy.
This only works when the vendor's mail is clearly separable from your primary sending. It adds DNS and policy management overhead, but limits the blast radius of a key compromise.
Which option should you choose?
| Situation | Approach |
|---|---|
| Vendor cannot change in under 6 months, low threat environment | Use 1024-bit as bridge while pushing vendor |
| Vendor upgrade is achievable but takes time | Dual DKIM selectors as temporary bridge |
| Vendor is immovable, risk is unacceptable | Re-signing proxy or gateway |
| Vendor mail is clearly separable | Subdomain isolation with separate DMARC policy |
No single answer is right for everyone. What matters is making an informed, documented decision with a plan to move off 1024-bit DKIM. Leaving it running indefinitely without review is not an acceptable option when the standards community has already declared it deprecated.
How to monitor this risk with DMARC reports
Even with a Most aggregate reports do not break down DKIM pass rates by key size. What they do show is whether your DKIM signatures are validating at specific receivers - and whether that validation rate changes suddenly. If a major receiver tightens its key size requirements and your DKIM pass rate drops, you need to know immediately.
For teams managing multiple DKIM keys across vendors - exactly the situation when one vendor requires 1024-bit while the rest use 2048-bit - aggregate report monitoring is the only way to catch problems before they become delivery failures.
The re-signing proxy approach or DMARC-aware gateway above solves the key size problem at the infrastructure level, but you still need to verify that all your selectors are validating correctly and that your plan to retire 1024-bit is actually working.
The bottom line
1024-bit DKIM is not a crisis today. But it is not fine indefinitely, and it is not fine without a plan.
The practical path: understand the real risk, pick the option that fits your situation, and work toward a future where 1024-bit is gone from your DNS. Use 1024-bit as a bridge, not a destination. Set a review date. Engage your vendor. Monitor your aggregate reports.
The email security community is right to want 1024-bit RSA gone from production DKIM deployments. RFC 8301 called the original requirements functionally obsolete in 2018. But not every organization can simply replace a vendor over key size. What you can do is make an informed decision with a plan - and start moving toward the right answer now.
Frequently asked questions
Is 1024-bit DKIM safe?
No, by modern cryptographic standards. RFC 8301 deprecates 1024-bit RSA for DKIM, and major receivers are progressively restricting it. It is acceptable as a temporary bridge measure while you work toward an upgrade, but it is not a permanent solution.
What does RFC 8301 say about DKIM key sizes?
RFC 8301 (2018) strongly recommends 2048-bit RSA for DKIM and explicitly marks 1024-bit as deprecated for new deployments. The RFC abstract describes the original DKIM cryptographic requirements as "functionally obsolete and in need of immediate revision."
Can I use two DKIM records with different key sizes?
Yes. You can publish two DKIM selectors under the same domain - one with 2048-bit, one with 1024-bit. Receivers generally validate the strongest key they can process. Both keys must maintain the same domain and DMARC alignment to avoid authentication failures.
How do I convince a vendor to upgrade their DKIM key size?
Show them that Google and Microsoft are restricting 1024-bit acceptance. Point them to RFC 8301's deprecation. Frame it as a deliverability risk - if their DKIM signatures are rejected by major receivers, their email does not get through. Give them a realistic timeline and start the conversation now.
What happens if a 1024-bit DKIM key is factored?
An attacker who factors your 1024-bit DKIM private key can forge valid DKIM signatures for your domain. Those forged emails pass DKIM validation. Your DMARC policy provides a secondary check - but the attacker has bypassed your primary authentication mechanism.