Migrating RSA DKIM to Ed25519

Why You Should Migrate from RSA DKIM to Ed25519 in 2026

You’re sending 100,000+ emails a day. Your DKIM signature is still RSA-based. It works — for now. But you’re relying on a legacy system that mail providers are quietly deprecating. Every day you delay, you’re increasing the risk of deliverability drift, even if your content is clean and your authentication is technically correct.

Think of your DKIM key like an old car engine: it still runs, but it’s heavier, slower, and using outdated fuel. Ed25519 is the upgrade — smaller, faster, and built for modern scale. Migrating from RSA DKIM to Ed25519 isn’t just a technical chore. It’s a necessary step to maintain trust, performance, and inbox placement in 2026 and beyond.

Key takeaways

Transitioning from RSA DKIM to Ed25519 reduces signing latency by up to 60% for high-volume senders, improving delivery speed and consistency.
Ed25519’s smaller key size (256 bits vs. 2048+ bits for RSA) reduces DNS record load and improves DNS performance at scale.
Major email providers are beginning to prioritize cryptographic strength; delaying migration increases risk of reduced trust signals even with valid authentication.

How Does DKIM Migration Impact Sender Reputation?

Switching from legacy RSA DKIM to Ed25519 can hurt sender reputation if done poorly—any signature mismatch, expired key, or transition gap risks being flagged as instability by ISPs. Even a brief failure during migration may trigger spam filters, delay delivery, or damage trust signals. The key is maintaining consistent authentication and avoiding any break in the chain. Proper preparation and real-time verification are essential.

Authentication Consistency Is Non-Negotiable

Sender reputation isn’t built on a single metric—it’s a mix of authentication reliability, low bounce rates, and consistent sending behavior. Receiving providers like Gmail and Outlook watch for anomalies. A single DKIM signature failure during migration can appear as a red flag, especially if it coincides with high volume or rapid key changes.

Let’s be clear: even a few seconds of invalid authentication can be enough for some filters to treat the sender as unreliable. This isn’t theoretical—spammers often use short-lived keys, and ISPs are trained to detect abrupt changes. Your migration must not look like a sign of poor infrastructure.

Migration Risks Are Real, But Manageable

During transition, you might have dual signing (RSA + Ed25519) for a short period. This is safe—major providers accept both if properly configured. But if one key fails, the system may reject the email. That’s why testing is critical.

Test your signature chain before going live. Use real email addresses to simulate sending. You can verify your DKIM setup with tools like MxToolbox or RFC 6376 validation checks—both are industry-standard references. But for scale and speed, a real-time verification API is better. With MailTester’s API, you can check thousands of addresses for valid DKIM signatures in minutes, including detecting mismatches or invalid domains.

Don’t assume your mailing list is clean. Bounces, invalid addresses, or typoed domains often hide in legacy data. Before migration, use bulk verification to prune. MailTester’s list verification helps confirm addresses are valid and authenticated, reducing stress on the transition.

What the Primary Keyword Really Means: Migrating RSA DKIM to Ed25519 Without Affecting Sender Reputation

You’re replacing an older RSA-based DKIM signature with Ed25519 to future-proof your email infrastructure, but you must do it without triggering bounces, spam filters, or inbox placement drops — meaning sender reputation stays intact. This isn’t just a tech swap; it’s a precision migration that demands dual-signing, careful timing, and inbox validation to maintain trust.

Why the Migration Matters

RSA-based DKIM is aging. Ed25519 offers faster signing, smaller key sizes, and better security — a step forward for long-term deliverability. But switching blindly risks misaligned signatures, which mail servers flag as suspicious. That’s why you can’t just switch overnight.

According to RFC 8941, Ed25519 is specified as an acceptable signature algorithm for DKIM, so it's not experimental. Major providers like Google and Microsoft already accept it, but not all systems recognize it immediately. A sudden switch breaks trust — even if valid — because receiving servers may reject unknown algorithms during a transition.

How to Do It Right: Timing, Dual-Signing, and Validation

Let’s be clear: you don’t drop RSA and jump to Ed25519 in one move. You enable dual-signing — both algorithms active in parallel. That way, regardless of the receiver’s capability, your message is verified. This is how you avoid delivery breaks during the window.

Once dual-signing is live, gradually phase out RSA. Monitor bounce rates, spam complaints, and inbox placement closely. Use tools like inbox placement testing to validate real-world delivery in Gmail, Outlook, and other major inboxes before finalizing the change.

