[ DKIM ]
Diagnose DKIM failures after a tenant migration
Trace old and new signing dependencies before retiring selectors or declaring a migration complete.
By the EmailAuth research team · 3 min read
[ Key points ]
- Inventory old and new signing dependencies by route.
- Separate missing keys, mismatched keys and changed content.
- Retire old verification data only under a risk-based plan.
[ Takeaway ]
Retire old verification data only under a risk-based plan.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Compare dependencies by route
Old and new selectors, targets and processing order can fail independently.
Next steps
- Preserve pre-migration samples.
- Classify the exact failing check.
- Test all production-critical formats.
CISO / SecOps
Approve coexistence and retirement
Overlap preserves verification but must not preserve compromised authority without review.
Next steps
- Record key custody on both sides.
- Review CNAME target retention.
- Set risk-based exit and recovery conditions.
Founder / Non-technical
Treat authentication as a migration workstream
Moving mailboxes does not automatically move customer-message identity.
Next steps
- Include application owners in cutover.
- Protect delayed business messages.
- Require evidence before closing the old service.
[ FAQs ]
Frequently asked questions
Can mailbox migration succeed while DKIM still fails?
Yes. Signing, DNS, applications and queued mail have separate dependencies.
Should the new tenant reuse the old selector?
Only when the supported design and transition evidence justify it. Replacing a key at the same name can break old signatures.
Does keeping a CNAME preserve the old key?
Only if its target continues to serve the required verification data.
How long should old keys remain?
Base the overlap on queues, expiry, operational requirements and risk; there is no universal duration.
Does lower TTL clear earlier cached answers?
No. Earlier cache entries can live for their previously assigned TTL.
Why might new mail pass DKIM but lack alignment?
The new service may sign with a provider domain rather than the intended customer domain.
Will rotating keys fix a body-hash mismatch?
Not if a downstream component is changing signed content. Investigate the processing order.
[ Sources ]
Sources
[ Glossary ]
Glossary
- DKIM
- A signature mechanism that associates a signing domain with selected message content using DNS-published verification material.
- Selector
- The s value that, with the d signing domain, identifies a DKIM verification-key lookup name.
- Identifier alignment
- The required domain relationship between the author domain and a successfully authenticated identifier for DMARC.
- Key custodian
- The person, team or provider responsible for controlling and protecting a private signing key.
- Authentication trust boundary
- The administrative boundary within which a receiver accepts a reported authentication result as its trusted evidence.
Enterprise provenance
Why top financial institutions and governments retired their email security dashboards.
Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.
EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.
SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption