DANE and TLSA checker for mail servers

1. 1

   Find the mail servers

   The scan reads the domain's MX records. No MX records means there is nothing for DANE to authenticate, and the checks report Not applicable.

2. 2

   Look up TLSA records

   For each MX host it queries _25._tcp.<host>. Whether the records exist is judged across the whole set: a sender only gets protection when every MX host is covered, and a partly covered set advertises protection that does not hold.

3. 3

   Compare with the live certificate

   Where records exist, the scan connects to the host on port 25, negotiates STARTTLS and checks the certificate it is shown against each TLSA record.

4. 4

   Grade the records themselves

   It checks that the usage, selector and matching type are ones SMTP senders honour, and whether a successor record is published before the current certificate expires.

5. 5

   Check the zone

   TLSA records are only worth anything inside a DNSSEC-signed zone. The scan checks that the zone is signed and that the TLSA records carry a covering signature. The full chain of trust is graded by the DNSSEC checks in the same scan.

Publish a TLSA record for every MX host, at port 25, and sign the zone with DNSSEC (unsigned TLSA records are ignored):
  _25._tcp.mx1.example.com. IN TLSA 3 1 1 0F1E2D3C4B5A69788796A5B4C3D2E1F00F1E2D3C4B5A69788796A5B4C3D2E1F0
  _25._tcp.mx2.example.com. IN TLSA 3 1 1 <sha256 of that host's SPKI>
Use DANE-EE(3) SPKI(1) SHA2-256(1): it survives certificate renewal as long as the key is reused, and does not depend on a public CA. Derive the digest from the live certificate:
  openssl s_client -starttls smtp -connect mx1.example.com:25 </dev/null 2>/dev/null \
    | openssl x509 -noout -pubkey \
    | openssl pkey -pubin -outform DER | openssl dgst -sha256
Publish the new record before rotating a key, and keep both digests during the overlap.

Re-derive the digest from the certificate the server is serving right now and republish:
  openssl s_client -starttls smtp -connect mx1.example.com:25 </dev/null 2>/dev/null \
    | openssl x509 -noout -pubkey \
    | openssl pkey -pubin -outform DER | openssl dgst -sha256
  _25._tcp.mx1.example.com. IN TLSA 3 1 1 <that digest>
Automate this alongside certificate renewal. Publish the incoming record at least one TTL before the certificate changes and remove the old one only afterwards.

The mail server table with TLSA records and match results is part of every report, including the anonymous one. The findings list with this impact and remediation text is part of the signed-in report.

1. 1

   Sign the zone

   DANE depends on DNSSEC. Sign the zone that holds your MX hosts and publish the DS record at your registrar. Until the chain of trust is complete, TLSA records give no protection.

2. 2

   Publish a TLSA record for every MX host

   Use 3 1 1 (DANE-EE, SubjectPublicKeyInfo, SHA-256) at _25._tcp.<mx host>. Derive the digest from the certificate the server serves now, with the openssl command in the finding above.

3. 3

   Plan the next certificate renewal

   Publish the digest of the next key before you rotate, and keep both records during the overlap. Remove the old record only after the new certificate is live and the old record's TTL has passed. Pinning a long-lived key turns renewal into a non-event.

4. 4

   Extend to the submission ports

   If you offer mail submission on ports 587 and 465, publish the same TLSA records at _587._tcp.<host> and _465._tcp.<host> and roll them together with the certificate.

5. 5

   Scan again

   Run the scan once the records have propagated. Every MX host should show a record that matches the certificate, in a signed zone.

Frequently asked questions

What is a TLSA record?

A TLSA record is a DNS record that says which certificate or public key a server on a given port should present. For mail it sits at _25._tcp.<mx host>. A sending mail server that supports DANE looks it up and refuses to deliver if the certificate does not match.

Does DANE need DNSSEC?

Yes. TLSA records are only trustworthy when DNSSEC guarantees the answer. In an unsigned zone an attacker on the path can substitute their own TLSA record, and conforming senders ignore the record rather than trust it.

Does the checker test DANE for my website?

No. It tests the mail servers in the domain's MX records, on port 25, plus a TLSA lookup for the submission ports 587 and 465. TLSA records for HTTPS on port 443 are not checked.

Why did DANE break after I renewed my certificate?

Because the published TLSA record still described the old key. Publish the digest of the next key before you rotate, keep both records during the overlap, and remove the old one only after the new certificate is live and the old record's TTL has expired. Reusing the same key at renewal avoids the problem.

Which TLSA parameters should I use?

For a certificate you manage yourself, use 3 1 1: DANE-EE, SubjectPublicKeyInfo, SHA-256. To pin your issuing CA instead, use 2 1 1 and serve that CA in the chain. Usages 0 and 1 are not defined for SMTP, and matching type 0 means republishing the whole certificate at every renewal.

My domain has no mail servers. Will it fail?

No. A domain with no MX records gets Not applicable for the DANE checks: there is no mail server to authenticate.

Does the scan need me to verify the domain first?

Not for DANE. All six DANE checks run in a plain anonymous scan. Probes of mail client ports, which are a separate set of checks, are the ones that need a verified domain.

Do I need an account?

No. Anonymous visitors get 5 scans a day, and results are kept for 1 hour. The findings list with the full remediation text is part of the signed-in report.

Scan a domain

Keep reading