Look up TLSA
Enter a domain and the tool follows its MX records. Enter a mail host directly (mx1.example.com) to check that host alone.
How it works
MX
The domain's MX records are fetched and sorted by preference. A bare hostname is checked as a mail host directly.
TLSA
For each host, the TLSA record at _25._tcp is fetched. Each record is split into usage, selector, matching type and digest.
DNSSEC
The resolver's AD flag on the zone tells you whether a validating sender would trust the records at all.
Read
3 1 1 is the recommended shape. Anything with usage 0 or 1, matching type 0, or an unsigned zone is flagged.
What DANE for SMTP does
Ordinary TLS between mail servers is opportunistic: the sender encrypts if it can, and falls back to plaintext if it cannot, and it does not check that the certificate belongs to anyone in particular. DANE lets the receiving domain publish a fingerprint of the certificate or key in DNS, under the MX hostname, and a DANE-aware sender refuses to deliver unless the server presents a matching key. Because the record lives in DNS, the whole thing only works if DNS itself is authenticated — which is why DANE requires DNSSEC.
Reading a TLSA record
A record like 3 1 1 2a7f… has four parts. Usage 3 means the record identifies the end-entity certificate itself, ignoring the CA chain. Selector 1 means it matches the public key rather than the whole certificate, so a renewed certificate with the same key still validates. Matching type 1 means the digest is SHA-256. That combination, 3 1 1, is what RFC 7672 recommends and it is what almost every working deployment uses. 2 1 1 pins an issuing CA instead and is the other acceptable pattern.
Who uses it
DANE is well established among German, Dutch and Scandinavian providers, in government mail, and on self-hosted Postfix. Google and Microsoft do not publish TLSA for their MX hosts and, as senders, Google does not enforce it; Microsoft 365 added outbound DANE validation in 2024. For a cold email fleet on Workspace this tool is diagnostic rather than something to configure — but if a client's domain is on a provider that publishes TLSA, a broken record will cause hard delivery failures from DANE-aware senders that no other tool will explain.
The failures that matter
TLSA records with the zone unsigned, which every sender ignores. A record on the primary MX but none on the secondary, so failover mail is delivered without authentication. A digest that no longer matches after a certificate was rotated with a new key. And a domain that was moved off a DANE-publishing provider with the old TLSA records left behind at the new DNS host, which makes strict senders refuse to deliver at all.
Frequently asked questions
What is a TLSA record?
A DNS record under _port._protocol.hostname — for mail, _25._tcp.mx.example.com — that publishes a hash of the certificate or public key the server will present. It is the record DANE is built on.
Does DANE work without DNSSEC?
No. A sender that cannot validate the DNS answer treats the TLSA record as absent. Unsigned TLSA records are harmless but do nothing.
Should I add TLSA to my Google Workspace domain?
You cannot, usefully — Google's MX hostnames are Google's, and you do not control the certificates. Use MTA-STS instead, which Google and Microsoft both honour.
Why 3 1 1?
Usage 3 checks the server certificate directly, selector 1 checks the public key so renewals with the same key keep working, matching type 1 is SHA-256. It is the least fragile combination.
What does DANE-EE versus DANE-TA mean?
DANE-EE (usage 3) pins the server's own certificate or key. DANE-TA (usage 2) pins a CA that must appear in the chain the server sends, so any certificate that CA issues will validate.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace — Silver Partner
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.