Why is DKIM double signing important during domain migration?

You're migrating email systems. Old servers still sending. New ones live. But your emails start bouncing—sometimes silently. Why? Because DKIM verification fails when the public key doesn’t match the signature. And if your new system doesn’t yet cover all old messages, your emails can be marked as forged.

DKIM double signing during migration—using two selectors on the same domain—is the technical safeguard that keeps deliverability intact. It’s like having two working keys during a house move: one for the old locks, one for the new, until the full switch is complete. Without it, even valid emails get rejected.

Here’s what you’ll learn: how double signing works, why it prevents delivery breakage during overlap periods, and what happens when you skip it. This isn’t theory. It’s a known point of failure in cross-system migrations.

Key takeaways

  • DKIM double signing uses two selectors on the same domain to maintain email authentication during parallel system operation.
  • Without it, migrated messages may fail DKIM verification due to missing or mismatched public keys, reducing inbox placement.
  • Double signing preserves sender reputation by avoiding sudden drops in authentication success during transition phases.

What happens if you don’t use two DKIM selectors during migration?

You risk email delivery failures and reputation damage during migration. If you don’t use two DKIM selectors—one for the old system, one for the new—sending from the legacy system may fail DKIM validation once the new DNS records go live, while emails from the new system won’t be validated by older receivers until they’ve learned about the new key. This creates a window where messages are either rejected or flagged as suspicious, harming sender reputation and inbox placement.

Legacy sends break as DNS shifts

During migration, the old DKIM key is still active, but DNS records for the new key are being propagated. Even if your new system signs messages correctly, receivers relying on the old key won't recognize the new signature. The old system, still using the old key, may fail validation when the new records are fully live. This mismatch results in hard bounces or spam filtering, especially for receivers that enforce strict DKIM checks.

Old receivers aren’t aware of the new key

Even if your new system signs all messages properly, older systems may not be able to validate the new key until they’ve refreshed their DNS records. This lag—common with DNS caching and propagation delays—means legitimate emails could be rejected or marked as suspicious during the transition phase. The effect is worse for ISPs that prioritize authentication strictness, like Google and Microsoft, which may temporarily flag or deprioritize messages due to signature mismatch.

According to RFC 6376, DKIM signing must align with the domain’s published public key. Any mismatch during transitional phases can trigger validation failures. You're not just changing a key—you're changing the trust chain that receivers follow. Without dual selectors, you leave a gap where both old and new systems can fail independently.

MailTester’s real-time email verification can help you test whether an address is properly configured for DKIM—especially during transition periods. Run a bulk list check before migration to catch domains with inconsistent or missing key records. Verify your entire list ahead of time to identify and clean up problematic addresses before sending.

How does DKIM double signing with two selectors work?

During a DKIM migration, you publish two separate DKIM records in DNS: one for your old selector (like legacy._domainkey.example.com) and one for the new (like new._domainkey.example.com). Both keys are active simultaneously, so both your legacy and new mail systems can sign outbound emails correctly. Receiving servers verify the signature using the selector name in the DKIM-Signature header to look up the correct public key in DNS. This avoids sending failures or authentication drops during the transition.

Why Two Selectors Are Needed

When switching DKIM keys, your old system must keep signing emails until all old messages are delivered and tracked. If you disable the old key too early, receiving servers will reject emails signed with the old selector because the public key is no longer present in DNS. That breaks email integrity. By keeping both records online, you maintain a smooth handover without losing authentication.

How DNS and Receiving Servers Handle the Transition

Each DKIM signature includes a selector value in the DKIM-Signature field. For example: d=example.com; s=new; tells the receiver to query new._domainkey.example.com. The server doesn't care about the old key unless the email uses s=legacy. This means you can operate two keys in parallel, each associated with different sending systems or time windows.

According to RFC 6376, the selector is part of the DNS lookup path, and servers must use it to resolve the correct public key. This design enables migration without disruptions. Major providers like Google, Microsoft, and AWS all require this pattern during key roll-over.

