The recommendation to migrate DKIM signing from 1024-bit to 2048-bit RSA keys has been in industry guidance for over five years. NIST, M3AAWG, and various email infrastructure standards bodies recommend 2048-bit as the current minimum for new deployments. Older 1024-bit keys are technically still supported but increasingly viewed as inadequate.
Despite the recommendation, 1024-bit DKIM keys remain widely deployed. Many senders configured their authentication years ago and never migrated. The migration was not strictly required by receivers. The path of least resistance was to leave existing configurations alone.
We completed the migration of our entire customer base from 1024-bit to 2048-bit DKIM keys in early 2026. The migration covered approximately 280 customer accounts and 450+ sending domains. The work took 16 weeks of coordinated effort. The customer impact was minimal but real.
This post documents what the migration involved, what we learned, and what other operators should consider about similar migrations.
Why migrate
The reasons for migrating 1024-bit DKIM to 2048-bit:
Cryptographic strength
1024-bit RSA keys are considered marginal for current cryptographic standards. While not immediately breakable, the security margin is narrowing as computational capacity grows.
2048-bit keys provide significant additional security margin. The increased margin protects against accelerating computational capacity, including potential quantum computing advances.
Receiver-side trends
Some receivers have started preferring 2048-bit signatures over 1024-bit. The preference is not yet enforced as a hard requirement but trends toward eventual enforcement.
Receivers that have implemented preference but not requirement still produce subtle reputation differences. Senders with 2048-bit keys may see slightly better reputation outcomes than equivalent senders with 1024-bit keys.
Standards compliance
Industry standards bodies (M3AAWG, NIST) recommend 2048-bit as the minimum for new deployments. Operators wanting to align with current best practices have reason to migrate.
Risk reduction
The cryptographic security of mail authentication is foundational to deliverability. Maintaining strong cryptography reduces the risk that future cryptographic developments would require emergency migration.
Forward compatibility
Future receiver-side requirements may eventually require 2048-bit minimum. Operators who have already migrated will not face that future enforcement event.
Why the migration is not trivial
Despite being a simple-sounding change (replace one key with a longer key), the migration involves several considerations.
DNS record size constraints
DKIM public keys are published in DNS TXT records. 1024-bit keys produce TXT records of approximately 200 characters. 2048-bit keys produce records of approximately 400 characters.
The 400-character size exceeds single TXT record limits in some DNS systems. The records require splitting into multiple TXT strings within a single record, which most DNS providers handle but some do not.
Transitional state management
DKIM signing changes require coordination. The new key must be published in DNS before signing starts using it. The old key must remain published until any in-flight mail signed with it is delivered.
The transitional state typically involves several days of dual-key operation. Both keys are valid for the transition period.
Operational coordination
For multi-tenant operations like ours, the migration affects many customers. Each customer’s migration must be coordinated. Customer-specific schedules, customer-specific authentication setups, customer-specific volume patterns all need consideration.
The coordination is more substantial than the technical work.
Verification and validation
After migration, the new keys need verification. Authentication must continue passing. DMARC alignment must hold. Receiver acceptance must continue.
The verification process catches issues that emerge from the change.
Customer communication
Customers need to know about the migration. Even though the operational impact is minimal, customers prefer to be informed about changes to their authentication infrastructure.
The communication discipline is part of the migration work.
Our migration approach
Our 16-week migration followed a structured approach.
Phase 1: Planning and preparation (weeks 1-2)
Inventory of all customer accounts and DKIM keys. The inventory covered:
Customer accounts (approximately 280) Sending domains per customer (1-15 domains per customer) DKIM selectors in use per domain (1-4 selectors typical) Current key lengths (predominantly 1024-bit) Sending volume per domain Customer engagement level (active vs less active)
The inventory provided the scope of the migration work.
Customer prioritization. Customers with highest volume and most active operations were prioritized for early migration to manage risk. Less active customers were prioritized later.
Customer communication preparation. Templates for customer notification about the upcoming migration were developed.
Technical preparation. Internal tooling for key generation, DNS publication, and signing configuration updates was reviewed and improved where needed.
Phase 2: Pilot migration (weeks 3-4)
Migration of our own infrastructure first. The ASH brand domains were migrated to verify the procedure worked. The pilot identified several minor improvements to the procedure.
Migration of 5 customer accounts who volunteered for early migration. The 5 customers had varied profiles (different volumes, different content, different infrastructure). The migrations completed successfully with no customer impact.
Lessons captured from the pilot informed the broader rollout procedure.
Phase 3: Active migration (weeks 5-13)
Migration proceeded in batches. Each batch of approximately 25-30 customer accounts was migrated over a 1-week period.
The weekly cadence allowed:
- Monday: customer notification and key generation
- Tuesday-Wednesday: DNS publication and propagation verification
- Thursday: signing configuration update
- Friday: verification and stabilization
The pattern repeated for 9 weeks covering all remaining customer accounts.
Each batch’s migration was monitored for issues. Issues identified in one batch informed adjustments for subsequent batches.
Phase 4: Cleanup (weeks 14-15)
Old keys were retired from DNS. The 1024-bit keys had been left in DNS during the transition for backward compatibility. Cleanup removed them.
The cleanup was straightforward but required verification that no mail was still being signed with old keys (which would produce authentication failures after removal).
Phase 5: Documentation (week 16)
Documentation updates to reflect the new infrastructure state. Operational procedures updated to reflect 2048-bit as standard. Customer documentation updated.
The documentation work consolidated learning from the migration.
What we learned during the migration
The migration produced specific learnings.
DNS provider variability
Different DNS providers handled the larger TXT records differently. Some accepted the records as-is. Some required specific syntax for multi-string records. Some had bugs that produced incorrect record serving.
We documented per-provider handling. Customers using specific providers received provider-specific guidance.
Customer DNS access patterns
Some customers had direct DNS access; we could publish records ourselves. Others required them to publish records through their DNS provider. The latter required more coordination time and produced more variability in timing.
For customers without direct DNS access, the migration timeline depended on customer responsiveness for the DNS update step.
Key generation variability
Different DKIM signing implementations had different syntax for using new keys. PowerMTA, Postfix with OpenDKIM, Postal all use slightly different configuration patterns.
We had documented procedures for each implementation. The documentation made the rollout smoother.
Receiver behavior variability
Most receivers accepted the new keys without issue. A small percentage produced authentication issues during the transition window where both keys were valid.
The issues resolved within hours as receivers refreshed their DNS caching. The minor turbulence was operationally acceptable.
Customer engagement variability
Some customers actively engaged with the migration (reviewing announcements, asking questions, verifying outcomes). Others were essentially passive (their mail continued working; they did not engage with the process).
Both patterns are acceptable. The customers who engaged required slightly more support time. The customers who did not engage produced no support load.
Specific edge cases
Several specific edge cases emerged during the migration:
A customer with very old DKIM selectors had records that did not migrate cleanly due to DNS issues from years prior. The migration revealed the issues; cleanup of the old configuration was bounded but real.
A customer with DKIM key rotation automation needed special handling because their automation conflicted with our migration process. Coordination resolved the conflict.
A customer with very large DKIM records (above 400 characters) due to additional parameters needed careful handling for the new record. The technical work was straightforward but required attention.
These edge cases produced approximately 2% of the migration time despite affecting only a few customers. The customer-specific handling was operationally necessary.
What did not happen
Several concerns about the migration did not materialize.
Mass deliverability degradation
We worried about whether the migration would produce deliverability issues. The migration produced essentially no measurable deliverability impact across customer base. Mail continued delivering as before.
Significant customer disruption
We worried about whether customers would experience significant disruption. The vast majority of customers experienced no operational issues. A few customers had minor questions that were resolved with brief communication.
Receiver-side issues
We worried about whether some receivers would have issues with the larger keys. Receivers handled the migration smoothly. Authentication continued passing across receivers.
Time overruns
We worried about whether the 16-week timeline would extend. The timeline held closely; the migration completed approximately on schedule.
Cost overruns
We worried about whether the migration would cost more than budgeted. The cost was bounded; the actual investment matched the planning estimates closely.
What the migration produced
Beyond the immediate technical change:
Improved authentication posture
All customer DKIM signatures are now 2048-bit. The cryptographic foundation of our customer infrastructure is current with best practices.
Reduced future migration risk
The eventual receiver requirement for 2048-bit DKIM (if it comes) will not be a forcing function for emergency migration. Our customers are already compliant.
Improved documentation
The migration produced updated documentation that supports future operational activities. The investment in documentation discipline has compounding value.
Customer trust building
Customers saw us conduct a substantial infrastructure migration smoothly. The demonstration of operational capability builds trust for future operational needs.
Team capability building
The migration exercised our team’s coordination capability across many customers simultaneously. The team capability is strengthened for future migrations or coordinated activities.
Internal procedure refinement
The procedures developed for this migration improve our overall operational discipline. Similar future migrations will benefit from the procedural learning.
What other operators should consider
For other operators considering similar migrations:
Plan for the duration
Migration of many customer accounts takes time. The technical work per customer is bounded but the coordination, customer communication, and verification time accumulates.
Plan for weeks or months for substantial migrations. Compressed timelines produce mistakes.
Communicate proactively
Customers benefit from knowing what is happening with their infrastructure. Proactive communication builds trust and reduces support load during the migration.
Document procedures carefully
The procedures developed for migration are operational assets. Document them in detail. Future migrations or related work benefit from documented procedures.
Verify outcomes carefully
Migration verification matters. Confirm authentication continues passing. Confirm DMARC alignment holds. Confirm deliverability continues. The verification work catches issues early.
Plan for the transition state
The transitional state where both old and new keys are valid requires careful management. Plan the transition timing carefully.
Accept some operational variability
Customer DNS providers vary. Customer engagement patterns vary. Customer technical implementations vary. Accept the variability rather than expecting uniformity.
Use the migration for related improvements
Migration activities often surface related issues. Use the opportunity to address other deferred operational improvements.
What we recommend to senders not yet migrated
For senders still operating with 1024-bit DKIM keys:
Plan migration for 2026
The migration is overdue based on industry standards. Senders should plan migration to 2048-bit during 2026 if not already done.
Use the migration timing appropriately
The migration is straightforward but not instantaneous. Plan for the work rather than treating it as a quick task.
Coordinate with infrastructure providers
If using managed services, work with the provider on migration timing. The provider may have procedures that support smooth migration.
Verify after migration
Confirm authentication continues passing. Run test sends. Check DMARC reports. The verification catches issues early.
Document the new configuration
The new configuration is operational asset. Document it for future reference and operational continuity.
Watch for receiver-side feedback
If receivers indicate authentication issues post-migration, investigate quickly. Most receivers handle migrations smoothly; the small percentage with issues need attention.
What we expect going forward
Looking at DKIM cryptographic evolution:
2048-bit as standard for years
2048-bit is expected to remain the standard for the foreseeable future. The cryptographic margin is sufficient for current threats.
Eventual move toward 4096-bit
Industry standards may eventually move toward 4096-bit or even longer keys. The timing is uncertain but trends toward longer keys are likely.
Quantum-resistant alternatives
Eventually, cryptographic algorithms that are resistant to quantum computing attacks may become relevant. The timing is uncertain; current quantum systems are far from threatening RSA at 2048-bit.
The transition to post-quantum cryptography is a future consideration for email infrastructure. The transition will require coordinated industry action.
Ed25519 alternatives
Some implementations support Ed25519 (elliptic curve) signatures as alternatives to RSA. The performance characteristics differ; the security characteristics are comparable.
For specific use cases, Ed25519 may emerge as alternative to RSA-2048. The current state is RSA-dominant; transitions may occur over time.
Receiver behavior evolution
Receivers may begin preferring or eventually requiring specific cryptographic standards. The trend is toward stronger cryptography rather than weaker. Senders maintaining current standards are positioned well.
The broader pattern this reflects
The DKIM 2048-bit migration reflects broader patterns in email infrastructure.
Ongoing operational discipline
Email infrastructure requires ongoing operational work. Authentication setup is not one-time configuration. Cryptographic standards evolve. Sender practices need to evolve correspondingly.
Industry standards as forcing function
Industry standards bodies produce recommendations that eventually become practical requirements. Senders staying current with standards face less disruption than senders who fall behind and need to catch up under time pressure.
Cumulative investment
The investment in proper email infrastructure compounds over time. Each operational improvement builds on previous improvements. The cumulative discipline produces sustainable operations.
Customer relationships through operational quality
Customers who experience smooth operational migrations develop trust. The trust supports future operational needs and ongoing customer relationships.
Documentation as operational asset
Operational documentation is asset that supports future work. Investment in documentation discipline pays back across many future activities.
The honest summary
The DKIM 2048-bit migration was operationally substantial but bounded. The 16-week timeline reflected the scope. The customer impact was minimal. The operational improvements are real.
For operators considering similar migrations: the work is achievable. The planning and execution discipline matters. The customer relationships benefit from professional execution.
For senders not yet migrated: the work is overdue. Plan migration during 2026. The technical work is bounded; the coordination work is more substantial but manageable.
For our customer base: the migration is complete. Mail continues delivering as before with improved cryptographic foundation. The future receiver enforcement event (if it comes) will not be a forcing function for our operations.
For our team: the migration exercise built capability and refined procedures. The investment supports future operational work across many dimensions.
The broader pattern continues: email infrastructure requires ongoing operational discipline. Specific elements (authentication, list quality, content quality, infrastructure maintenance) all need continuous attention. The cumulative work produces sustainable operations.
The 1024-bit DKIM era is ending across our customer base. The 2048-bit era continues. The next cryptographic transition (whatever it may be) will come eventually. The discipline that produced this migration prepares us for that future work.
Customers who experienced the migration smoothly continue with us. The operational quality demonstrated through the migration reinforces ongoing relationships. The work continues; the customers continue benefiting; the team continues building capability.
For other operators reading this: the patterns are generalizable. Plan migrations carefully. Communicate with customers proactively. Verify outcomes thoroughly. Document procedures comprehensively. The cumulative discipline produces sustainable infrastructure that serves customers well over years rather than just during specific moments.