Who says a mail server is really who it claims to be?You're sending something that matters to a business partner. Their mail server picks up the phone. But how do you actually know that server is who it says it is, and not an impostor sitting in the middle? Traditionally, you take a certificate authority's word for it. DANE is the answer that skips the middleman.
⬡ title-card, "DANE for SMTP" fades in over a lighthouse handing off a sealed envelopeDANE stands for DNS-Based Authentication of Named Entities. In plain terms, it lets you publish your mail server's real TLS certificate details straight into your own DNS, so other servers can check who you are without asking a certificate authority to vouch for you. Think of it as posting your official credentials in a public ledger everyone can read.
⬡ record-cards, a DNS zone card lights up with a small certificate icon pinned inside itThe way you post those credentials is a special DNS entry called a TLSA record. It says, in effect, "these are the legitimate certificates for my mail server." That record is the whole foundation of DANE. Get comfortable with it, it's its own video, linked below.
⬡ record-cards, a single TLSA card appears, labelled "the certificates I promise to present"Look it up. Verify it wasn't tampered with. Compare.Here's the flow. Another server wants to deliver mail to you. Before it trusts the connection, it fetches your TLSA record, and it uses DNSSEC to confirm that record wasn't tampered with in transit. Then it compares what you promised in DNS against the certificate your mail server actually presents. Match, the connection is trusted. No match, the mail gets rejected. No quiet fallback.
⬡ auth-flow, sender queries TLSA, DNSSEC seal verifies green, cert compared to record, PASS lights upIf that clicked, subscribe, we're walking through every corner of email authentication, one question at a time.
⬡ title-card, subscribe prompt over the teal auth-flow stillSo why isn't everyone using this. DANE leans entirely on DNSSEC, that security layer that protects DNS itself, and DNSSEC takes real resources to run well. It's popular in Europe and with government agencies that already have that infrastructure. Most large commercial providers, Gmail, Outlook, Yahoo, haven't turned it on for inbound mail. So it's powerful, but not yet widespread.
⬡ split-compare, LEFT "Runs DANE: EU, gov, security-focused" vs RIGHT "No inbound DANE yet: most big commercial providers"So DANE for SMTP is this: you publish your certificate in DNS, DNSSEC keeps that record honest, and senders verify you directly instead of trusting a certificate authority. Strong idea, still a niche tool.
⬡ title-cardNext up, the record that makes all of this work: what a TLSA record actually is, field by field.
⬡ end-card, Subscribe + Next: "What are TLSA records?" (003.008.002)What is DANE for SMTP? DANE (DNS-Based Authentication of Named Entities) lets a receiving domain publish its TLS certificate details in DNS via a TLSA record, so a sending mail server can verify the server's identity without trusting a certificate authority. DNSSEC keeps the record from being forged. In this video: the one-line definition, the role of the TLSA record, the lookup-verify-compare flow, and why DANE is common in Europe and government but rare with big commercial providers like Gmail, Outlook, and Yahoo.
Next: What are TLSA records? → [link 003.008.002]
Compare it to the simpler alternative: What is MTA-STS? → [link 003.007.001]
Full written guide → reviewmyemails.com/emailalmanac/authentication-verification/dane-dns-based-auth-of-named-entities
#email #DANE #deliverability