Double signing isn't a long-term solution, but a temporary bridge. Once your new system fully handles all sending and all old mail has cleared delivery windows, you can remove the legacy key safely. Leaving both keys indefinitely increases exposure risk if either private key is compromised.

If you’re planning a DKIM migration, ensure both your old and new systems are configured to use the correct selector. Test signatures using tools like inbox placement testers to confirm receiving servers accept your signed mail during the overlap period. Proper implementation here prevents deliverability issues that can arise from authentication breakage.

What are the technical steps to set up DKIM double signing?

During a migration, you configure DKIM double signing by generating a new DKIM key pair for your new email system, publishing a new DNS TXT record with a unique selector (like 'new'), while keeping the old selector (like 'legacy') active. Both keys are used simultaneously until the new system is fully live, ensuring message authentication isn’t interrupted. Proper alignment with SPF and DMARC must be maintained throughout.

Step-by-step configuration

  1. Generate a new DKIM key pair for your new email service provider (ESP) using their built-in key management tool. This ensures the new system signs emails correctly with a fresh, secure key. The key length should follow industry standards—typically 2048 bits or higher.
  2. Create a new DNS TXT record with a unique selector (e.g., 'new') under the DKIM selector domain, such as new._domainkey.yourcompany.com. This record publishes the public key so receiving servers can verify signed messages from your new system.
  3. Keep the old DNS TXT record active for the legacy selector (e.g., legacy._domainkey.yourcompany.com). Do not remove it until you're certain all outbound emails are flowing through the new system. Premature removal causes authentication failures.
  4. Ensure both mail systems sign with the correct selector. The old system must continue using the legacy selector; the new system must use the new one. Misconfigured selectors result in failed validation even with valid keys.
  5. Monitor for signature failures using tools like MxToolbox's DKIM checker or Spamhaus' DNSBL tools. Check that both public keys are valid and accessible. You can also test alignment by sending a sample email and verifying the signature headers.

Key alignment and verification

DKIM double signing only works if SPF and DMARC are configured correctly across both systems. SPF must include both the old and new sending IPs, and DMARC policy (p=) should be set to quarantine or reject only after you're confident all legitimate traffic is covered. Use a real-time email authentication tool to test alignment.

Want to stress-test your domain's deliverability before or after migration? Try MailTester’s inbox placement test to see how your messages are received by major providers like Gmail, Outlook, and Apple. It checks authentication, content, and spam signals—no guesswork.

Double signing is temporary. Once the new system has full traffic and all old messages are validated, remove the legacy selector record. Always test DNS propagation afterward using tools like MxToolbox’s DNS lookup to confirm changes are live and no servers are still referencing the old key.

What’s the role of SPF, DKIM, and DMARC during this transition?

During a migration, SPF stays fixed—it authorizes only your approved sending IPs, so it doesn’t shift when switching systems. DKIM is where double signing matters: signing with both the old and new selectors ensures your messages pass validation regardless of which system sent them. DMARC relies on SPF or DKIM alignment—without both, your policy enforcement can fail, especially if DKIM is missing on old messages. Double signing keeps DMARC checks passing during the overlap period. You’re not losing control; you're maintaining it across the handoff.

SPF: A consistent baseline

SPF defines which IPs are allowed to send mail for your domain. During migration, you typically keep the same SPF record, especially if you’re using a shared service or transitional sending method. Changing SPF too soon risks breaking legitimate mail flow. So, if your old and new systems both use legitimate IPs, SPF remains unchanged. The key is ensuring the new system’s IP is included in the record, not removing the old one.

DKIM: The integrity layer with dual signatures

DKIM signs each message cryptographically, proving it wasn’t altered in transit. When migrating from one email system to another, you can’t instantly remove the old signing key. Double signing—where you sign the same message with both the old selector and the new one—ensures recipients still validate the message using either key. This avoids failed validation due to mismatched signatures during overlap. It’s not redundant; it’s necessary.

For example, if the old system used selector1._domainkey.example.com and the new one uses selector2._domainkey.example.com, signing with both during migration means any receiving server using either key will verify the message. This prevents deliverability drops during the switch. The DKIM specification allows multiple signatures per message, so this is a standard, supported practice.

