DKIM often breaks after an email or DNS migration because the selector, private key owner and public DNS record no longer describe the same signing system. Find the selector on an actual outgoing message first; do not guess it from the hosting panel.
Read the DKIM-Signature header
Record d= and s= from a message sent by the new path. That tells you the exact DNS name the recipient queries.
Query the authoritative DNS
Confirm selector._domainkey resolves to the public key expected by the current mail provider, without stale CNAMEs or old zone data.
Check which system signs
Moving DNS does not move the private key; moving mail service may introduce a new selector. Know whether WordPress SMTP, Microsoft, Google or an API provider owns signing.
Allow coexistence during migration
Old and new selectors can coexist safely while traffic transitions. Removing the old selector too early breaks delayed or still-routed senders.
Watch propagation by authoritative answer
Use authoritative nameservers and then public resolvers; a local panel saying “saved” does not prove recipients can see the record.
Retest alignment and body integrity
A passing signature should also align for DMARC where intended. Gateways that modify body/headers after signing can still invalidate DKIM.
Use the existing DKIM diagnostic and compare DNS migration effects with email delivery after moving DNS.
Keep a selector migration table
For old and new sending systems record provider, DKIM selector, d= domain, DNS target/value, first-send date and planned retirement date. During the transition both selectors may be valid. This table makes it obvious which record can be removed later and prevents deleting the old key while queues or legacy senders are still producing signed messages.