Knowledge base

The receiver declares an encryption requirement on its website

MTA-STS
The receiver’s policy, fetched over HTTPS

The mechanism has two steps: the node asks DNS for the policy ID, then fetches the policy itself over HTTPS from mta-sts.<domain>/.well-known/mta-sts.txt.

If the policy is in enforce mode, the message goes out only if three conditions are met at once: the receiver’s address matched at least one MX pattern from the policy; the connection is encrypted; the node verified both the certificate chain and the server name in it.

testing mode forbids nothing — the node will deliver the message even if the MX does not match. This matters during an investigation: the policy exists, but the behavior is ordinary because the receiver has not turned on enforcement yet.

Certificates are verified against the list shipped with the distribution — Mozilla CA — and it can be replaced with your own via smtp-tls-ca-file. The node does not check certificate revocation, and it does not support TLS reports (RFC 8460) at all.

The policy is cached for the period stated in it and refreshed once a day. That is, changes at the receiver do not reach us instantly.

And a separate rule about queue rollup: if the receiver enforces MTA-STS, queues are rolled up only when all the MX being rolled up are allowed by its policy. Otherwise there will be no rollup.

The main trap is taking the receiver’s policy for working protection without looking at its mode. mode: testing is common: a domain publishes a policy to look at reports and requires nothing. Our enabled line changes nothing at such a receiver — and that is normal, not a malfunction.
What the Hub does. It writes yes in all fifteen blocks of the policy template, including the general one; for large receivers next to require-starttls, in the general block without it: there encryption is mandatory only for those who declared it with an MTA-STS policy. The choice is deliberate: unlike DANE, MTA-STS requires nothing of our infrastructure — no DNSSEC, no special resolver — while performing a stricter check than just mandatory encryption: both the chain and the name in the certificate are verified.
Recommended values

The mechanism has no values of its own: it is enabled by use-mta-sts. What is worth knowing about the behavior:

Receiver’s policy mode What the node does
enforce delivers only when the MX matches, the connection is encrypted and the certificate is verified
testing delivers in any case — the policy requires nothing
no policy delivers as usual

What the mechanism does not do: it does not check certificate revocation and does not send TLS reports. These cannot be relied on.

The three delivery conditions, the policy modes, caching and the queue rollup rule come from the manual (§ 10.6). The comparison with DANE by infrastructure requirements is ours.
Example configuration
# a large receiver gets mandatory encryption and policy verification
<domain hotmail.com>
    use-starttls yes
    require-starttls yes
    use-mta-sts yes</domain>
The lines complement each other: require-starttls always requires encryption, MTA-STS adds MX and certificate verification — but only if the receiver published a policy in enforce mode.
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 ends3 mistakes▶

Treating the enabled line as a working check

§ 10.6

What it costsThe check depends entirely on the receiver’s policy. If there is no policy or it is in testing mode, the behavior is ordinary, and there is no additional protection.
How to spot itThe setting is on, but nothing has changed in accounting.
How to do it rightLook at the receiver’s policy with the command from the reference. Your own mandatory encryption is provided by require-starttls, not by this line.

Forgetting about the interaction with queue rollup

§ 10.6

What it costsWith an enforcing policy, queues are rolled up only if all the MX being rolled up are allowed. A single mismatch — and there will be no rollup at all, while the load calculation was built on it.
How to spot itThe expected rolled-up queue does not appear, and messages go through separate per-domain queues.
How to do it rightCompare the MX patterns from the receiver’s policy with the rollup list. This is not a configuration error but documented behavior.

Counting on certificate revocation checking

§ 10.6

What it costsThe node verifies the chain and the name, but does not check revocation. A revoked but not yet expired certificate will pass the check.
How to spot itIt surfaces during a requirements review, not in operation.
How to do it rightDo not consider MTA-STS a full verification of the receiver’s authenticity. The node does not look at revocation and does not send TLS reports.
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-mta-sts lives in <domain> and merges by the usual rule for recipient blocks, where the most precise match wins. The policy cache is shared by the node and does not depend on the blocks.
How to check on the node
The check starts with the receiver’s own policy — whether it exists and in which mode:
curl -s https://mta-sts.gmail.com/.well-known/mta-sts.txt
The line mode: enforce means the verification actually works; testing means the receiver requires nothing, and our enabled setting will change nothing. No response means there is no policy.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Tune the pace for a provider · Connection encryption