Demo
Demo

Knowledge base

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

use-mta-sts

<domain>set by the Hub

Whether to verify the connection against the receiver's MTA-STS policy
in the configuration this is a lineuse-mta-sts falseinside the block <domain>
Verification against the policy the receiver publishes

The line enables working with the MTA-STS policy for this receiver. The node finds it through DNS and fetches it over HTTPS, then acts according to its mode.

In enforce mode there are three conditions, and all are required: the receiver’s address matched an MX pattern from the policy; the connection is encrypted; the node verified the certificate chain and the server name in it. If any one is not met, the message will not go out.

In testing mode nothing is forbidden. The node will deliver the message even if the MX does not match — that is by design, and during an investigation it is the first thing worth checking.

The default is false.

There is a consequence for queue rollup. With 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.

The main trap is assuming the line guarantees something by itself. It enables verification of the receiver’s policy, not mandatory encryption. A receiver without a policy or with a policy in testing mode will get messages exactly as before. Mandatory encryption on our side is require-starttls, and both lines are needed.
What the Hub does. It writes yes in all fifteen blocks of the policy template, including the general one. For large receivers it sits next to require-starttls: encryption is mandatory by our decision, and MTA-STS adds MX and certificate verification. The general block has no mandatory encryption, and MTA-STS is the only thing there that requires it: for the receivers that declared it themselves. Unlike DANE, MTA-STS requires nothing of our infrastructure.
Recommended values

The value is boolean, and it is worth enabling together with its neighbor:

What is set What you get
only require-starttls encryption is guaranteed, the receiver is not verified
only this line verification exists, but only at receivers with an enforce policy
both (our choice) encryption always, plus verification where the receiver requires it

It can be set broadly. Unlike use-dane, this line requires nothing and simply does not trigger at receivers without a policy.

The false default, the three delivery conditions and the queue rollup rule come from the manual (§ 3.3.10.108.4). The advice to enable it in a pair and broadly is ours.
Example configuration
# this is exactly how it is in the Hub's policy template — three lines
<domain $mailru>
    use-starttls yes
    require-starttls yes
    use-mta-sts yes</domain>
Each line is responsible for its own part: the first allows encryption, the second makes it mandatory by our decision, the third adds verification by the receiver — if the receiver requires it.
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▶

Using it instead of mandatory encryption

§ 10.6

What it costsThe line enables policy verification, not encryption. At a receiver without a policy the message will go out in plain text exactly as before — even though “MTA-STS is enabled.”
How to spot itIn accounting, some receivers have an empty protocol version field.
How to do it rightPut require-starttls next to it. These are two different guarantees, and both are needed.

Not accounting for the impact on 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 load calculation built on rollup stops adding up.
How to spot itThe expected rolled-up queue does not appear.
How to do it rightCompare the MX patterns from the policy with the rollup list. This is documented behavior, not a failure.
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-mta-sts <boolean>
Values
yes | no | true | false
Default
false § 3.3.10.108.4
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 policy cache is shared by the node and does not depend on the blocks.
⇄

Related directives

2 relations

Does not work without

use-starttls<domain>The receiver’s policy requires an encrypted connection: without one the verification is bound to fail. § 3.3.10.108.4

Can be replaced by

use-dane<domain>The second scheme with the same purpose; this one requires nothing of our infrastructure, while that one needs a DNSSEC resolver. § 3.3.10.108.4

Referenced from

The receiver declares an encryption requirement on its websiteThe line that enables the mechanism for a specific receiver. § 10.6

How to check on the node
Look at the receiver’s own policy — everything depends on it:
curl -s https://mta-sts.gmail.com/.well-known/mta-sts.txt
mode: enforce means the verification works; mode: testing means the receiver requires nothing, and our line changes nothing; an empty response means there is no policy. In all three cases our own encryption requirement is provided by require-starttls, not by this line.
◇

What else to read

3 articles

◇Submission over HTTPS on its own listener, modeled on SparkPostA separate entry point: its own listener with a certificate, its own keys and a reserved source name through which the usual submission settings apply to such mail.◇The receiver declares an encryption requirement on its websiteThe node fetches the recipient domain’s policy over HTTPS and, if it is in enforce mode, delivers only when the MX matches, the connection is encrypted and the certificate is verified.◇The receiver declares an encryption requirement in its DNS zoneThe node looks at the recipient domain’s DANE records and, if STARTTLS is required, sends only over an encrypted channel with a certificate verified by fingerprint.

In the Hub
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connection encryption
Neighboring settings of the block <domain>:use-starttlssmtp-tls-min-versionuse-danerequire-starttlssmtp-client-certificateAll 135 directives of the block →