Demo
Demo

Knowledge base

PMTA knowledge base›Recipe

Encrypt where the receiver requires it

And do not give up on the message where it does not

The task. A client’s messages must not silently go out in plain text when the receiver expected encryption. The default behavior is to encrypt if offered, otherwise send as is and tell no one.

What it is made of:

  • dane — enforcement for receivers that publish signed records with a certificate fingerprint;
  • mta-sts — enforcement for receivers that publish a policy over HTTPS;
  • require-starttls — the blunt option: never downgrade to plain text.

The parts have different scopes. All three are enabled per recipient. DANE needs a resolver with DNSSEC support — this is a node condition, and without it DANE records cannot be trusted.

How they interact. The three parts are ordered by how much they demand from the receiver. Refusing to downgrade demands nothing and will not deliver mail to anyone who does not offer encryption. DANE and MTA-STS work only with those who published requirements themselves, and when the conditions are not met they do not send the message in plain text. They trust different things — signed DNS and a policy over HTTPS — so together they cover more receivers. What the scheme does not give is the number of messages that went out in plain text where nothing was required.

The main trap is require-starttls for all recipients. The line in a common block will not deliver mail to any receiver without STARTTLS — and there are still many of them; enforcement at the receiver’s own request is provided by DANE and MTA-STS.
What the Hub does. It applies two components out of three. use-mta-sts yes is set in all fifteen blocks of the policy template, require-starttls yes only for fourteen large receivers: the general <domain *> has no mandatory encryption (it had until Sep 15, 2026). DANE is not enabled. The result follows the setup: the blunt refusal to downgrade applies where encryption always exists, and the rest get a check by their own policy.
Recommended values

Three methods and what they need:

Method Line What is required of the receiver Node condition
DANE use-dane signed records with a fingerprint a resolver with DNSSEC
MTA-STS use-mta-sts a policy over HTTPS —
no downgrade require-starttls nothing —
The mechanisms, their conditions and the lines come from the manual (§ 10.5, § 10.6, § 3.3.10.108). The scheme itself is our hypothesis.
Example configuration
<domain *>
    use-mta-sts yes
    use-dane yes</domain>
<domain bank.example>
    require-starttls yes
</domain>
Enforcement at the receiver’s request is for everyone, the blunt one only for the recipient for whom plain text is unacceptable.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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.
How to check on the node
Check which mechanisms apply to a recipient:
pmta show settings gmail.com/vmta1 | grep -E '^(use-dane|use-mta-sts|require-starttls) '
require-starttls yes for an arbitrary recipient is a sign of the blunt option for everyone.