[ Transport security ]
DANE for SMTP: understand DNSSEC and TLSA dependencies
Trace secure MX discovery, TLSA usability and usage-specific certificate matching before treating an SMTP route as DANE authenticated.
By the EmailAuth research team · 8 min read
[ Key points ]
- DANE depends on validated discovery, not merely the presence of TLSA text.
- TLSA usage, selector and matching type determine the authentication check.
- Review every MX candidate and coordinate DNSSEC, DNS publication and server-key ownership.
[ Takeaway ]
Validate the route and trust chain independently from the association-to-server match, retaining the exact DANE outcome for each candidate.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Follow the actual service binding
TLSA owner and usability must match the SMTP candidate.
Next steps
- Record secure MX and TLSA lookup paths.
- Compare the full tuple with the presented chain or key.
- Review backups and normal preference traversal.
CISO / SecOps
Distinguish validation states
Insecure DNS and bogus signed data have different consequences.
Next steps
- Retain resolver and trust context.
- Apply usage-specific rules rather than generic PKIX assumptions.
- Coordinate DNSSEC and certificate lifecycle owners.
Founder / Non-technical
Own the shared operational dependency
A supplier key change can invalidate otherwise healthy DNS.
Next steps
- Identify DNS and SMTP accountable teams.
- Require change notification across them.
- Approve rollout only with complete route evidence.
[ FAQs ]
Frequently asked questions
Does a visible TLSA record prove DANE authentication?
No. Its DNSSEC status, applicability, supported parameters and match to the server all matter.
Where is the normal port-25 TLSA lookup?
It uses _25._tcp with the applicable TLSA base domain, often the MX hostname. Alias and non-MX rules require following the actual discovery path.
Is insecure DNS the same as bogus DNSSEC?
No. Insecure results are not validation errors; bogus or indeterminate results are treated as lookup failures in this specification.
What does 3 1 1 describe?
DANE-EE usage, SPKI selection and SHA-256 matching. It associates the server’s leaf public key through DNSSEC-protected data.
Does DANE-EE require a public-CA name match and expiry check?
Its SMTP authentication relies on the TLSA association; RFC 7672 says certificate names need not match and expiration is ignored for this usage. Other usages differ.
What if secure TLSA records are present but all unusable?
That branch still requires TLS, but not authentication. It differs from a secure set with at least one usable association.
Can a lower-priority MX preempt a better one because it has DANE?
No. RFC 7672 preserves MX preference traversal rather than promoting candidates solely for stronger security.
Can DNSSEC and certificate rollovers share one unchecked change?
Treat them as distinct dependencies with coordinated evidence. A valid association with broken DNSSEC and secure stale data are different failures.
[ Sources ]
Sources
- RFC 7672
Sections §2.1 DNS Considerations · §2.2 TLS Discovery · §2.2.1 MX Resolution · §2.2.3 TLSA Record Lookup · §3.1 TLSA Certificate Usages · §3.2 Certificate Matching · §4. Server Key Management
- RFC 7671
Sections §6. Service Provider and TLSA Publisher Synchronization · §7. TLSA Base Domain and CNAMEs · §8. TLSA Publisher Requirements · §8.1 Key Rollover with Fixed TLSA Parameters · §8.3 Switching to New TLSA Parameters
- RFC 6698
Sections §2.1 TLSA RDATA Wire Format · §3. Domain Names for TLSA Certificate Associations
[ Glossary ]
Glossary
- DANE-EE
- Certificate usage 3, authenticating the end entity through its DNSSEC-protected association.
- DANE-TA
- Certificate usage 2, using a DNSSEC-designated trust anchor with applicable chain and name checks.
- Usable association
- A TLSA association whose parameters the relevant implementation can apply.
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