Introduction

A mail migration can move users to the new provider while the domain still publishes a DKIM selector that authorizes the old platform. Mail may appear to work, authentication may even pass for some messages, but one application, relay, or mailbox path still signs through the previous provider because its selector remains active in DNS.

Treat this as a sender-inventory problem instead of a generic DKIM failure. Start by checking which systems are still signing live mail and which selectors they use, because an old DKIM record should not be removed or kept blindly after a provider migration.

Symptoms

  • The domain still publishes DKIM selectors from the old mail provider after migration
  • Some messages are signed by the new provider while others still show the old selector
  • Authentication reports reveal mixed DKIM identities on the same domain
  • Teams are unsure whether it is safe to remove the old provider’s DKIM records
  • Third-party apps or devices still appear to send as the domain after cutover
  • The issue started after mail-provider migration, relay cleanup, or staged sender cutover

Common Causes

  • One application or device still sends through the old mail provider
  • The old DKIM selector was left in DNS for coexistence and never revisited
  • Mailboxes moved, but outbound relays and app senders were not cut over at the same time
  • Teams validated mailbox sending only and missed other live sending paths
  • DNS cleanup was postponed because removing the old selector felt risky without evidence
  • Multiple selectors remained published without a clear inventory of which ones were still active

Step-by-Step Fix

  1. Capture headers from live messages sent through each important path and identify which DKIM selectors are still being used, because you need evidence before removing or keeping any old selector.
  2. Confirm whether the old selector belongs to a sender that is still legitimately in use, because a stale DNS record alone is not a problem unless the old provider is still part of live mail flow.
  3. Inventory every outbound sender that uses the domain, including mailbox users, websites, scanners, CRMs, and relay devices, because provider migrations often move people before they move applications.
  4. Compare the selectors published in DNS with the selectors observed in message headers, because that shows which records are still operational versus simply left behind.
  5. Cut over or retire any sender still using the old provider before removing its selector, because deleting DKIM early can break authentication for a path you have not migrated yet.
  6. Remove the old selector only after confirming no live traffic depends on it, because mixed-provider sending often survives longer than the mailbox migration itself.
  7. Retest messages from every remaining sender and confirm they now sign with the intended provider, because one successful mailbox test does not prove full outbound cleanup.
  8. Review SPF and DMARC alignment after the DKIM cleanup, because old-provider authorization often lingers in more than one DNS control.
  9. Document the final selector inventory and active senders for the domain, because DKIM cleanup is easy to defer and hard to reconstruct later without message evidence.