You’re not just maintaining sender reputation — you’re ensuring it remains consistent. A single spike in bounces or rejections can hurt your reputation for months. That’s why verification is key. Use bulk verification to clean stale or invalid addresses before migration, ensuring your list is strong from the start.

Think of it like upgrading a transmission in a moving car — you can’t stop and swap it mid-drive. You need to run both systems until the new one is proven. Only then do you disengage the old. That’s the core of doing it without affecting sender reputation.

Step 1: Audit Your Current DKIM Configuration

You need to extract your existing DKIM DNS record using tools like MxToolbox or dig, confirm it uses an RSA key (look for rsa-sha256 in the selector), and note the selector name, key size (e.g., 2048-bit), and any known expiration. Validate that all sending sources — internal IPs, SendGrid, HubSpot, etc. — are configured to use this same selector. Skipping this step risks breaking email authentication, triggering bounces, and harming sender reputation.

Start with DNS Discovery

Use MxToolbox’s DNS Lookup or the command-line dig TXT _domainkey.yourdomain.com to retrieve your current DKIM record. This reveals your selector and algorithm.
Check the record’s algorithms field. If it says rsa-sha256, you're using an RSA key. This is the common configuration in legacy setups, but not future-proof.
Record the selector name (e.g., default, 2023, or mail). You’ll need this to configure Ed25519 later.
Note the key size — usually 1024-bit, 2048-bit, or 4096-bit. The larger the key, the more processing overhead, especially with RSA.
If available, check the record’s expiration date (typically found in the expires field). This helps you plan your transition before renewal.

Verify Sending Sources and Third Parties

Review your email infrastructure. List all IPs, domains, and platforms (SendGrid, HubSpot, Mailchimp) that send on your behalf.
Confirm each uses the same selector. If third-party systems use different selectors or aren’t aligned, you’ll have misaligned authentication and potential message rejection.
For platforms like SendGrid or HubSpot, check their admin interfaces or support dashboards to see which selector they’re tied to. Reconfigure if needed to match your current record.
Run a real-time email test using MailTester’s inbox placement tool to validate that your current DKIM setup passes authentication checks across major inboxes (Gmail, Outlook, Apple).
Use the API email verification to validate a sample of your domain’s email addresses and ensure they’re not flagged as invalid or catch-all — anomalies here can signal broader deliverability risks during migration.

When you’re done auditing, you’ll have a full map of your current DKIM state. This clarity prevents misconfiguration during the Ed25519 migration. Don’t assume third-party tools are synced — verify it. The goal is zero change to deliverability while upgrading security.

Step 2: Generate a New Ed25519 DKIM Key Pair

You generate a new Ed25519 DKIM key pair using a trusted tool like OpenSSL with openssl genpkey -algorithm Ed25519. Choose a unique selector like ed2026._domainkey.yourdomain.com and never reuse old key material. Keep the private key secure—never store it in logs, config files, or public repositories. This step ensures cryptographic freshness, which is critical to maintaining sender reputation during migration.

Use a Trusted Tool for Key Generation

Run openssl genpkey -algorithm Ed25519 in a secure environment. OpenSSL is widely accepted and vetted by the cryptographic community, including the IETF, which defines standards for digital signatures in RFC 8032.
Save the output privately. The generated key pair includes a private key and a public key. Only the public key is added to your DNS records.
Navigate to your domain’s DNS management. Add a new TXT record using the selector name (e.g., ed2026._domainkey.yourdomain.com) and paste the public key value as specified by OpenSSL.

Secure Key Handling and Selectors

Let’s be clear: do not repurpose an existing key or rename an old one. Each DKIM key should be unique. Reusing keys—even accidentally—can signal inconsistent practices to receivers, potentially triggering reputation checks.

The 3 steps described in “Use a Trusted Tool for Key Generation”, in order.

Use a forward-looking, versioned selector like ed2026._domainkey.yourdomain.com. This makes tracking easier and avoids conflicts during dual-signing periods.

Store the private key in a password-protected vault or secure key management system. Never expose it in logs, config files, or code repositories, even in encrypted form. If a private key leaks, revoke it immediately and replace it.

Before finalizing the DNS record, verify the configuration using tools like MXToolbox or Apple’s DNS-SD documentation for correctness. Misconfigured DNS records nullify the security benefit.

