DANE TLSA Checker

Why check your DANE TLSA

SMTP transport over opportunistic TLS leaves the door open to two quiet attack scenarios: a man-in-the-middle stripping STARTTLS to force cleartext, or a forged certificate accepted by a sending MTA that cannot tell the real one from the fake. DANE closes this gap by publishing a hash of the expected certificate in DNS, signed by DNSSEC.

But DANE is unforgiving: a misplaced TLSA record, an unsigned DNSSEC zone, or a hash that drifts after a certificate renewal is enough to silently invalidate your deployment. No error message reaches the sending MTA: the connection quietly falls back to opportunistic TLS, and your SMTP flow loses the protection you thought you had.

Checking your DANE TLSA in real time becomes essential:

• After initial publication: confirm that the record resolves, is DNSSEC-signed, and that the hash matches the served certificate
• After any certificate renewal: the number one cause of DANE outages is a hash/certificate mismatch
• Mail security audit: confirm DANE covers every MX host and no edge is left on opportunistic TLS
• Before a mail provider migration: Microsoft 365, Google Workspace and traditional providers do not offer the same level of DANE support

How to use this checker in 3 steps

Step 1: enter the domain to analyze

Type the mail domain exactly as it appears in your email addresses:

• captaindns.com (primary domain)
• marketing.captaindns.com (subdomain if you manage multiple zones)

The tool automatically enumerates the MX hosts, then queries _25._tcp.<mx-host> for each. DNSSEC validation walks the full chain up to the root.

Step 2: read the per-MX results

The checker displays, for each MX:

Step 3: apply the fixes

Diagnostics are ranked by severity:

• Blocking: DNSSEC missing, TLSA not found, hash mismatch. The DANE deployment is protecting nobody as is.
• Warning: discouraged combination (usage 0 or 1 without a controlled CA), matching type 0 publishing the raw certificate, abnormally long TTL.
• Info: MX host with no expected DANE support (Google Workspace), multiple records consistent with an ongoing key rollover.

Fix the DNS zone, wait for propagation (TTL), and rerun the checker to confirm.

Anatomy of a TLSA record

The TLSA record is published at a precise location and contains four fields strictly specified by RFC 6698.

DNS location

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 2bb183af2e2b295b...

The owner name follows the pattern _<port>._<protocol>.<host>. For inbound SMTP, this is always _25._tcp.<mx-host>. Publishing the record at the domain apex instead of the MX host name is the most common mistake: no MTA finds it.

The four fields

The recommended SMTP combination

3 1 1 remains the de facto standard:

• Usage 3 (DANE-EE): trust is anchored in your key, independent of any certificate authority
• Selector 1 (SPKI): the record stays valid as long as the public key is preserved, even after certificate renewal
• Matching type 1 (SHA-256): 32 bytes, universally supported, robust enough

DNSSEC: the non-negotiable prerequisite

Without DNSSEC, a TLSA record is ignored by any compliant MTA. The checker explicitly caps the score at 30/100 as soon as the DNSSEC chain is broken or missing.

Chain of trust to validate

Root (.) -> TLD (.com) -> Domain (captaindns.com) -> _25._tcp.mail.captaindns.com
   DNSSEC       DNSSEC              DNSSEC                       Signed

Every link must be signed. An unsigned parent zone invalidates everything downstream, regardless of how good the TLSA record itself is. The checker walks the chain and pinpoints the failing link.

Common DNSSEC pitfalls

• Domain zone signed but not the MX host zone: if your MX records point to a subdomain on a separate zone, that zone is the one that must be signed.
• DS records missing at the registrar: a locally signed zone is invisible to external resolvers if the DS record is not pushed up to the TLD.
• Expired RRSIGs: DNSSEC signatures have a validity window. A failed renewal puts the zone in bogus state.

The checker tells you which case is happening.

Key rollover strategies

Rotating certificates without service disruption is the main operational challenge with DANE. Three strategies coexist.

