What does this DANE TLSA checker verify?
A DANE misconfiguration silently blocks mail from security-conscious senders. Government agencies, banks, and major providers validate DANE before delivering. This tool catches problems before they cause rejected mail.
The checker performs five verification steps:
- MX resolution: Identifies the domain's mail servers
- TLSA lookup: Queries
_25._tcp.hostnamefor TLSA records - DNSSEC verification: Confirms the signature chain is complete and valid
- Syntax validation: Checks RFC 6698/7672 compliance for each field
- Certificate match: Connects via STARTTLS and compares the live certificate to TLSA data
Understanding DANE TLSA records
DNS location
TLSA records live at a specific DNS name derived from the mail server hostname, not the domain itself. This is the most common deployment mistake.
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af2e2b295b...
Critical: If captaindns.com has MX mail.captaindns.com, publish the TLSA at _25._tcp.mail.captaindns.com. Publishing at _25._tcp.captaindns.com fails silently.
Record structure
| Field | Values | Meaning |
|---|---|---|
| Certificate Usage | 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), 3 (DANE-EE) | Constraint type |
| Selector | 0 (Cert), 1 (SPKI) | Part of the certificate matched |
| Matching Type | 0 (Full), 1 (SHA-256), 2 (SHA-512) | Comparison method |
| Certificate Data | Hexadecimal | Hash or full data |
Recommended configuration for SMTP
3 1 1 <sha256-hash>
- Usage 3 (DANE-EE): No PKIX validation needed
- Selector 1 (SPKI): Survives renewals with the same key
- Matching Type 1 (SHA-256): Compact and secure
The role of DNSSEC
DANE without DNSSEC is worthless. An unsigned TLSA record offers zero security: any attacker who can manipulate DNS can also forge TLSA data. DNSSEC prevents this.
Chain of trust
DNS Root (.) → TLD (.com) → Domain (captaindns.com) → TLSA record
DNSSEC DNSSEC DNSSEC Signed
Every level of the DNS hierarchy must be signed. One missing link breaks the entire chain. Unsigned TLSA records are treated as nonexistent by compliant MTAs.
What our tool checks
| Check | Description | Impact if failed |
|---|---|---|
| Signed zone | Domain has DNSSEC keys | TLSA records ignored |
| Valid chain | Signatures are verifiable | TLSA records ignored |
| Non-expired signature | RRSIGs are still valid | TLSA records temporarily ignored |
Common issues detected
No TLSA record found
Cause: The domain has not configured DANE Impact: No DANE protection for inbound mail Fix: Generate a DANE TLSA record and publish it in DNS
DNSSEC not enabled
Cause: The domain is not DNSSEC-signed Impact: TLSA records are ignored even if they exist Fix: Enable DNSSEC at your registrar and DNS host
Certificate hash out of sync
Cause: The TLS certificate was renewed without updating the TLSA record Impact: DANE-aware MTAs refuse the connection or fall back to opportunistic TLS Fix: Update the TLSA hash with the new certificate. Use DANE-TA (usage 2) or SPKI selector (1) with key reuse to avoid this issue.
TLSA at the wrong location
Cause: Record published for the domain instead of the MX server
Impact: Sending servers cannot find the record
Fix: Publish at _25._tcp.<mx-hostname>, not at _25._tcp.<domain>
Certificate rotation strategy with DANE
Certificate rotation is the #1 cause of DANE outages. A renewed certificate with a new key invalidates existing TLSA records instantly. Plan your rotation strategy before deploying DANE.
Strategy 1: DANE-TA (best for Let's Encrypt)
Pin the CA certificate instead of the server certificate:
2 0 1 <sha256-of-CA-certificate>
Advantage: The TLSA record survives every renewal, as long as the same CA signs your certificates. Trade-off: Less strict than pinning the exact server certificate.
Strategy 2: DANE-EE with key reuse
Reuse the same private key across renewals:
3 1 1 <sha256-of-public-key>
Advantage: Strongest pinning. The SPKI hash stays constant across renewals.
Trade-off: Requires configuring key reuse (--reuse-key in Certbot). Key compromise requires both certificate and TLSA rotation.
Strategy 3: Dual record rollover
Publish both the current and future TLSA records before rotating the certificate:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <current-cert-hash>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <future-cert-hash>
After rotation, remove the old record. This approach guarantees zero downtime but requires careful coordination.
DANE and SMTP: protecting mail in transit
Without DANE, SMTP encryption is opportunistic: a MitM attacker can strip TLS and read emails in plaintext. DANE makes TLS mandatory and verifiable.
How DANE works for SMTP
- The sending server resolves the MX for
captaindns.com - It queries TLSA records at
_25._tcp.<mx-hostname> - It validates the TLSA response via DNSSEC
- It connects via STARTTLS and compares the certificate to TLSA data
- Certificate matches → secure delivery confirmed
- Certificate mismatch → delivery refused (not downgraded)
Difference from opportunistic TLS
| Aspect | Opportunistic TLS | DANE |
|---|---|---|
| Certificate verification | None (accepts any) | Via TLSA record |
| MITM protection | No | Yes |
| Non-TLS fallback | Yes | No (by default) |
| Prerequisite | None | DNSSEC |
FAQ - Frequently asked questions
Q: What does the DANE TLSA Checker verify?
A: Our checker performs a DNS lookup of TLSA records on your domain, validates their syntax, verifies DNSSEC signature status, checks the match with the mail server certificate, and reports configuration issues.
Q: Why is my DANE TLSA check failing?
A: Common causes: DNSSEC not enabled on the domain, TLSA records not published at the correct location (_25._tcp.mail.captaindns.com), certificate hash out of sync after renewal, or incorrect usage/selector/matching type combination.
Q: What is the correct DNS name for SMTP TLSA records?
A: SMTP TLSA records must be published at _port._protocol.hostname, typically _25._tcp.mail.captaindns.com. The hostname must be that of the target MX server, not the domain itself.
Q: How does DANE protect mail in transit?
A: DANE prevents man-in-the-middle attacks on SMTP connections by letting the sending server verify the TLS certificate via DNS/DNSSEC instead of relying solely on certificate authorities.
Q: How often should I check my DANE TLSA records?
A: Check after every TLS certificate renewal, after any DNS changes, and monthly. Certificate expiration is the number one cause of DANE failures.
Q: Does DANE work with Let's Encrypt certificates?
A: Yes, but plan for 90-day renewals. DANE-TA (usage 2) with the Let's Encrypt CA certificate is easier. DANE-EE (usage 3) with key reuse (--reuse-key in Certbot) works too.
Complementary tools
| Tool | Purpose |
|---|---|
| DANE TLSA Validator | Validate syntax before publication |
| DANE TLSA Generator | Create a TLSA record from a certificate |
| MTA-STS Record Check | Check MTA-STS policy (alternative TLS security) |
| TLS-RPT Record Check | Monitor TLS failures via reports |
| SMTP Check | Check the STARTTLS connection that DANE protects |
| Email domain audit | Complete email authentication audit |
Useful resources
- RFC 6698 - DANE TLSA (original specification)
- RFC 7671 - Updates to DANE (operational updates)
- RFC 7672 - SMTP Security via DANE (DANE for SMTP)
- Microsoft - DANE with DNSSEC (Exchange Online guide)
- Let's Encrypt - Using DANE (DANE tips with LE)