After deployment, test deliverability and inbox placement with a real-world tool like MailTester’s Inbox Placement Test. This simulates end-user inboxes across major providers and helps confirm that your migration hasn’t triggered filtering.

Step 3: Configure Dual Signing During Migration

You can preserve sender reputation during the RSA to Ed25519 DKIM migration by configuring your email infrastructure—MTA, relay, and ESP—to apply both RSA and Ed25519 signatures simultaneously for a grace period. This dual signing ensures receiving servers can validate the email using either key, avoiding delivery failures during transition.

Enable Dual Signature Generation

Update your MTA or ESP to generate both RSA and Ed25519 signatures on outgoing messages. This requires support in your mail transfer agent and proper key management. Most modern ESPs and MTAs like Postfix, Exim, and Amazon SES support this configuration. You’re not replacing RSA; you're adding Ed25519 alongside it.

Let’s say your system sends 10,000 emails per day. During the migration, those 10,000 messages will carry two DKIM signatures—one with the old RSA key, one with the new Ed25519 key. No change in message content, just two cryptographic proofs. This maintains compatibility with older receivers still relying on RSA while enabling new ones to use Ed25519.

Verify Signature Publication and Validation

Ensure both DKIM DNS records are published and accessible. Use tools like DKIM Validator or MxToolbox to test that both signatures pass validation. Check the DNS TXT record for your DKIM selector, and confirm it includes both the RSA and Ed25519 public keys.

Receiving servers that support multiple DKIM keys will accept either signature. Those that only support RSA won’t block delivery. Those that support Ed25519 can verify the newer key. This avoids any disruption in delivery or inbox placement—critical for maintaining sender reputation.

Monitor authentication logs during this period. Look for DKIM failures, especially from large providers like Gmail or Outlook. If a failure appears, validate the key placement and alignment (DKIM, SPF, and domain). A mismatch in domain or header alignment will break DKIM even with correct keys.

When you’re confident the new signature works consistently across major inboxes, you can phase out the RSA key. But only after you’ve tested using tools like MailTester’s inbox placement tester, which shows how your emails land in real inboxes—Gmail, Outlook, Yahoo—before committing to full rollout.

Dual signing isn’t a permanent fix. It’s a buffer. But it’s the only safe way to migrate without risking inbox placement or reputation. It’s how we do it at scale—without breaking a beat.

Step 4: Publish the New Ed25519 DKIM Record

You add a new TXT record in DNS for the Ed25519 selector, using a new identifier like ed2026._domainkey.yourdomain.com, while keeping the same domain and selector format as your RSA key. This ensures continuity for receiving servers that validate DKIM. Make sure the record fits within 255 characters—split it across multiple records if needed using proper DNS syntax. The key is to publish it without interrupting mail flow.

How to Publish the Record Correctly

Generate the Ed25519 public key using your signing tool or service. The key format is different from RSA—shorter, deterministic, and designed for modern security.
Create a new DNS TXT record with the selector name ed2026._domainkey.yourdomain.com. Use the same domain as your existing RSA record but a new identifier to avoid conflicts.
Paste the full DKIM public key into the TXT record value. If it exceeds 255 characters, split it into multiple quoted strings (e.g., "part1" "part2") and publish each as a separate TXT record. You can verify the split using tools like DNSCheck or MXToolbox.
Double-check the record syntax. Misplaced quotes or characters break DKIM validation. A single typo in the value can cause valid messages to be marked as forged.
Wait 15–30 minutes for DNS propagation, then verify the record with a tool like RFC 6763 or your email service’s DNS checker.

Why This Matters

Receiving servers look for DKIM signatures using the selector and domain. If the new record is missing, misnamed, or malformed, your messages fail validation—even if they were sent correctly. This can trigger rejections or spam marking, especially with high-sensitivity providers like Gmail or Outlook.

Ed25519 reduces the signature size by up to 75% compared to RSA-2048. That means smaller headers and faster validation, which benefits delivery speed and scalability. But publishing it correctly is non-negotiable. A missing or corrupted record can break alignment, even with valid SPF and DMARC.

For testing, use MailTester’s inbox placement test to see how your new DKIM record affects delivery in real inboxes across major providers.

Step 5: Validate Before and After Migration

