DANE / TLSA Analysis: a beginner's guide

DANE (DNS-Based Authentication of Named Entities) is a standard that lets a domain publish its own TLS certificate fingerprint in DNS, so that other servers can verify the certificate without having to trust the public certificate-authority (CA) system. For email specifically, DANE solves a longstanding problem: when one mail server connects to another over SMTP, it has no reliable way to verify the destination server's certificate using the normal CA chain (the "just look up the root CA" model has no native hook in SMTP). DANE fixes that by letting the recipient domain say, in DNS, "the correct certificate for my mail server has this fingerprint — reject anything else." Defined in RFC 6698 and updated by RFC 7671, DANE has been endorsed by major mail operators including Google, Microsoft, and the IETF as the cert-verification foundation for modern SMTP.

You should care because DANE closes the remaining TLS-verification gap in SMTP and makes cert-rotation mistakes visible instead of silent. Without DANE, a mail server can present a mis-issued or self-signed cert and the sending server has no way to distinguish it from a legitimate one. With DANE, any cert that doesn't match the fingerprint published in DNS is rejected outright. It also makes DNSSEC operationally required for email — because DANE's security rests entirely on the integrity of the TLSA record, which is only trustworthy if DNSSEC signs it.

The four things every DANE check looks at:

• TLSA record presence. Each MX host should have a TLSA record at `_25._tcp.<host>` advertising its certificate fingerprint.

• Certificate usage mode. RFC 6698 defines four modes: 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), and 3 (DANE-EE). RFC 7671 effectively deprecates modes 0 and 1 for DANE — modern deployments use DANE-TA or DANE-EE.

• Matching type and hash algorithm. SHA-256 and SHA-512 hashes are both acceptable; SHA-1 is broken and should never appear. Matching type 0 (exact certificate match) is fragile; type 1 (SHA-256 of the SubjectPublicKeyInfo) is the modern recommendation.

• DNSSEC authentication bit. Without DNSSEC signing the zone, DANE provides zero security — an attacker who can forge DNS responses can simply forge the TLSA record too. Resolvers must see the AD (Authenticated Data) bit before trusting DANE.

Three questions a DANE check answers:

• Is my mail server actually authenticating its peers using DANE, or silently accepting any certificate that passes basic TLS?

• Are my TLSA parameters current, or am I still publishing deprecated modes (0 or 1) that newer mail servers will reject?

• Is DNSSEC actually signing my zone, so that the DANE record I publish can be trusted in the first place?

The cost of skipping DANE is leaving SMTP TLS verification partially unsolved — the cert chain is validated, but the identity of the peer isn't cryptographically pinned to your domain. The fix is to publish TLSA records alongside every DKIM rotation, and verify with public tooling that the record parses cleanly and is covered by the DNSSEC chain. The IETF DANE working group maintains the current specification set, and Let's Encrypt's documentation covers how the free-cert workflow interacts with DANE.

In one sentence: Audit DANE TLSA records for mail and HTTPS (secure HyperText Transfer Protocol) hosts

Analyzes DANE (DNS-Based Authentication of Named Entities, the official internet standard) TLSA records for a domain's MX servers and HTTPS (secure HyperText Transfer Protocol) hosts. Validates TLSA record (TLS (Transport Layer Security) Authentication record) parameters (cert usage, selector, matching type), confirms DNSSEC (Domain Name System Security Extensions) authentication (AD bit), and grades each host's DANE configuration.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

For each MX host (probed at _25._tcp.<host>) and optionally each configured HTTPS (secure HyperText Transfer Protocol) host (_443._tcp.<host>), queries the TLSA record (TLS (Transport Layer Security) Authentication record) via DNS-over-HTTPS. Parses each TLSA record into its the official internet standard fields: certificate usage (0=PKIX-TA, 1=PKIX-EE, 2=DANE-TA, 3=DANE-EE), selector (0=full cert, 1=SPKI), and matching type (0=exact, 1=SHA-256, 2=SHA-512). Flags weak configurations (SHA-1 hashes, cert usage 0/1 which have been deprecated by the official internet standard for DANE), and confirms DNSSEC (Domain Name System Security Extensions) AD bit is set — DANE without DNSSEC provides no security benefit.

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the DANE / TLSA Analysis tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

