Which mechanism protects what?
SPF, DKIM and DMARC use DNS data. Incorrect responses can affect their evaluation. The receiving destination in the MX record also comes from DNS. An MTA-STS policy, by contrast, is retrieved over HTTPS and announced through DNS; an already known, valid enforce policy does not simply disappear because of a manipulated DNS response. RFC 4033 §§3–4, RFC 8461 §10
On narrow screens, scroll the table sideways.
| Mechanism | What it protects | Key limit |
|---|---|---|
| DNSSEC | Authenticity and integrity of DNS RRsets, including proven non-existence | The consumer of the response must validate it; no encryption or guarantee of correct zone configuration |
| SMTP DANE | Binding the SMTP TLS peer to authenticated TLSA data | The sending MTA must evaluate DANE; this concerns the transport hop, not message content |
| CAA | Permitted certificate issuers under the applicable issuance rules | Applies only to compliant CAs; does not revoke existing certificates |
| DNS hygiene and account protection | Dangling references, delegations and administrative access | Remain necessary even if all DNS responses are validly signed |
Distinguish registrar, DNS host, resolver and mail provider
The registrar manages domain registration and arranges, among other things, delegation and DNSSEC anchoring at the parent. The authoritative DNS host publishes your zone and signs it where applicable. A validating resolver checks responses for its users. The mail provider operates SMTP servers and decides which authentication and transport mechanisms it uses for sending and receiving.
One provider may perform these roles, but does not have to. DNSSEC for your own domain name does not give you control over TLSA records under a third-party MX hostname. If your MX points to mx.provider.example, that operator manages the corresponding TLSA zone. The SPF record must authorise your actual sending services, not automatically your DNS host.
DNSSEC: signatures, chain of trust and failure states
DNSSEC signs groups of records with the same name and type, called RRsets. Resolvers check the signatures using DNSKEY data and a chain of trust to a key previously obtained through a trusted route: the trust anchor. The root trust anchor is usual; local trust anchors are also possible. DS data in the parent zone links the delegation to a key in the child zone. RFC 4033 §§2, 5, RFC 4034
On narrow screens, scroll the table sideways.
| Record | Purpose |
|---|---|
| DNSKEY | The zone's public key; flags, protocol, algorithm and key material |
| RRSIG | Signature over an RRset, including signer, algorithm and validity period |
| DS | Fingerprint of a DNSKEY, published in the parent zone |
| NSEC / NSEC3 | Authenticated proof of absent names or record types; NSEC3 uses hashed names |
The KSK role (signing the DNSKEY RRset) and ZSK role (signing other RRsets) can be separated; a combined key is also possible. Rotation intervals depend on operation. A new key file alone does not make a successful rollover: DNSKEY, signatures, DS and cache lifetimes must fit together. RFC 6781 §§3–4
On narrow screens, scroll the table sideways.
| Validation state | Meaning | Diagnostic implication |
|---|---|---|
| Secure | Chain and required signatures successfully checked | Applies to the checked data, not automatically to the whole domain |
| Insecure | No authenticated protection along this path, for example a correctly unsigned delegation | Do not confuse this with a broken signature chain |
| Bogus | Data should be validatable, but validation fails | Can prevent resolution and mail operation for validating consumers |
| Indeterminate / unknown | Trust information or measurement is insufficient for a decision | Investigate the cause; claim neither success nor absence |
An absent DS can leave a signed zone without protection from its parent. A remaining DS pointing to a key no longer used, by contrast, can break validation. Therefore, do not “remove” DNSSEC by disabling signing while the delegation still points to it. RFC 4033 §5, RFC 6781 §4.3
Schematic explanation · not a measurement
A chain of trust for a particular DNS response
A validating resolver starts from a key trusted in advance. This shows the usual path from the root trust anchor to the domain.
Signed path
- Root trust anchor
Check the root signature over the TLD’s DS record.
-
DS connects the parent zone to the child key
TLDCheck the TLD’s DNSKEY and its signature over the domain’s DS record.
-
Validate the delegation to the domain
DomainCheck the DNSKEY and signature of the queried MX RRset.
-
All required checks successful
Secure for this responseNot blanket evidence for all SPF, DKIM or TLSA names.
Alternative: Insecure
- Proven unsigned delegation branch
This path has no authenticated protection. It is not a broken signature chain.
If MX points to an external host name, that host’s TLSA name needs its own verified chain of trust.
Alternative: Bogus
- Expected validation fails
An invalid chain or signature can prevent resolution for validating users.
Alternative: Indeterminate / unknown
- Insufficient trust information or measurement
Claim neither success nor absence; investigate the cause.
DNSSEC authenticates the DNS data checked; it does not encrypt email or establish that a configuration is appropriate.
Complete description of the flow
A resolver starts with its trusted root key. It checks the root signature over the TLD's DS, then the TLD's DNSKEY and signature over the domain's DS, and finally the domain's DNSKEY and requested MX RRset. The valid path is labelled “secure for this response”. A delegation branch proven to be unsigned ends at “insecure”; an expected but faulty signature ends at “bogus”. A third-party MX hostname branches into its own zone, whose TLSA trust must be established separately. No line treats one MX result as proof that all SPF, DKIM or TLSA names have been checked.
Keep algorithms and denial-of-existence proofs current
RFC 9904 replaced RFC 8624 and moved the authoritative algorithm recommendations to the IANA registries. In the registry read on 27 September 2026, recommended algorithms for DNSSEC signatures include RSA/SHA-256 (8), ECDSA P-256/SHA-256 (13) and Ed25519 (15). The choice must suit the host and any planned migration; an algorithm number alone does not establish a fully verified DNSSEC setup. RFC 9904, IANA
RFC 9905 prohibits new DNSSEC signing with algorithms 5 and 7; under the registry, DS digest type 1 (SHA-1) must no longer be used for delegations. The signature algorithm and DS digest type are separate fields. Section 2 requires resolver operators to treat signature algorithms 5 and 7 as unsupported; without other supported algorithms, the affected responses thus become insecure. At the same time, implementations must continue to provide validation capability. RFC 9905 §§2, 5
NSEC3 does not protect confidentiality: guessable names remain discoverable through dictionary attacks. RFC 9276 recommends NSEC when the specific NSEC3 features are not needed. For NSEC3 it requires zero additional iterations and recommends no salt; it does not recommend opt-out for small zones. Old instructions prescribing 150 iterations and a long salt are not a current basis for this. RFC 9276 §3.1
Resolver operators must maintain their trust anchors. IANA plans to switch to root key KSK-2024 (key tag 38696) on 11 October 2026; on the source review date, this is a planned change. Update according to your resolver distribution's instructions, not using a key file copied from an article. IANA: root trust anchors
DANE: TLSA data must match the actual mail server
SMTP DANE combines DNSSEC with TLS. For mx1.example.com on SMTP port 25, the TLSA RRset is at _25._tcp.mx1.example.com. A common format is:
_25._tcp.mx1.example.com. IN TLSA 3 1 1 <SHA256-DER-SPKI-of-server-certificate>The placeholder is not a publishable hash. The three numbers mean:
On narrow screens, scroll the table sideways.
| Field | Example | Meaning |
|---|---|---|
| Certificate Usage | 3, DANE-EE | Binding to the end-entity certificate; this method needs no additional public PKIX trust path |
| Selector | 1 | SubjectPublicKeyInfo (SPKI), the public key with algorithm information, rather than the entire certificate |
| Matching Type | 1 | SHA-256 over the selected DER-encoded data |
RFC 7672 recommends 3 1 1, alternatively 2 0 1 for a binding to a trust anchor certificate. Usages 0/1 are not the recommended options for opportunistic SMTP DANE. With Usage 2, observe the appropriate certificate chain and further rules for the trust anchor. RFC 7672 §3.1
A local certificate can be evaluated for 3 1 1 as follows; the command does not establish an SMTP connection:
openssl x509 -in server.pem -pubkey -noout |
openssl pkey -pubin -outform DER |
openssl dgst -sha256server.pem must contain the end-entity certificate actually used. Correctly calculating a value from the wrong file does not help. The public key may stay the same or change during certificate renewal; do not rely on an assumed default in your ACME tool.
What the sending MTA decides
For DANE delivery protected against manipulated receiving destinations, the MX data must also be authenticated. The TLSA response for each relevant destination host is then assessed. RFC 7672 §§2.1–2.2
On narrow screens, scroll the table sideways.
| TLSA result | Behaviour of an SMTP DANE sender |
|---|---|
| Secure, with at least one usable record | TLS and successful authentication required; otherwise try another permitted destination or defer delivery |
| Secure, non-empty, but all records unusable | TLS required, DANE authentication impossible; no arbitrary plaintext fallback |
| Insecure or proven absence of TLSA | No DANE requirement follows from this; other transport rules may still require TLS |
| Query/validation failure | Handle the failure path; do not reinterpret it as proven absence permitting plaintext |
Schematic explanation · not a measurement
The TLSA result determines the DANE path
The SMTP DANE sender selects an MX according to SMTP preference. Authenticated MX data and the target host’s TLSA path need separate consideration.
Secure with at least one usable TLSA record
- STARTTLS and certificate matching
TLS and successful authentication are required.
-
A usable TLSA association matches
Transfer possibleOnly after successful matching. On failure: the next permissible target or the queue.
No plaintext fallback on failure.
Secure, non-empty, all TLSA records unusable
- TLS remains required
DANE authentication is not possible with these data; no unrestricted plaintext fallback.
Insecure or proven absence of TLSA
- Check other transport rules
This result supplies no DANE binding. MTA-STS, for example, may still require TLS.
Query or validation error
- Error path
Do not treat it as proven absence or fall back to plaintext. MTA-STS does not override a DANE validation error.
The four paths explain the rules for a DANE sender, not a mail flow measured here.
Complete description of the flow
A sending MTA selects an MX according to SMTP preference, checks its TLSA path and branches into the four cases in the table. With secure, usable TLSA data, the path proceeds through STARTTLS and certificate matching to possible transmission. TLS or matching failures lead to the next permitted destination or the queue, not to plaintext. “No TLSA proven” leads to checking other rules such as MTA-STS. A DANE failure must not be overridden by MTA-STS. The figure shows rules, not mail flow measured here.
DANE and MTA-STS can coexist. MTA-STS is not a way around failed DANE validation. For hosted mailboxes, the mail provider's current support is decisive; the earlier blanket claim that Microsoft 365 publishes no TLSA data is outdated. Microsoft documents inbound SMTP DANE for Exchange Online using appropriately migrated MX names. RFC 8461 §2, Microsoft: SMTP DANE
Change TLSA and keys together
- Record all affected MX hosts, certificates, TLSA parameters and operators.
- Publish the matching future TLSA binding alongside the current one before deploying the new key.
- Wait for the required cache lifetimes. With fixed TLSA parameters, RFC 7671 §8.1 specifies at least two TTLs or longer; consider the actual previous state and signatures.
- Switch the servers and use a DANE-capable client against your own systems to check that the presented chain matches.
- Remove old bindings only after successful migration and once no affected server needs them.
After a failure, reverting to the old server/key state is a suitable recovery route only if its binding is still published and valid. Different TLSA parameter combinations can affect evaluation; it is not enough for just any record to match: the rollover rules for every combination used must be met. RFC 7672 §4, RFC 7671 §8
CAA: restrict certificate issuance
CAA restricts issuance by compliant certification authorities. The CA looks for the applicable CAA RRset for the requested name, following aliases and moving up to parent names if no result is found. Absence of CAA at the exact queried name therefore does not automatically mean unrestricted issuance. RFC 8659 §3
On narrow screens, scroll the table sideways.
| Tag | Purpose |
|---|---|
issue | Permitted issuers for certificates within the applicable scope; also applies to wildcards if no issuewild is present |
issuewild | Separate issuer rule for wildcard certificates |
iodef | Contact for reports about issuance problems; no guarantee of a report |
example.com. IN CAA 0 issue "ca.example"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef "mailto:pki@example.com"ca.example is an invented issuer. Replace it with the value documented by the issuer you actually use. The example policy is intended to allow that issuer and block wildcard issuance. Before changing it, check all affected web, mail and MTA-STS certificates. Excluding the CA in use can prevent its next renewal. CAA does not revoke existing certificates or protect against a compromised CA that ignores the rules. RFC 8659 §§4–5
CAA for public TLS certificates is not automatically a rule for S/MIME or BIMI mark certificates. These have their own tags and issuance rules, such as issuemail for S/MIME and issuevmc for mark certificates. RFC 9495, BIMI
You cannot also publish arbitrary CAA data at a CNAME name. Above all, CAA is not general protection against takeover of the CNAME destination: the relevant lookup follows the alias. RFC 2181 §10.1, RFC 8659 §3
Dangling references and administrative access remain separate risks
Someone controlling an administrative account can have false data validly signed. Someone taking over a dangling service destination may be able to use permissions left in place. An old SPF include can authorise new third-party sending addresses; control over a subdomain's SPF or DKIM can enable a DMARC pass under the same organisational domain with relaxed alignment. This does not mean that every CNAME takeover automatically enables a valid DKIM signature for the main domain. RFC 9989 §11.8
Schematic explanation · not a measurement
An authentically signed reference can still be unwanted
DNSSEC protects the origin of a record. Whether the authorisation it grants is still intended remains an operational question.
Orphaned SPF authorisation
- Service discontinued
The organisation leaves an SPF reference to the service’s domain in place.
-
Control of the referenced target changes
A new operator controls the targetThey can authorise their own senders there.
-
The authorisation was not removed
The old reference remains effectiveYour own zone may still have correct DNSSEC signatures.
Delegation and alignment
- Controlled subdomain
Another operator gains control of a delegated sending domain.
-
Compare authentication with the visible domain
Account for relaxed alignmentA shared organisational domain may suffice for alignment; check the actual sending authorisation.
Countermeasures: remove unused references, control delegations and narrowly limit sending permissions. DNSSEC and CAA alone do not prevent such a takeover.
The authenticity of a DNS reference and the appropriateness of its authorisation are different questions.
Complete description of the flow
An organisation ends a service but leaves an SPF reference to its domain in place. A new operator later controls that destination and authorises its own senders. The original zone may still have valid DNSSEC signatures; the old reference is authentic but unwanted. A second branch shows a controlled subdomain and the condition “shared organisational domain under relaxed alignment”. Countermeasures include removing unused references, controlling delegations and tightly limiting sending permissions. No arrow claims that CAA or DNSSEC alone prevents this takeover.
Maintain an inventory of CNAME, NS, MX and SPF references, with responsibilities and purposes. When ending a service, removing these references is part of decommissioning it. Also check domain renewal, recovery options, strong sign-in and permissions at the registrar and DNS host. Recurring review intervals depend on changes and risk; the RFCs cited here do not impose a blanket quarterly interval. More: Echospoofing and SubdoMailing.
Choose DNS providers and migration methods by capability
Ask about signing, supported algorithms, DS/DNSKEY procedures with your registrar, key rotation, export, incident diagnostics and handover procedures. An interface with a DNSSEC switch does not prove that delegation is complete and every mail path validated. For DANE, the operator of the MX host's zone is also decisive.
On narrow screens, scroll the table sideways.
| Operating model | Prerequisite | Typical risk |
|---|---|---|
| One host signs and operates the zone | Coordinated delegation and key operation | Dependence on the provider and administrative account |
| One signer, multiple authoritative servers | All serve consistent signed zone data; transfer support is actually available | Stale signatures or inconsistent zone versions |
| Multiple signers under RFC 8901 | Coordinated DNSKEY/DS and algorithm configuration according to the chosen model | Unilateral key changes or incompatible responses |
An unsigned secondary is not a reliable fallback for a zone secured through a DS. Specific provider combinations must actually support the required transfers and signing models. RFC 8901
Before migrating: secure an export and recovery route, fully prepare the new zone, agree delegation/DS procedures with both operators, check old and new responses including signatures, and allow for cache lifetimes. A cooperative migration can preserve the chain; other methods may require a deliberately planned temporary unsigned phase. This is not a universal sequence of clicks. Never leave an old DS pointing to keys that have disappeared. RFC 6781 §4.3.5
Verification: distinguish DNS responses, TLS connections and message flow
A DNS tool can show records and status; complete DNSSEC diagnostics require the validation chain. A DANE-capable SMTP client must additionally compare the key actually presented with TLSA. Only a coordinated message test of your own demonstrates the tested sending route. Publish check data with name, record type, time, resolver and result, without inferring overall approval from one sample.
The Email Security Check has the following limits in the product version reviewed here:
On narrow screens, scroll the table sideways.
| Area | Finding obtained | What it does not establish |
|---|---|---|
| DNSSEC | MX and TXT response at the entered name; AD/error signal from a resolver connected within a validating, trusted setup | Our own cryptographic verification from root to zone; all DKIM/SPF destinations, zone roles or your mail provider's resolver operation |
| DANE | TLSA data and resolver validation for no more than three equally preferred MX hosts with the lowest preference number | Complete coverage of all MX levels, certificate matching or successful message transport |
| CAA | Response at the entered name | Complete lookup through all parent names, checking every MTA-STS/web name or permission for actual issuance |
| DNS hygiene | No complete inventory of CNAME/NS references | Detection of all dangling services, provider changes or compromised accounts |
The scanner does not validate DNSSEC signatures itself. The AD bit is meaningful only with an appropriate resolver trust boundary; an arbitrary set bit is insufficient. Authenticated non-existence proves the absence of the requested data, not a functioning mail service. Responses may come from caches. More on the selected SMTP path: MX infrastructure.
DNSSEC and TLSA queries do not consume SPF's limit of ten DNS-triggering terms. That is a separate limit within SPF evaluation, not a shared budget for all email security mechanisms. RFC 7208 §4.6.4
Technical findings and organisational evidence
DNSSEC, DANE and CAA can form part of a security approach. They alone do not establish whether a policy or legal obligation is met. Email compliance covers scope and the documentation needed. An external check replaces neither evidence of actual operation nor incident analysis.
Frequently asked questions
Does DNSSEC encrypt email?
No. DNSSEC authenticates DNS data. TLS protects individual transport connections; end-to-end encryption serves a different purpose again.
Is an unsigned zone automatically bogus?
No. A correctly unsigned delegation can be insecure. Bogus means that expected validation has failed.
Is DNSSEC at my DNS provider enough for DANE?
No. The MX path, zone of the MX hostname, suitable TLSA data, actual TLS server and a DANE-capable sender are decisive.
Can MTA-STS work around a DANE failure?
It must not override failed DANE validation. Correct the wrong binding or server state; plan changes with valid old and new bindings.
Does CAA prevent subdomain takeover?
No. CAA controls certificate issuance by compliant CAs and also follows aliases during lookup. You must remove dangling service references yourself.
Sources and next steps
Standards and registry status checked on 27 September 2026. In addition to the sources in the text: RFC 4035 on validation and AD, RFC 9364 / BCP 237, RFC 6698 on TLSA fields. Examples and local calculations do not replace checking your zone or delivery.
Further reading: SMTP TLS, MTA-STS and TLS-RPT, MX infrastructure and ARC and gateways.