DANE / TLSA Analysis
developer/v1/security/daneAnalyzes DANE (DNS-Based Authentication of Named Entities, RFC 6698) TLSA records for a domain's MX servers and HTTPS hosts. Validates TLSA record parameters (cert usage, selector, matching type), confirms DNSSEC authentication (AD bit), and grades each host's DANE configuration.
What It Does
For each MX host (probed at _25._tcp.<host>) and optionally each configured HTTPS host (_443._tcp.<host>), queries the TLSA record via DNS-over-HTTPS. Parses each TLSA record into its RFC 6698 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 RFC 7671 for DANE), and confirms DNSSEC AD bit is set — DANE without DNSSEC provides no security benefit.
Why It's Useful
DANE enables cert-agnostic TLS 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, unsupported usage modes, stale hashes) before they cause delivery failures.
Use Cases
SMTP DANE Deployment Audit
Verify DANE TLSA records are published for all MX hosts and match the live TLS certificate, preventing opportunistic TLS downgrades that MTA-STS alone cannot stop.
Protect inbound email from MITM attacks that bypass MTA-STS via DNS hijacking.
DNSSEC + DANE Rollout Validation
After enabling DNSSEC and publishing TLSA records, confirm the AD bit is set and TLSA parameters use RFC 7671-compliant modes (usage 3, SHA-256).
Catch rollout issues before they silently disable DANE verification.
Compliance Reporting
Document DANE support for regulators and customers in regulated industries (healthcare, government) where opportunistic TLS is insufficient.
Machine-readable evidence of cryptographic attestation over transport encryption.
Parameters
| Name | Type | Required | Description |
|---|---|---|---|
domain | string | Required | The domain whose MX hosts (and optionally HTTPS hosts) should be analyzedExample: example.com |
ports | string | Optional | Comma-separated list of ports to probe per host. Defaults to 25 for MX. Add 443 to include the HTTPS host at the apex.Example: 25,443 |
Response Fields
| Field | Type | Description |
|---|---|---|
domain | string | The queried domain |
has_dnssec | boolean | Whether the domain's TLSA query responses carried the DNSSEC AD bit |
hosts | array | Per-host TLSA analysis with records, grade, and findings |
summary | object | Counts: hosts_total, hosts_with_tlsa, hosts_fully_validated |
overall_grade | string | Overall DANE deployment grade: A, B, C, D, F |
findings | array | Aggregate findings with severity |
recommendations | array | Remediation steps |
Code Examples
curl "https://api.edgedns.dev/v1/security/dane" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d "domain=example.com"const response = await fetch(
'https://api.edgedns.dev/v1/security/dane?domain=example.com',
{
headers: {
'Authorization': 'Bearer YOUR_API_KEY'
}
}
);
const data = await response.json();
console.log(data);import requests
response = requests.get(
'https://api.edgedns.dev/v1/security/dane',
headers={'Authorization': 'Bearer YOUR_API_KEY'},
params={
'domain': 'example.com'
}
)
data = response.json()
print(data)Read the full DANE / TLSA Analysis guide
Why it matters, real-world use cases, parameters, response fields, and how to call it from Claude, ChatGPT, or Gemini via MCP.
Read the guide →Related Endpoints
External References
Learn more about the standards and protocols behind this endpoint.
Try This Endpoint
Test the DANE / TLSA Analysis endpoint live in the playground.