DANE enables cert-agnostic TLS (Transport Layer Security) verification — the domain cryptographically attests to its own certificate without relying on the public CA system. Google, Microsoft, and Let's Encrypt have all endorsed DANE for SMTP. This endpoint audits DANE deployment so mail operators can catch misconfigurations (missing DNSSEC (Domain Name System Security Extensions), unsupported usage modes, stale hashes) before they cause delivery failures.

Picture this in real life. Imagine an email infrastructure engineer. Here's the situation they're walking into: Verify DANE TLSA records are published for all MX hosts and match the live TLS (Transport Layer Security) certificate, preventing opportunistic TLS downgrades that MTA-STS (Mail Transfer Agent Strict Transport Security) alone cannot stop. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the DANE / TLSA Analysis tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the DANE / TLSA Analysis tool is built for you:

• Will the emails I send actually reach the inbox, or are they going to spam?

• Can someone else send phishing emails pretending to be my domain?

• Have I set up the three rulebooks (SPF, DKIM, DMARC) that mailbox providers now require?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Small-business owners worried about deliverability, marketing managers onboarding a new email service, IT admins prepping for a security audit, and brand teams protecting against phishing. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and your real emails risk landing in the spam folder while scammers find it easier to impersonate your brand. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the DANE / TLSA Analysis tool belongs in your toolbox, this section is for you. Below you'll meet three real people — an email infrastructure engineer, a security engineer, and a compliance officer — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: SMTP DANE Deployment Audit

Imagine you're an email infrastructure engineer. Verify DANE TLSA records are published for all MX hosts and match the live TLS (Transport Layer Security) certificate, preventing opportunistic TLS downgrades that MTA-STS (Mail Transfer Agent Strict Transport Security) alone cannot stop.

Why it matters: Protect inbound email from MITM attacks that bypass MTA-STS (Mail Transfer Agent Strict Transport Security) via DNS (Domain Name System) hijacking.

Story 2: DNSSEC + DANE Rollout Validation

Imagine you're a security engineer. After enabling DNSSEC (Domain Name System Security Extensions) and publishing TLSA records, confirm the AD bit is set and TLSA parameters use the official internet standard-compliant modes (usage 3, SHA-256).

Why it matters: Catch rollout issues before they silently disable DANE verification.

Story 3: Compliance Reporting

Imagine you're a compliance officer. Document DANE support for regulators and customers in regulated industries (healthcare, government) where opportunistic TLS (Transport Layer Security) is insufficient.

Why it matters: Machine-readable evidence of cryptographic attestation over transport encryption.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the DANE / TLSA Analysis tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• When setting up email on a brand-new domain.

• After signing up for a new email-sending service (Mailchimp, SendGrid, HubSpot, etc.).

• When a customer reports that your emails are landing in their spam folder.

• Before a security audit, a SOC 2 review, or a major marketing campaign.

If you can see yourself in even one of those bullets, the DANE / TLSA Analysis tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the DANE / TLSA Analysis tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the DANE / TLSA Analysis tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

You need to provide 2 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with DANE / TLSA Analysis. If you're already running this check, the related ones often answer the next question that comes up:

• DNSSEC Check — Verify DNSSEC signing and validation

• MX Records — Find mail servers and detect email provider

• MTA-STS Check — Validate email transport encryption policy

• Certificate Chain — Validate SSL certificate chain

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check DANE / TLSA Analysis and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

HTTPS (secure HyperText Transfer Protocol) — HTTP with encryption — the little padlock in your browser. It means nobody between you and the website can read what you're sending.

TLSA record (TLS Authentication record) — A DNS entry that pins which HTTPS certificate a domain is allowed to use, as an extra layer of protection beyond regular certificate authorities.

MTA-STS (Mail Transfer Agent Strict Transport Security) — A way to tell other mail servers "always use encryption when sending email to me, and refuse to fall back to unencrypted delivery."

TLS (Transport Layer Security) — The encryption that puts the 'S' in HTTPS. It scrambles data so nobody between you and a website can read it.

DNSSEC (Domain Name System Security Extensions) — A way to digitally sign DNS records so attackers can't trick your computer into looking up the wrong server.

RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.