Before you fully retire RSA DKIM, test the new Ed25519 signatures in live environments. Use MailTester’s real-time verification API to send test emails from your production system, check headers for both RSA and Ed25519 signatures, and confirm they pass on multiple domains. Monitor bounce logs and postmaster dashboards for sudden delivery delays or authentication errors to catch issues early—especially with older email clients or legacy DMARC policies that may not yet recognize Ed25519.

Test both signatures in parallel

Send test emails via MailTester’s verification API from your actual sending infrastructure, not a test sandbox.
Inspect email headers using a tool like MxToolbox or RFC 6376 to confirm both RSA and Ed25519 signatures are present during the transition.
Validate signing success across at least 3 different domains (e.g., Gmail, Outlook, Yahoo) to rule out recipient-side filtering quirks.
Use MailTester’s inbox placement tester to simulate delivery outcomes in major inboxes before full rollout.

Monitor post-migration performance

Check your postmaster dashboard (e.g., Google Postmaster Tools, Microsoft SNDS) for spikes in authentication failures or DMARC alignment warnings.
Review bounce logs for unexpected hard bounces labeled as “authentication failed” or “DKIM signature invalid” — even if rare, they’re red flags.
Keep a secondary RSA DKIM key active for 14–30 days to preserve fallback compatibility while the new Ed25519 signatures stabilize.
Use MailTester’s bulk verification to scan your entire address list and flag users whose domains reject Ed25519 signatures during bulk sends.

Even small signature mismatches can trigger filtering. Validating across multiple real inboxes ensures your migration doesn’t degrade delivery.

Transitioning from RSA to Ed25519 isn’t just a technical update—it’s a reputation safeguard. Let the data from actual email headers and delivery logs guide your decisions, not assumptions. Use MailTester’s tools to test, verify, and validate every step without disrupting your sender reputation.

Step 6: Monitor for Anomalies and Maintain Sender Reputation

After migrating from RSA DKIM to Ed25519, you must actively monitor authentication results and inbox placement. Use DMARC reports (via rua and ruf) to track pass/fail rates and detect anomalies. Watch for sudden drops in deliverability, especially in Gmail, Outlook, and Apple Mail, which can signal misconfiguration. Run inbox placement tests with MailTester post-cutover to verify stability and catch issues before they impact your sender reputation.

Post-Migration Monitoring Checklist

Enable and parse DMARC aggregate (rua) and forensic (ruf) reports to track authentication success across your domains.
Set up a dedicated email inbox for DMARC reports—tools like dmarcanalyzer.com can help parse results without overloading your primary inbox.
Review the reports daily for one week post-migration, then weekly, looking for increases in DKIM failures or unexpected domains signing mail.
Compare deliverability rates across major providers—Gmail, Outlook, Apple Mail—using baseline data from your pre-migration period.
Run inbox placement tests on a sample of your mailing lists immediately after cutover using MailTester’s inbox placement tool; test both new and returning recipients.
If you notice unexpected delivery failures or spikes in bounces, recheck your Ed25519 key setup, signature alignment, and signing domain consistency.
Ensure your public key is published correctly in DNS and that the selector remains unchanged during migration to avoid breakage.
Use your verification API (MailTester’s API) to validate high-volume sender lists in real time, catching invalid or misconfigured addresses before they damage reputation.

What to Watch For

Sudden drops in inbox placement—especially in Gmail and Apple Mail—are early warnings of failed DKIM validation. Ed25519 keys, while stronger, don't auto-fix misconfigured signing chains. A typo in the selector or mismatch between the signing domain and header From domain will fail even with a correct key.

Let’s say you see a 5% drop in delivery to Gmail two days after migration. That’s a signal. Check: did the key align? Was the selector updated in DNS? Was the message re-signed? Use MailTester’s inbox tester to simulate delivery from your IP and confirm whether the test fails because of DKIM or another factor.

Reputation isn’t built in a day—it’s maintained. Monitoring doesn’t stop at cutover. Keep running tests and reviewing reports. A single misconfigured email can trigger rate limiting, especially if multiple senders from the same IP fail authentication.

Step 7: Fully Deprecate RSA DKIM After 30–60 Days

Once you’ve verified consistent inbox delivery across major providers and confirmed zero failures in DKIM validation using independent tools, you can safely remove the RSA DKIM record from DNS and stop signing with RSA. Let’s walk through the final steps to make the transition irreversible without harming sender reputation.

Transition and Verification Process

