Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.108.3

use-dane

<domain>

Whether to check the receiver's requirements from DANE records
in the configuration this is a lineuse-dane falseinside the block <domain>
An encryption requirement from the receiver’s DNS zone

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 main trap is turning it on without checking the resolver. The line looks like protection that is on, but without DNSSEC it is not. What needs checking is not the presence of name-server but that the resolver specified there actually returns validated records.
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. There is exactly one reason — the resolver: MTA-STS requires nothing of our infrastructure, while DANE requires DNSSEC on every node in the fleet. It makes sense to enable it only after verification, and preferably for a specific receiver rather than for all.
Recommended values

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 false default, the downgrade ban and the DNSSEC requirement come from the manual (§ 3.3.10.108.3). The order of enabling is ours.
Example configuration
# 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>
The manual’s example. Without the top line the bottom one makes no sense: the manual calls a DNSSEC resolver a strictly mandatory condition.
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 it without a DNSSEC resolver

§ 10.5

What it costsThe mechanism does not provide the protection it was enabled for, but it looks enabled — and ends up in security configuration reports as a working measure.
How to spot itThe behavior does not differ from regular encryption.
How to do it rightCheck the resolver and change it in name-server if necessary. Do not set the line without DNSSEC.

Enabling it for everyone at once in the common recipient block

§ 3.3.10.108.3

What it costsA receiver with broken DANE records stops getting mail — messages pile up in the queue without bounces. In the common block this affects everyone at once.
How to spot itQueues to several receivers grow at the same time, with no bounces.
How to do it rightEnable it for specific receivers and watch for a day. Leave the common block at the default.
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.
Reference data
Syntax
use-dane <boolean>
Values
yes | no | true | false
Default
false § 3.3.10.108.3
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and merges by the usual rule for recipient blocks: the most precise match by receiver name wins. The same three levels apply by sending address — node, <virtual-mta-pool>, <virtual-mta>. The resolver has no levels: there is one name-server for the whole installation.
How to check on the node
First of all — the resolver: does it return validated records at all:
dig +dnssec TXT example.com @8.8.8.8 | grep -c "flags:.* ad"
A one means the resolver is suitable. Next, watch the queue depth to the receiver: when negotiation fails, messages do not bounce but pile up, and this is the only noticeable sign.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Connection encryption