Source review dated 8 November 2026. Operational steps are proposed; only the explicitly labelled offline demonstration is executed. No live tenant, DNS or mail delivery is claimed.
A tenant migration can move users successfully while leaving outbound authentication partly attached to the old service. DKIM failures then appear only for certain domains, applications or delayed messages. Diagnose the actual signing and DNS dependencies rather than assuming that a working login or mailbox proves the mail path has moved.
Preserve the old configuration and representative raw messages before changing anything else. Record when the failure began and whether it affects new mail, mail already queued or a particular sending route. That timeline is essential when the signature and the current DNS state belong to different stages of the migration.
Inventory both sides of the transition
For each From domain and route, record the old and new d values, selectors, DNS record types, targets, key custodians and last known signing times. Include application SMTP, delegated aliases and outbound gateways, not only user mailboxes. Distinguish management-portal access from the services that still sign or queue messages.
If the new service requires the same selector label, compare the complete lookup name and proposed key material. Replacing the public key at an existing name can prevent old signatures from verifying. A distinct supported selector often permits coexistence more cleanly, but the product's actual capabilities determine the available design.
Classify the first failing check
Use a newly received sample and a preserved pre-migration sample. Accept Authentication-Results only from the receiving system’s established trust boundary, not an arbitrary sender-supplied header. Locate each DKIM-Signature and derive its lookup from d and s. A missing old key is a lookup failure. A new public key that does not match the old private key is a different problem. A body-hash mismatch points toward changed content or canonicalization rather than a missing DNS record.
RFC 6376 section 6.1 separates key retrieval, key validation, body-hash comparison and signature verification. Keep those observations separate in the incident log. A migration can also produce passing DKIM under an unrelated provider domain, which is an alignment issue rather than a cryptographic failure.
Work through a coexistence timeline
Illustrative timeline: the old tenant signs using old1._domainkey.brand.example. The replacement tenant starts signing with new1 at the same domain. During a planned overlap, both public keys remain available while new traffic uses new1. Removing old1 immediately can make a delayed old message unverifiable even though a new test message passes.
Choose the overlap from known queue behavior, signature expiry where used, operational requirements and security risk. There is no universal safe number of hours. Lowering DNS TTL at cutover does not shorten the lifetime of answers already cached under an earlier TTL. The timeline is a proposed migration model, not evidence that any provider preserves old verification data after an account closes.
Repair the actual dependency
If an old provider controls a CNAME target, establish whether closing the tenant also removes the target. Keeping a customer-side CNAME does not preserve a key that the target no longer serves. Ask the provider for its documented retention behavior before final account closure.
For new mail, confirm that the new service is actively signing with the intended domain and selector, and that its published public key matches. If a gateway now modifies the message after signing, repair the processing order rather than repeatedly rotating keys. Test the supported route with HTML, attachments and important application messages.
Define migration exit evidence
Keep dated samples for each critical domain and route, with verification and alignment as separate fields. Record remaining old senders, delayed-message exposure and the approved time or condition for retiring each key. Export operational evidence before losing the old interface.
Close the migration only when the relevant dependencies have moved or have explicit owners and expiry conditions. Preserve a recovery plan, but do not blindly restore a key or provider permission if the migration followed a compromise. The accepted outcome is a verified transition with stated residual risks, not merely an empty old tenant.
Primary section references: RFC 6376 §3.1, RFC 6376 §3.6.2, RFC 6376 §6.1, RFC 6376 §8.3, RFC 9989 §4.4, RFC 8601 §7.1, RFC 1034 §3.6, RFC 1034 §3.6.2.