DMARC policy enforcement depends on either SPF or DKIM alignment being met. If DKIM is missing or failed during the migration, DMARC reports can mark the message as failing, even if SPF passes. Double signing removes that risk. Without it, you may see sudden spikes in DMARC failures or sudden drops in inbox placement.

Double signing is a low-cost, high-impact step. It ensures continuity without waiting for full propagation. Use a real-time verification tool like MailTester’s email checker to test your domains and verify that both old and new DKIM keys are active and properly published during the migration phase.

How do you verify that DKIM double signing is working?

You verify DKIM double signing by checking that delivered emails contain two valid DKIM-Signature headers, one for each selector. Confirm by inspecting raw message headers, using a real-time email verification service to test outgoing messages, and running bulk list verification to catch misaligned signs during high-volume sends. This ensures both old and new keys are recognized during migration.

Check the DKIM-Signature header directly

  • Open a delivered email in your inbox and view the full message headers.
  • Look for two DKIM-Signature headers, each with a unique id or selector value (e.g., selector1.domain.com and selector2.domain.com).
  • Validate both signatures are present and syntactically correct using an online DKIM verifier like the one at dkimvalidator.com.
  • Ensure the d= and h= fields match your domain and signed header fields.

Use real-time verification to test outbound delivery

  • Send test messages to known domains (like Gmail, Outlook, Yahoo) using your sending platform.
  • Use MailTester’s email checker to verify single addresses before sending, confirming they accept DKIM-signed mail.
  • Send sample messages through your new DKIM setup and run them through MailTester’s inbox placement test to see if they reach inboxes and maintain validation.
  • Use MailTester’s verification API to automate checks on your sending list, flagging any addresses that fail DKIM validation.
Double signing is not a workaround — it’s a migration necessity. According to the RFC 6376 specification, a receiving system should accept any valid signature, regardless of selector, as long as it’s properly aligned and verified.

Run bulk verification on your sending list

  • Upload your full sending list to MailTester’s bulk verification tool to check for misaligned or invalid DKIM signs at scale.
  • Review the results for any “invalid” or “dangling” DKIM statuses, which may indicate a failure in key alignment.
  • Use the output to purge or retry addresses with known signing issues before sending campaigns.
  • Recheck the list after completing the migration phase to confirm no new errors emerged.

Can you automate DKIM double signing during migration?

Yes, you can automate DKIM double signing during migration—but only with precise coordination between DNS updates, mail system configuration, and automated validation. Let’s walk through how it works in practice.

Automate key generation and deployment

Use your ESP’s API to generate and deploy DKIM keys for both the old and new selectors programmatically. This ensures both keys are in place before you activate new senders. APIs from providers like SendGrid or Amazon SES allow you to spin up key pairs and update DNS records in a repeatable, error-proof way.

Once generated, publish both selectors in your DNS zone. The old selector remains active until you’ve confirmed delivery stability with the new one. This parallel phase is essential—double signing keeps email authentication valid while you transition.

Validate immediately with real-time verification

Don’t wait for logs or delivery reports to detect breakage. Integrate MailTester’s real-time verification API into your deployment pipeline. After updating DNS and activating a new sender, run immediate checks on a sample of your list.

This catches issues like misconfigured selectors, incorrect key lengths, or malformed headers before they hit your customers. A single failing verification reveals a misstep in your automation—fix it instantly, not days later.

