Skip to main content

New

Test your email deliverability

Send a test email and get a complete diagnosis of your SPF, DKIM and DMARC authentication in seconds.

  • Real send test
  • Instant diagnosis
  • No signup required

DANE TLSA Validator

Validate your TLSA records before DNS publication

Check your DANE TLSA record syntax before publishing. Our validator checks the certificate usage, selector, and matching type fields, verifies hexadecimal data format, and detects invalid combinations.

Format: usage selector matching-type data (e.g. 3 1 1 followed by the hex hash).

RFC 6698 compliance

Validates your record against the DANE specification. Detects out-of-range values, invalid combinations, and malformed syntax.

DNSSEC check

Reminds that DANE requires DNSSEC to work. Without DNSSEC signatures, TLSA records are ignored by servers.

Instant feedback

Real-time validation as you type. No waiting, no form submission. Immediate results with diagnostic codes.

Detailed diagnostics

Clear explanations for every issue detected. Each error includes the affected field, the invalid value, and how to fix it.

Email TLS security

DANE protects SMTP connections against MITM attacks. Validate your TLSA records to ensure secure email transport.

What is DANE TLSA and why validate the syntax?

A single typo in a TLSA record silently disables DANE protection. Your mail server loses its cryptographic identity, and no error message warns you.

DANE (DNS-based Authentication of Named Entities) binds TLS certificates to DNS names through DNSSEC-signed TLSA records. RFC 6698 defines the protocol. RFC 7671 provides operational updates. Together, they eliminate the dependency on certificate authorities for mail server identity verification.

Syntax validation is critical because:

  • Invalid TLSA records are silently ignored: no DNS error, no log entry
  • A wrong usage field weakens security instead of strengthening it
  • Malformed hexadecimal data renders the entire record useless
  • Incorrect field combinations cause mail delivery failures

Validate before you publish. Use this tool to catch errors that DNS cannot detect.


TLSA record format explained

Basic structure

_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af...
FieldValuesDescription
Certificate Usage0-3Certificate constraint type
Selector0-1Part of the certificate to match
Matching Type0-2Comparison method
Certificate DataHexCertificate data or hash

Certificate Usage (field 1)

ValueNameDescription
0PKIX-TACA constraint: certificate must be signed by this CA AND pass PKIX validation
1PKIX-EECertificate constraint: exact server certificate match + PKIX validation
2DANE-TATrust anchor: accepts any certificate signed by this CA
3DANE-EEDomain certificate: exact server certificate match, no PKIX validation

Recommendation: DANE-EE (3) dominates SMTP deployments. It skips PKIX validation entirely, relying on DNSSEC alone.

Selector (field 2)

ValueNameDescription
0CertFull certificate (DER)
1SPKIPublic key only (Subject Public Key Info)

Recommendation: SPKI (1) survives certificate renewals when the key pair stays the same. Choose it to minimize DNS updates.

Matching Type (field 3)

ValueNameHex length
0FullVariable (full certificate)
1SHA-25664 characters
2SHA-512128 characters

Recommendation: SHA-256 (1) produces a compact 64-character hash with strong collision resistance. It is the standard choice for SMTP TLSA records.


Common syntax errors

Out-of-range usage value

# Incorrect - usage 4 does not exist
3 1 1 2bb183af... → usage must be 0-3

# Correct - DANE-EE (3)
3 1 1 2bb183af...

Invalid hex data

# Incorrect - non-hex characters (G, Z)
3 1 1 2bg183zf...

# Correct - only 0-9, a-f
3 1 1 2bb183af...

Incorrect hash length

# Incorrect - SHA-256 must be 64 hex characters
3 1 1 2bb183

# Correct - complete SHA-256 hash (64 chars)
3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4

Inconsistent usage/selector combination

# Warning - DANE-EE (3) + Cert (0) changes on every renewal
3 0 1 ...

# Recommended - DANE-EE (3) + SPKI (1) survives renewals
3 1 1 ...

DANE configuration for SMTP

Follow these five steps to deploy DANE correctly. Skipping any step risks silent failure.

Step 1: Enable DNSSEC

DANE requires DNSSEC, no exceptions. Without DNSSEC signatures, every MTA ignores your TLSA records. Enable DNSSEC at your registrar and DNS host first.

Step 2: Generate the TLSA record

Use our DANE TLSA Generator to create a record with the correct usage, selector, and matching type.

Step 3: Validate the syntax

Paste the generated record into this validator. Catch format errors before they reach production DNS.

Step 4: Publish to DNS

Add the TLSA record at the correct DNS location: _25._tcp.mail.captaindns.com. Double-check the MX hostname: TLSA goes on the mail server, not the domain.

Step 5: Verify deployment

Run our DANE TLSA Checker to confirm the record is live, DNSSEC-signed, and matches your certificate.


DANE vs MTA-STS: two approaches to TLS security

DANE and MTA-STS solve the same problem, preventing TLS downgrade attacks on SMTP, through different mechanisms.

CriteriaDANEMTA-STS
MechanismDNSSEC + TLSA recordsHTTPS + text policy
DependencyDNSSEC requiredHTTPS required
Trust levelCryptographic (DNSSEC)PKI (HTTPS)
Deployment easeComplex (DNSSEC)Simpler
AdoptionGovernments, financial institutionsBroader (Gmail, Outlook)

Deploy both for maximum coverage. MTA-STS protects connections from senders that lack DANE support. DANE provides cryptographic certainty that MTA-STS cannot match.


FAQ - Frequently asked questions

Q: What is a DANE TLSA record?

A: A DANE TLSA record is a DNS record that binds a TLS certificate to a domain name via DNSSEC. It enables certificate verification without relying solely on certificate authorities, adding a security layer to SMTP connections.


Q: What does the DANE TLSA validator check?

A: Our validator analyzes TLSA syntax: the certificate usage field (0-3), selector (0-1), matching type (0-2), and certificate association data format. It detects invalid combinations and malformed hexadecimal data.


Q: What are the TLSA certificate usage types?

A: Four usage types exist: PKIX-TA (0) CA constraint, PKIX-EE (1) service certificate constraint, DANE-TA (2) trust anchor assertion, DANE-EE (3) domain-issued certificate. DANE-EE (3) is the most common for SMTP.


Q: What is the difference between DANE-TA and DANE-EE?

A: DANE-TA (usage 2) pins a certificate authority, allowing certificate rotation without DNS updates. DANE-EE (usage 3) pins the specific server certificate, offering stronger security but requiring a DNS update on renewal.


Q: Does DANE require DNSSEC?

A: Yes, absolutely. Without DNSSEC, TLSA records cannot be authenticated. The DANE security model relies entirely on DNSSEC to guarantee DNS response integrity.


Q: Can I use DANE with Microsoft 365 or Google Workspace?

A: Microsoft 365 supports DANE with DNSSEC for inbound mail (Exchange Online). Google Workspace does not yet support DANE for receiving. Both platforms support DANE validation when sending to DANE-enabled recipients.


Complementary tools

ToolPurpose
DANE TLSA CheckerVerify TLSA record deployed in DNS
DANE TLSA GeneratorCreate a TLSA record from a certificate
MTA-STS Record CheckCheck MTA-STS policy (alternative TLS security)
TLS-RPT Record CheckMonitor TLS failures via reports
Email domain auditComplete email authentication audit

Useful resources