Remove the RSA DKIM DNS record after 30–60 days of consistent performance. This prevents old signatures from being attempted during failover or edge cases. Monitor logs for any unexpected validation errors post-removal.
Update your email infrastructure to disable RSA DKIM signing entirely. Ensure no legacy systems or third-party tools (like old ESPs or internal gateways) are still appending RSA signatures in the background.
Validate all outgoing messages using multiple independent tools—check the DKIM signature in message headers via tools like MxToolbox or RFC 8463 (which describes Ed25519’s current standardization). Confirm all messages now carry only the Ed25519 signature.
Test deliverability end-to-end using a mix of inbox placement services. Run tests through platforms like MailTester’s inbox placement tool to ensure no drop in inbox placement occurs during the transition.
Reconfirm your sender reputation with major providers using real-time monitoring tools. If your domain has a history, watch for any unexpected decline in deliverability after the change—though Ed25519 is widely supported and stable.

Why Timing Matters

Leaving RSA DKIM in place beyond 60 days increases the risk of mixed signatures, especially during mail server upgrades or migrations. Even a single message with an old RSA signature can trigger a validation failure in strict environments, potentially marking your domain as inconsistent. The longer RSA remains active, the more chance one broken relay or misconfigured relay can impact your reputation.

RSA DKIM is no longer required. In fact, the IETF has standardized Ed25519 as the preferred method for new implementations due to improved performance and security. The transition is safe when done in phases—monitoring, validating, and confirming before removing legacy support.

Use tools like MailTester’s real-time verification API to test individual messages, or run bulk validation on entire campaigns with MailTester’s bulk verification. This helps you catch edge cases before they hit production. Once you’ve confirmed consistency across multiple tests and over time, you can be confident in the change.

Transitioning to Ed25519 is not just about security—it’s about future-proofing your infrastructure. The move is low-risk when staged properly.

Why Migrating Safely Matters for Deliverability

Email providers like Google and Microsoft rely on consistent DNS-based authentication as a baseline trust signal. Any disruption—no matter how brief—can trigger scrutiny, especially during high-volume sends.

A failed DKIM validation, even if temporary, may result in throttling or temporary blacklisting. This is especially risky when transitioning from legacy RSA DKIM to Ed25519 without a dual-signing window, which leaves no fallback during the switch.

Even a single misrouted or unauthenticated message can degrade sender reputation. Migrating safely—ensuring dual signing and full DNS alignment—is not optional. It's a deliverability necessity.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can I skip dual signing during DKIM migration?

No. Skipping dual signing increases the risk of authentication failure, which can harm sender reputation. Dual signing ensures continuity until all receivers recognize the new key.

How long should I keep RSA DKIM after migrating to Ed25519?

Keep RSA DKIM active for 30–60 days after enabling Ed25519 to avoid delivery disruptions, especially with older or slow-updating email providers.

Does Ed25519 replace RSA entirely in DKIM?

Not all providers support Ed25519 yet, but it is the recommended standard for new setups. Legacy RSA keys are still valid but increasingly discouraged.

Will changing DKIM signatures trigger spam filters?

Only if the transition is abrupt. Proper dual-signing and validation prevent spam filter flags. Sudden key changes are the real trigger.

Can I use MailTester to verify DKIM signatures in email headers?

Yes. MailTester’s real-time verification API checks DKIM, SPF, and DMARC alignment, including signature validity, domain ownership, and deliverability risks.

What happens if I publish Ed25519 but don’t use it to sign emails?

Receivers will fail signature validation. This breaks authentication and can trigger spam filtering. Only publish keys that are actively used.

Is Ed25519 widely supported by email providers?

Yes. Major providers like Gmail, Outlook, and Apple Mail support Ed25519, though adoption is still growing. It is now the preferred standard for new implementations.

How do I test if my Ed25519 DKIM works before full rollout?

Use MailTester’s inbox placement tool to send test messages to real inboxes and verify the signature passes DKIM validation and reaches the inbox.

Can I merge RSA and Ed25519 into a single DKIM record?

No. Each signature must be published independently in DNS. You cannot bind multiple keys into one TXT record; each selector requires its own.

Why does DKIM migration affect sender reputation so much?

Because sender reputation relies on consistency. A broken or missing DKIM signature is one of the fastest ways to trigger spam filtering. Even temporary failures can hurt long-term trust.