<domain>
The line enables working with DANE records for this receiver. The node looks into its zone, learns whether it requires STARTTLS, and checks the presented certificate against the fingerprint from DNS.
Downgrading to plain text is forbidden by the mechanism itself. If the receiver requires encryption and it could not be negotiated, the message will not go out — and will not bounce either, but will stay in the queue until it succeeds.
A mandatory condition is a resolver with DNSSEC. The manual calls it strictly mandatory: without DNSSEC, DANE records can be spoofed, and the whole point of the check is lost. The resolver is set with the name-server line at the node level.
The default is false.
The value is boolean, but the decision is about infrastructure:
| Value | When |
|---|---|
| false (default) | the DNSSEC resolver has not been verified |
| true | the resolver is verified, and the receiver publishes DANE records |
The order of enabling. First check the resolver, then enable it for one receiver, watch the queue depth for a day, then expand. The line is not put in <domain *>: broken records at one receiver will then stop mail only to that receiver, not to everyone.
# the DNSSEC resolver at the node level, the mechanism itself per receiver name-server 8.8.8.8 <domain hotmail.com> use-starttls yes use-dane true</domain>
what people get wrong and how it ends2 mistakes▶
§ 10.5
§ 3.3.10.108.3
3 relations
dig +dnssec TXT example.com @8.8.8.8 | grep -c "flags:.* ad"
3 articles
◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.