DANE and TLSA record checker
Check whether senders can authenticate a domain’s mail servers with DANE: TLSA records per MX host, DNSSEC, record syntax and rollover, each with a fix.
By using these tools you accept the Terms and the Privacy page.
Compare a certificate
The check above compares each mail server’s live certificate automatically. To test another one (the next key, before a rollover), paste the certificate, full chain or public key in PEM form. Your browser hashes it, shows which TLSA records match, and writes the records to publish. Nothing is sent.
How the DANE checker grades a domain
The DANE checker tests whether sending servers can authenticate a domain’s mail servers with TLSA records (RFC 7672). It is for mail administrators who publish TLSA records, or plan to, and want to be sure DANE-aware senders accept the setup.
What it checks, step by step
- The MX records and whether DNSSEC signs them. A null MX on its own ends the check.
- The A and AAAA records of up to 8 mail servers, in MX preference order, and whether those are signed. If a server name is a CNAME with a signed chain, TLSA records are looked up at the target first, then at the server name (RFC 7672 §2.2.3).
- Each server’s TLSA records, parsed, explained in plain words and marked usable or ignored, with the reason.
- The live certificate of up to 4 servers with usable records. A DANE-EE record must match the server’s own certificate or key; names and dates don’t matter. A DANE-TA record must match a CA certificate the server sends, and the server’s certificate must be signed through it, name the server and be in date.
- When a resolver answers SERVFAIL, a second query with DNSSEC checking turned off tells broken signatures apart from an outage.
- The whole check stops at 25 seconds: anything slower is “couldn’t check”, and that result isn’t cached.
How the grade works
A+ means every mail server has usable, signed TLSA records, the MX records are signed, and nothing needs attention; a warning makes it A. B: the servers use DANE, but the MX records aren’t signed. C: only some servers are covered. D: TLSA records exist, but DNSSEC doesn’t protect them, so senders skip them. F: DANE is broken, because DNSSEC fails, no record is usable, a live certificate doesn’t match or STARTTLS is missing. A domain without TLSA records gets no grade, just the next steps, and neither does a check where a lookup failed.
Problems it catches
- A live certificate that matches no record, usually after a key change. DANE senders keep the mail queued; the finding gives the
3 1 1record for the key now in use. - Mail servers whose own DNS isn’t signed. DANE can’t be added for them; if they are your provider’s, only the provider can enable it.
- A hash of the wrong length. A SHA-256 value has 64 hex digits; any other length can never match.
- Selector 0 with usage 3. It pins the whole certificate, so the record breaks at every renewal.
Testing a key before a rollover
The comparison box below the results takes a certificate, chain or public key in PEM form, shows which published records match it, and writes the records to publish. Each server’s details also include an openssl s_client command for a check from your own machine. For the rest of the server’s TLS setup, run the TLS checker on port 25.
Updated · Maintained by Liviu Tanase
Questions
What is DANE for email?
DANE (RFC 7672) lets a domain publish, in DNSSEC-signed DNS, which certificate or key its mail servers use. A sending server that supports DANE then insists on TLS and checks the certificate against those TLSA records, so an attacker can’t strip encryption or present a fake certificate. Without DANE (or MTA-STS), server-to-server TLS is opportunistic and can be downgraded.
Where do TLSA records live?
At _25._tcp. followed by each MX host name, for example _25._tcp.mail.example.com. Port 25 is SMTP. If an MX host name is a CNAME, senders look first under the name it points to, then under the original name. If a domain has no MX records, the domain itself is the mail server.
Which TLSA record should I publish?
3 1 1: DANE-EE (your server’s own key), SPKI (the public key, not the whole certificate), SHA-256. It needs no CA and keeps working across renewals that reuse the key. 2 1 1 (a CA’s key) is the second choice; the server must then send that CA certificate in its chain. Usages 0 and 1 aren’t meant for SMTP.
How do I create a 3 1 1 TLSA record?
Paste the server’s certificate or public key into the comparison box below the results: your browser computes the SHA-256 of the public key and writes the line to publish, _25._tcp.mail.example.com. IN TLSA 3 1 1 <hash>. If the live certificate matches no record, the finding gives that line too. For the rest of the server’s TLS setup, run the TLS checker on port 25.
Why does DANE need DNSSEC?
Without signatures an attacker who can tamper with DNS could replace the TLSA records too. So senders ignore TLSA records that aren’t DNSSEC-validated, and they don’t look up TLSA records for a mail server whose address records aren’t signed. Sign the zone and publish the DS record at your registrar first.
How do I change certificates without breaking mail?
Publish the new key’s TLSA record next to the old one, wait at least two TTLs, switch the certificate, then remove the old record. Reusing the private key at renewal (for example certbot --reuse-key) keeps a 3 1 1 record valid with no DNS change.
Why does a server show “couldn’t check”?
Each check has a 25-second limit. A DNS lookup that fails or answers too late, or a mail server that doesn’t finish the SMTP greeting and TLS handshake in time, is marked “couldn’t check” instead of guessed. Such results get no grade and aren’t cached, so Check again retries at once. Some servers wait several seconds on purpose before greeting a new client, so their live check is slower.
Do I need DANE if I have MTA-STS?
They protect the same hop in different ways and work side by side. DANE needs DNSSEC and pins keys in DNS; MTA-STS needs no DNSSEC but trusts public CAs and an HTTPS policy file. A sender that supports both relies on DANE (RFC 8461). The deliverability score checks MTA-STS and TLS-RPT next to DANE.
Does this checker connect to my mail server?
Briefly, and only servers that publish TLSA records: it connects on port 25, asks for STARTTLS, reads the certificate chain and disconnects. No mail is sent. The connection comes from a scanner on Cloudflare’s container platform, because Cloudflare Workers can’t open port 25. DNS is read through Cloudflare and Google. The comparison box hashes a pasted certificate in your browser and sends nothing. zerobounce.ai’s own logs don’t keep the domain you check; Cloudflare’s request logs do, as the privacy page explains.