Strategy 1: SPKI selector + key reuse

With --reuse-key (Certbot) or a shared --key-type rsa, the public key stays identical across renewals. The SPKI hash never changes, and the 3 1 1 <spki-hash> record stays valid indefinitely. This is the simplest strategy.

Strategy 2: DANE-TA on the certificate authority

2 0 1 <sha256-of-the-CA-cert>

You pin your CA's root certificate (Let's Encrypt ISRG Root X1 for instance) instead of your own certificate. Upside: no DNS update at renewal. Downside: trust delegated to the CA, so less strict than DANE-EE.

Strategy 3: dual record during transition

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 <current-key-hash>
_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 <next-key-hash>

Publish the next key's hash 7 days before rotation (at minimum twice the maximum TTL). Compliant MTAs accept a connection if at least one record matches the served certificate. After rotation, remove the old hash.

The checker recognizes the presence of multiple records and labels it as an ongoing key rollover rather than an error.

DANE and SMTP: what happens at delivery time

1. The sending server resolves the MX records of captaindns.com
2. It queries _25._tcp.<mx> to retrieve the TLSA record
3. It validates the DNSSEC chain up to the root
4. It opens STARTTLS on port 25 and retrieves the served certificate
5. It computes the hash of the certificate according to the published matching type
6. If the hash matches: secure connection confirmed
7. Otherwise: delivery refused (fundamental difference from opportunistic TLS)

DANE vs opportunistic TLS

Common diagnostics and fixes

No TLSA record found

Cause: the domain has not configured DANE, or the record is published at the wrong location.

Fix: generate and publish a TLSA record at _25._tcp.<mx-host>. Our DANE TLSA installation guide for Postfix, BIND and Let's Encrypt covers the deployment step by step.

DNSSEC missing or broken

Cause: the zone is not signed, or the DS records have not been pushed to the registrar.

Fix: enable DNSSEC at your DNS host, export the DS records, and publish them at your registrar. Verify propagation with a dedicated DNSSEC tool before rerunning this checker.

Certificate hash drift

Cause: the TLS certificate has been renewed and the published hash is no longer up to date.

Fix: use the SPKI selector (1) with --reuse-key to make the record invariant to renewals. Otherwise, update the hash immediately and adopt the dual record strategy for future rotations.

TLSA at the wrong location

Cause: record published at the domain apex instead of the MX host name, or at the wrong port.

Fix: republish at _25._tcp.<mx-host> exactly. For an MX mail.captaindns.com, that is _25._tcp.mail.captaindns.com. Nothing else.

Microsoft 365 / Google Workspace without inbound DANE

Cause: these providers do not sign their DNS zones, so DANE is not applicable on the inbound side.

Fix: deploy MTA-STS instead of DANE for these providers. MTA-STS relies on HTTPS instead of DNSSEC and is supported by Google Workspace and Microsoft 365.

DANE and MTA-STS: complementary approaches

Both protocols form a defense in depth, not an exclusive choice.

Recommendation: deploy both. DANE for domains hosted on Postfix or Exim, MTA-STS for domains delegated to Microsoft 365 or Google Workspace. Maximum coverage requires the combination.

Related tools and resources

Related guides

• DANE TLSA: the complete guide - Understand DANE end to end, from DNSSEC to SMTP deployment.
• DANE TLSA on Postfix, BIND and Let's Encrypt - Step-by-step setup with key rollover.
• DANE TLSA and Microsoft 365 Exchange Online - Inbound and outbound DANE support on Exchange Online.
• DANE TLSA: 12 troubleshooting case studies - Diagnosis and resolution of DANE incidents.
• MTA-STS vs DANE: detailed comparison - Choose or combine the two protocols.

Specifications

• RFC 6698 - DANE TLSA (original specification)
• RFC 7671 - Updates to DANE (operational clarifications)
• RFC 7672 - SMTP Security via DANE (DANE for SMTP)