Instantly look up TLSA records for any domain, check your DANE DNS configuration, and verify certificate usage fields, free, no signup required.
The DANE Record Checker looks up TLSA records for your mail server and verifies DNSSEC status, the foundation for DNS-based Authentication of Named Entities (DANE).
DANE lets mail servers publish TLS certificate or public-key associations in DNS, so senders can verify they are connecting to the correct server without relying solely on public CAs.
Find TLSA records published at _port._protocol.mxhost for your primary MX server.
Check whether DNSSEC is validated, required for DANE to be trustworthy.
See usage, selector, matching type, and certificate hash data for each TLSA record.
Get specific next steps when TLSA or DNSSEC records are missing or misconfigured.
Provide your domain, SMTP port (default 25), and protocol (TCP, UDP, or SCTP).
The tool finds your primary MX host and queries _25._tcp.mxhost for TLSA records.
DNSSEC validation status is verified via the AD flag in DNS responses.
Read TLSA details, validation messages, and recommendations for your setup.
DANE requires both TLSA records on your MX host and validated DNSSEC on the domain. Without DNSSEC, TLSA records cannot be trusted.
TLSA records exist with DANE-TA or DANE-EE usage and DNSSEC is validated.
No TLSA record at the query name, DANE cannot be enforced for this mail service.
TLSA may exist but DNSSEC is missing or unvalidated, senders cannot trust DANE data.
PKIX-TA/PKIX-EE usage records used for certificate rollover, N/A if none are published.
Found or Not Found, whether TLSA records exist at the query name.
Detected, Signed (unvalidated), or Not Detected, DNSSEC chain validation status.
The TLSA lookup name, e.g. _25._tcp.mail.example.com.
PKIX-TA, PKIX-EE, DANE-TA, or DANE-EE, how the certificate association is applied.
Certificate (full cert) or SPKI (public key), what the association data matches.
Full certificate, SHA-256 hash, or SHA-512 hash of the association data.
DANE is only meaningful with validated DNSSEC, enable and verify DNSSEC before publishing TLSA.
Usage values 2 (DANE-TA) or 3 (DANE-EE) are required for DANE enforcement, not PKIX modes alone.
Publish rollover TLSA records before renewing certificates to avoid delivery interruptions.
DANE and MTA-STS address different layers, many organizations use MTA-STS for broad coverage and DANE where DNSSEC is available.
DNS-based Authentication of Named Entities lets you publish TLS certificate or public-key fingerprints in DNS (TLSA records) so senders can verify your mail server identity.
TLSA records in unsigned DNS could be spoofed. DNSSEC ensures senders receive authentic, untampered TLSA data.
A DNS record at _port._protocol.hostname containing certificate association data, usage, selector, matching type, and hash or certificate bytes.
No. This tool checks DNS records and DNSSEC only. Certificate hash matching requires a live TLS handshake, which is not performed here.
Port 25 (SMTP) is the default for inbound mail. Use the port your MX server accepts TLS connections on.
Additional TLSA records with PKIX-TA or PKIX-EE usage published before certificate renewal so senders accept both old and new certificates during transition.
Adoption is growing but less universal than MTA-STS. DANE is most valuable when your DNS zone has full DNSSEC deployment.
The tool requires MX records to determine which host to query for TLSA. Add MX records or check the correct domain.
SenderSignal monitors these signals continuously: 48 blacklists, SPF, DKIM, DMARC, TLS and more, with alerts in Slack, email and signed webhooks.