DANE
DNS-Based Authentication of Named Entities: a TLSA record in DNSSEC-signed DNS that states which certificate a mail server must present, removing reliance on public certificate authorities. Defined in RFC 6698 and RFC 7672 for SMTP.
DNS-Based Authentication of Named Entities. The other way to require TLS for inbound mail.
DANE publishes a TLSA record stating which certificate, or which issuing key, your mail server will present. A sending server that supports DANE checks the presented certificate against it and refuses to deliver on a mismatch.
It requires DNSSEC. Without signed DNS an attacker could simply forge the TLSA record, so the whole mechanism rests on the chain of trust being intact.
Compared with MTA-STS: DANE is stronger, because it does not trust the public certificate authority system, and harder to deploy, because it needs DNSSEC and careful certificate rotation. MTA-STS needs no DNSSEC and is trivial to publish. Large providers differ on which they support, and publishing both is a legitimate position.
Related
- DNSSECDomain Name System Security Extensions: cryptographic signatures on DNS records that let a validating resolver confirm an answer came from the real zone and was not altered. Defined in RFC 4033 through RFC 4035.
- MTA-STSSMTP MTA Strict Transport Security: a policy published over HTTPS and announced in DNS that tells sending servers to require TLS and to accept only named mail exchangers for a domain. Defined in RFC 8461.
- TLS-RPTSMTP TLS Reporting: a DNS record asking sending servers to send daily reports about failures to establish a secure connection to a domain's mail servers. Defined in RFC 8460.
- DNSSEC TestSigned, validating, or signed-with-a-broken-chain, the three states that matter.
Every fix on this site is yours to implement. If you would rather someone did it, I take this work directly.