Why use an offline validator
A malformed TLSA record is ignored without warning by compliant MTAs. You believe your DANE deployment protects your inbound SMTP flow; in practice, no sending server verifies anything. The outage is silent until the next audit, or until a delivery incident exposes the flaw.
The DANE TLSA syntax validator analyzes your record without publishing or querying DNS. No data leaves your browser, no signal leaks to an external resolver. This offline approach covers four use cases that live audits cannot handle.
Typical use cases:
- Before deployment: validate a draft before DNS publication, to avoid a record silently ignored.
- Generator output: check the syntax of a record produced by a third-party tool, an internal wiki or a shared template.
- Offline debugging: reproduce and fix an error without touching public DNS, for example in pre-production.
- Configuration review: examine a record received from a partner or exported from customer infrastructure before applying it.
The validator applies the RFC 6698 specification on structure, and RFC 7671 on operational constraints. No DNS query, no external connection.
How to use this validator in 3 steps
Step 1: paste the TLSA record
Copy the value of your record into the provided field:
3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
You can also paste the full line with the owner name:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af...
The validator extracts the four fields and analyzes each one independently. No network connection is made at this step.
Step 2: read the verdict
Results are ranked by severity:
- Error: blocking issue, the record will be ignored or rejected by compliant MTAs
- Warning: discouraged combination, functional but exposing you to operational risk
- Valid: syntax compliant with RFC 6698 and 7671
Every message includes the affected field, the invalid value, and the expected fix.
Step 3: fix before publication
Adjust your record per the recommendations. Once the syntax is clean, publish the TXT at _25._tcp.<mx-host> in the DNSSEC-signed zone of the MX host, wait for propagation, then confirm live with the DANE TLSA Checker.
Validator or checker: when to use each tool
The two tools are complementary. They cover different moments in the lifecycle of a TLSA record.
| Dimension | Validator (this tool) | Checker |
|---|---|---|
| When to use | Before DNS publication | After publication |
| DNS resolution | None | Live _25._tcp.<mx> resolution |
| DNSSEC verification | No | Yes, full chain |
| Live certificate comparison | No | Yes, via STARTTLS on port 25 |
| Record source | Manual (pasted) | Public DNS |
| Data sent to the server | None | Analyzed domain |
Recommended workflow:
- Design or generate the record, then use the validator to check the syntax
- Publish the TXT in the DNSSEC zone of the MX host, then wait for propagation
- Run the checker to confirm DNSSEC and the live certificate match
The validator catches input errors before publication. The checker catches drift and confirms that the public DNS served matches the certificate currently presented over STARTTLS.
Anatomy of a TLSA record
The TLSA record contains four strictly specified fields.
General structure
_25._tcp.mail.captaindns.com. IN TLSA <usage> <selector> <matching> <data>
| Field | Values | Description |
|---|---|---|
| Usage | 0-3 | Trust anchor |
| Selector | 0-1 | Hashed portion of the certificate |
| Matching type | 0-2 | Comparison algorithm |
| Data | hex | Hash or binary block |
Usage (field 1)
| Value | Name | Description |
|---|---|---|
| 0 | PKIX-TA | CA constraint: the certificate must be signed by this CA AND pass PKIX validation |
| 1 | PKIX-EE | Certificate constraint: exact match + PKIX validation |
| 2 | DANE-TA | Trust anchor: any certificate signed by this CA is accepted |
| 3 | DANE-EE | Domain certificate: exact match, no PKIX validation |
SMTP recommendation: DANE-EE (3). The anchor sits in your key, independent of any external authority.
Selector (field 2)
| Value | Name | Description |
|---|---|---|
| 0 | Cert | Full certificate (DER) |
| 1 | SPKI | SubjectPublicKeyInfo (public key only) |
Recommendation: SPKI (1). The record stays valid as long as the public key is preserved, regardless of certificate renewals.
Matching type (field 3)
| Value | Name | Expected hex length |
|---|---|---|
| 0 | Full | Variable (raw certificate or key) |
| 1 | SHA-256 | 64 characters (32 bytes) |
| 2 | SHA-512 | 128 characters (64 bytes) |
Recommendation: SHA-256 (1). Universally supported, robust enough, compact.
The recommended SMTP combination
3 1 1 is the de facto standard for SMTP DANE.
3 1 1 <sha256-of-the-spki>
- Usage 3 (DANE-EE): no CA dependency, anchor directly in your key
- Selector 1 (SPKI): invariant to certificate renewal as long as the key is preserved
- Matching type 1 (SHA-256): 32 bytes, perfectly suited
Other combinations are possible but discouraged:
| Combination | Status | Why |
|---|---|---|
| 3 1 1 | Recommended | SMTP standard, robust, invariant to renewals |
| 3 0 1 | Tolerated | Hash on the full certificate, changes at every renewal |
| 2 0 1 | Acceptable | DANE-TA on CA, no DNS update at renewal |
| 2 1 1 | Acceptable | DANE-TA on CA SPKI |
| 3 1 0 | Refused | Matching type 0 exposes the raw certificate, massive DNS size |
| 1 x x | Refused for SMTP | PKIX-EE rarely deployable on MTAs |
| 0 x x | Refused for SMTP | PKIX-TA unsuited to SMTP |
The validator explicitly flags out-of-recommendation combinations and suggests the standard combination.
Common syntax errors and fixes
Usage out of range
Cause: usage value greater than 3.
Fix:
- 4 1 1 2bb183af...
+ 3 1 1 2bb183af...
Invalid selector
Cause: selector other than 0 or 1.
Fix:
- 3 2 1 2bb183af...
+ 3 1 1 2bb183af...
Matching type out of range
Cause: matching type greater than 2.
Fix:
- 3 1 3 2bb183af...
+ 3 1 1 2bb183af...
Invalid hexadecimal data
Cause: characters outside the hex range (0-9, a-f, A-F).
Fix:
- 3 1 1 2bg183zf...
+ 3 1 1 2bb183af...
Incorrect hash length
Cause: the data length does not match the matching type.
SHA-256 fix:
- 3 1 1 2bb183
+ 3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
SHA-256 (matching type 1) requires exactly 64 hex characters. SHA-512 (matching type 2) requires exactly 128 characters.
Fragile usage/selector combination
Cause: DANE-EE (3) + Full cert (0) leads to a hash that changes at every certificate renewal.
Recommended fix: switch to SPKI (1) to make the record invariant to renewals (with the --reuse-key ACME option).
- 3 0 1 <hash-of-the-full-cert>
+ 3 1 1 <hash-of-the-public-key>
Incorrect owner name
Cause: record published at the domain apex instead of the MX host, or at the wrong port.
Fix: _25._tcp.<mx-host> exactly. For an MX mail.captaindns.com, that is _25._tcp.mail.captaindns.com.
Preparing a key rollover
Multiple TLSA records in the same zone are not an error: it is the recommended pattern for an interruption-free key rollover.
Clean rollover procedure
- D-7: generate the next key, compute its SPKI hash, publish it as a duplicate:
_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>
-
D-0: perform the certificate rotation with the new key. Compliant MTAs accept the connection if at least one of the two records matches the served certificate.
-
D+7 (or twice the TTL): remove the old record. The rollover is complete.
What the validator checks
The validator processes each record independently and confirms that:
- Every hash respects the length expected by its matching type
- No field is out of valid ranges
- Combinations stay within the recommendations
A duplicate record is never flagged as an error when both are syntactically correct.
DANE and MTA-STS: complementary approaches
| Criterion | DANE | MTA-STS |
|---|---|---|
| Mechanism | DNSSEC + TLSA record | HTTPS + text policy |
| Dependency | DNSSEC required | HTTPS required |
| Trust | Cryptographic (signed DNS) | PKI (HTTPS CA) |
| Postfix / Exim support | Excellent | Good |
| Microsoft 365 / Google Workspace support | Partial to none | Full |
| Deployment | Complex (DNSSEC) | Simpler |
Recommendation: do not choose, deploy both. Validate your TLSA record here, then also publish an MTA-STS policy. Maximum coverage requires the combination.
Related tools and resources
| Tool | When to use it |
|---|---|
| DANE TLSA Checker | Live audit of the record published in DNS, with DNSSEC validation and certificate match |
| DANE TLSA generator | Create a TLSA record from a certificate or a public key |
| MTA-STS syntax validator | Validate the companion MTA-STS policy offline |
| TLS-RPT syntax validator | Validate the companion TLS-RPT record offline |
| Email-authentication audit | Overview of email authentication tools |
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 troubleshooting: 12 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)