DIAGNOSTIC PLAYBOOK
DANE TLSA exists but DNSSEC validation fails
DANE for SMTP relies on DNSSEC-authenticated TLSA information. A TLSA-shaped record without a valid DNSSEC chain cannot provide the same authenticated transport assurance.
HealthCheck Email editorial team · · Examples are illustrative
How to investigate
- Identify the destination MX and its applicable TLSA query name.
- Validate the DNSSEC chain and distinguish secure, insecure and bogus outcomes.
- Repair signing or delegation through the DNS operator before relying on the association data.
What this looks like
ILLUSTRATIVE EXAMPLE
A TLSA record matches the certificate, but a stale DS record breaks validation after a DNS migration. Matching bytes alone do not repair the trust chain.
A mistake to avoid
Changing TLSA data is not a substitute for fixing DNSSEC. Coordinate DNS and certificate ownership when investigating the failure.
Keep the result in context
Transport encryption protects a connection between mail systems. It is different from message authentication and does not imply end-to-end encryption. Investigate the receiving MX hostname, the TLS session and the applicable policy separately before deciding which system needs a change.
Take the next step
Use the related check to gather evidence, then compare it with the affected message or service. Keep the result and time with your notes so a later change can be distinguished from the original problem.
Sources and further reading
The protocol references below explain the underlying behavior. Your sending or DNS provider supplies the account-specific settings for its service.