DNS propagation delays can mask problems, but automated testing reduces blind time. The RFC 6376 standard outlines the technical requirements for DKIM, including multi-selector usage—[see section 4.5](https://tools.ietf.org/html/rfc6376#section-4.5) for the formal spec on selector handling.

Keep your infrastructure resilient by treating verification as part of deployment. Double signing isn’t just about compliance—it’s about continuity. Tools like MailTester help you prove both are working.

With the right automation, DNS, and validation, migration becomes predictable. You’ll avoid delivery gaps, protect sender reputation, and move faster—all without risking inbox placement.

What happens when the migration is complete?

Once you’ve fully switched to the new DKIM key and confirmed all outgoing mail is now using it, you should remove the old selector from DNS. Keep the new one active and watch for any DKIM failures—these could signal misconfigurations. Update your DMARC policy to reflect that only the new key is valid, especially if you’re enforcing strict policies. Finally, validate inbox delivery with a real-world test using tools like MailTester’s inbox placement checker to ensure nothing dropped during the transition.

Step-by-step: Post-migration stability

  1. Remove the old DKIM selector from DNS once no mail is being sent from the legacy system. Keeping it active creates a window for attackers to exploit old keys or trigger confusion in authentication checks.
  2. Monitor DKIM results for the new selector across all inbound and outbound mail flow. Failure rates above 0.1% may indicate misalignment in your signing setup or a mismatch in DNS records. Use tools like MxToolbox to validate DNS records in real time.
  3. Update your DMARC policy to reflect that only the new DKIM selector is valid. If you were using asp=1 or p=reject, ensure the alignment policy aligns with the new key. An outdated policy may result in legitimate messages being rejected due to failed authentication.
  4. Test inbox placement across major providers using real email inboxes. A shift in key signing should not affect delivery, but small changes in authentication patterns can trigger filters. Use MailTester’s inbox placement test to send sample emails to Gmail, Outlook, Yahoo, and others to verify delivery and spam scores.
  5. Retain audit logs for 30–60 days. Even after confirmation, keep monitoring for anomalies. If you later need to re-enable a legacy system, you’ll want to understand how old keys behaved in your environment.

Making it stick

DKIM migration isn’t a one-time switch. It’s a transition phase. The goal is not just to update keys—but to ensure the new system behaves identically to the old, without breaking trust. You’re not fixing authentication; you’re maintaining it through change.

Let’s be clear: if your DMARC policy enforces strict alignment, any failure—even a single invalid signature—can result in email rejection. That’s why testing real delivery, not just DNS, matters. Tools like MailTester give you a realistic view of how your email lands in real inboxes, not just a lab result.

How does MailTester support DKIM double signing during migration?

You can validate DKIM alignment and detect double-signing conflicts during migration by testing individual messages in real time, running inbox placement tests across major providers, and scanning large lists for misconfigured or invalid records—using MailTester’s 98.9% accurate verification engine to confirm your setup works before sending.

Test individual messages before they leave your system

Use MailTester’s real-time verification API to check each message’s DKIM signature alignment before sending. This catches issues early—like when both old and new selectors are active, causing double signing—before they affect deliverability. The API returns detailed feedback on alignment, DNS visibility, and signature validity. You can integrate it directly into your mailer stack, so every email is vetted automatically. Test individual emails with the real-time API before they go out.

Verify inbox placement across major email providers

Double signing can trigger red flags with inbox providers, even if technically valid. Run inbox placement tests using MailTester’s inbox tester to see if messages land in the inbox, spam, or get blocked across Gmail, Yahoo, Outlook, and others. This confirms whether your double-signature setup is accepted or flagged as suspicious. A test result showing inbox delivery means your configuration is likely safe for production. Run inbox placement tests to validate your migration.

Scan entire lists for configuration errors

During a migration, you may have thousands of addresses with inconsistent DKIM settings. Use bulk list verification to audit large contact files for catch-all responses, invalid syntax, or missing DNS records. MailTester detects misconfigured public keys or outdated selectors that could break DKIM alignment. The 98.9% accuracy means you're not betting on assumptions—just proven data. Verify your full list to catch problems before rollout.

DKIM double signing isn’t automatically harmful, but it can confuse spam filters if not handled carefully. The most reliable way to verify it’s working is to test across real mail environments. By combining real-time API checks, inbox placement validation, and large-scale list audits, MailTester gives you end-to-end clarity. This approach follows industry best practices—for example, the core principles of email authentication outlined in RFC 6376, which defines how DKIM signatures should be validated without ambiguity.

Is it safe to keep two DKIM selectors long-term?

No. Keeping two active DKIM selectors long-term increases complexity, raises the risk of misconfiguration, and can confuse email receivers. It may even trigger fraud alerts if the old selector isn’t properly retired. The best practice is to phase out the old selector immediately after confirming all outgoing mail uses the new one successfully.

Why two active selectors create lasting risk

Each DKIM selector defines a unique cryptographic key pair. When you run two active selectors, you’re effectively signing the same email with two different keys. This isn’t inherently broken — but it adds surface area for errors.

Receivers validate DKIM signatures using DNS records. If a mail receiver sees both selectors active but can’t correlate them to a single, coherent sending policy, they may interpret this as inconsistency or abuse. This can hurt your sender reputation, especially if the old selector was set up under different domain policies or was less rigorously managed.

How to phase out old selectors safely

Let’s walk through a real-world migration: you deploy a new selector, wait 24–48 hours, and confirm all outbound messages are signing correctly. Once you’re confident, stop using the old selector. Remove it from your DNS records entirely. Don’t just leave it inactive — old selectors that remain in DNS can still be used by third parties, increasing the attack surface.

According to RFC 6376 (the core DKIM specification), a receiving system assumes that a valid signature corresponds to a single, consistent key policy. Maintaining two active selectors violates that expectation. That’s why industry best practices — including those from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG) — emphasize time-bound migrations.

When you’re done, use a tool like MailTester’s email checker to verify that outbound emails from your domain now consistently use only the new selector, and that no legacy keys are still in active use.

If you're verifying large lists before migration, MailTester’s bulk verification can help you identify invalid or non-deliverable addresses early, reducing noise in your domain’s post-migration performance.

How do you avoid common mistakes during DKIM migration?

Never remove the old DKIM selector until testing confirms the new one works in production. Running both selectors in parallel during migration prevents email failures and ensures continuity.

Key practices for a smooth migration

  • Do not assume DNS changes take effect immediately. Allow 24–72 hours for propagation across global networks.
  • Use real inbox testing—like MailTester’s deliverability checks—to validate placement and authentication before full rollout.
  • Avoid mixing DKIM selectors across domains or subdomains unless alignment is explicitly managed. Misalignment breaks authentication.

DKIM double signing with two selectors is safe and necessary during migration. The critical factor isn’t the presence of multiple selectors—it’s ensuring the transition doesn’t break trust.

Sources

Keep reading

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

Frequently asked questions

What is DKIM double signing?

DKIM double signing means using two different DKIM selector records on the same domain during a transition. This allows both old and new mail systems to sign emails with valid keys, ensuring continuity.

Do I need two DKIM records during migration?

Yes—using two selectors ensures that emails from both old and new systems are validated by receivers. This prevents delivery failures during the shift.

Can a single DKIM signature fail during migration?

Yes. If only one selector is active and the old system is still sending, the message will fail DKIM validation, reducing deliverability.

How long should DKIM double signing last?

Only for the duration of the migration—typically a few days to two weeks. Remove the old selector as soon as the new system is fully active.

What happens if I don’t test DKIM during migration?

You risk undetected failure in email delivery, DMARC alignment failures, and damage to sender reputation without a clear signal.

Can I use MailTester to verify DKIM signatures?

Yes. MailTester’s real-time API and inbox testing tools check DKIM validity and inbox placement in major email providers.

Is DKIM double signing required for all migrations?

Not all—are small-scale migrations with simultaneous cutover may skip it. But for parallel or phased migrations, it’s essential.

Can double signing cause DMARC failures?

Not if configured correctly. Double signing doesn’t break DMARC as long as at least one of the two signatures aligns with SPF or the domain.

What’s the risk of leaving two selectors active too long?

Increased complexity, higher chance of misconfiguration, and potential confusion for receivers, which may trigger security warnings or filtering.

How do I know if my DKIM records are correct?

Use MailTester’s real-time verification or run a DNS check via MxToolbox to confirm public keys are published and accessible.

Do all ESPs support DKIM double signing?

The feature is widely supported, but the ability to assign custom selectors varies. Check your provider’s documentation for multi-selector support.

Can I migrate DKIM without using two selectors?

Yes—but only if you’re migrating in a single step with no overlap. For any parallel period, double signing is the safe, proven method.