Knowledge base

The receiver declares an encryption requirement in its DNS zone

DANE
The encryption requirement comes from the receiver, not from our configuration

Regular STARTTLS is opportunistic: if encryption works, fine; if not, the message goes out in plain text, and silently. require-starttls forbids that, but the decision is ours, not the receiver’s.

DANE reverses the roles. The receiver publishes records in its zone saying: we have STARTTLS, and here is our certificate’s fingerprint. The node reads these records and acts on them — downgrading to plain text is forbidden by the standard itself, not by our setting.

Not only encryption is verified, but the certificate too — against the fingerprint from DNS, not a chain of certificate authorities. This is the main difference from MTA-STS.

A mandatory condition is a resolver with DNSSEC support. The manual calls this strictly mandatory and gives an example: 8.8.8.8. Without DNSSEC, DANE records deserve no trust, because they can be spoofed.

The message does not bounce but waits. If negotiation fails, the message stays in the queue until STARTTLS succeeds under DANE rules.

The main trap is enabling DANE without checking the resolver. In the configuration it looks like protection that is on; in reality the mechanism makes no sense without DNSSEC. What needs checking is not the presence of the name-server line but that the specified resolver actually supports DNSSEC.
What the Hub does. It does not write it: all blocks of the policy template, including the general one, have the require-starttls plus use-mta-sts combination, and DANE is not enabled. The reason is the resolver — DANE requires DNSSEC, and that has to be checked on each node in the fleet separately. It is worth enabling only after such a check; otherwise the line creates the appearance of protection that does not exist.
Recommended values

The mechanism has no values of its own: it is enabled by use-dane. It is worth comparing with two neighboring methods:

Method Who decides What is verified What it requires
require-starttls we do only encryption nothing
DANE the receiver, through its DNS zone encryption and the certificate fingerprint a DNSSEC resolver
use-mta-sts the receiver, through its website encryption, the chain and the name in the certificate nothing special

They do not exclude each other. A sensible order for a fleet: mandatory encryption by our own hand for large receivers, MTA-STS because it requires nothing, DANE once the resolver is verified.

The mode of operation, the downgrade ban and the DNSSEC requirement come from the manual (§ 10.5). The comparison table of the three methods is ours.
Example configuration
# DANE is meaningless without a DNSSEC resolver — the lines go as a pair
name-server 8.8.8.8
<domain hotmail.com>
    use-starttls yes
    use-dane true
</domain>
The manual’s example with its own comment: the resolver is declared at the node level, and the mechanism itself is enabled per receiver. The order of the lines does not matter; what matters is that both are present.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Enabling DANE with a resolver without DNSSEC

§ 10.5

What it costsThe manual calls a DNSSEC resolver strictly mandatory. Without it DANE records are not protected by anything, and the mechanism does not provide what it was enabled for — while looking enabled in the configuration.
How to spot itThe line is set, and the behavior does not differ from regular STARTTLS.
How to do it rightCheck the resolver with the command from the reference and, if it does not support DNSSEC, change it in name-server — or do not enable DANE.

Expecting a bounce instead of waiting

§ 10.5

What it costsWhen negotiation fails, the message does not bounce but stays in the queue until STARTTLS succeeds under DANE rules. For a receiver with broken records this means a silently growing queue.
How to spot itThe queue to one receiver grows, with no bounces.
How to do it rightWatch queue depth after enabling it. A receiver’s broken DANE is not our problem, but the messages are stuck on our side.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Inheritance
The mechanism itself has no inheritance — the directive that enables it is inherited: use-dane lives in <domain> and merges by the usual rule for recipient blocks, where the most precise match wins. The name-server resolver, however, is set at the node level and has no levels: there is one for the whole installation.
How to check on the node
First the resolver is checked — whether it supports DNSSEC at all:
dig +dnssec TXT example.com @8.8.8.8 | grep -c "flags:.* ad"
A one in the response means the resolver returns validated records (the ad flag). A zero means DANE will not work, no matter how many lines are in the configuration. Next, look at accounting: for a receiver with DANE, messages without a protocol version should not appear at all.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Untangle a stuck queue · Connection encryption