Skip to content

DANE/DNSSEC Checker

Check if a domain has DNSSEC signing, DANE TLSA records, and MTA-STS configured for secure email transport.

What DANE and DNSSEC do

DNSSEC cryptographically signs DNS responses so a resolver can verify they weren't forged or altered in transit. DANE (DNS-based Authentication of Named Entities) builds on that foundation by publishing a TLSA record that pins a mail server's TLS certificate directly in DNS — so a connecting server can confirm it's talking to the real mail server without trusting a third-party certificate authority at all.

How to read the result

The checker grades a domain's transport security from A to F based on three independent checks: whether DNSSEC is signed, whether DANE TLSA records exist for the mail servers, and whether MTA-STS is configured as a fallback. A domain can score well with either DANE or MTA-STS alone — having both is the strongest configuration, since a connecting server only needs one to refuse an insecure delivery.

Common failure causes

  • DNSSEC was never enabled at the registrar or DNS provider, which blocks DANE entirely.
  • A TLSA record references an old certificate after the mail server's TLS certificate was renewed.
  • Neither DANE nor MTA-STS is configured, leaving inbound mail vulnerable to a downgrade to plaintext.
  • DNSSEC is signed but the DS record was never published at the registrar, breaking the chain of trust.

Frequently asked questions

What is the difference between DANE and MTA-STS?

Both force TLS for inbound mail, but DANE binds a mail server's certificate directly to DNS via a TLSA record, verified through DNSSEC — no certificate authority required. MTA-STS instead relies on a normal CA-issued certificate and an HTTPS policy file. Many domains deploy both, since a receiving server only needs one to honor to skip a plaintext or MITM-able connection.

Do I need DNSSEC before I can use DANE?

Yes. DANE's security guarantee comes entirely from DNSSEC signing the TLSA record, so a resolver can trust that the record wasn't tampered with in transit. Publishing a TLSA record on an unsigned zone provides no real protection — a forged TLSA record and a forged certificate could be substituted together.

What happens if a TLSA record goes stale after a certificate renewal?

Mail servers that support DANE will refuse to deliver, because the certificate presented no longer matches what DNS says is valid — this is the same fail-closed behavior that makes DANE effective against interception. Any TLS certificate rotation on the mail server needs a matching TLSA record update, ideally published before the new certificate goes live.

Keep an eye on this automatically

A one-off check tells you how things look right now. DMARC.WS collects your aggregate reports continuously, shows you which senders are failing authentication, and alerts you when something changes.

Free plan includes 5 domains. No card required.