Enforced transport encryption

MTA-STSTLS for email transportmade mandatory

MTA-STS publishes a policy that obliges sending mail servers to deliver only over an encrypted connection. If encryption is missing or the certificate does not match, the message is held back instead of being delivered in plain text.

Check your domain for free View MailGuard

mta-sts.txt policy

version: STSv1
mode: enforce
mx: *.mail.example.de
max_age: 604800

mode: enforce

MTA-STS is the pragmatic path to enforced transport encryption. It works without DNSSEC and enjoys broad support, closing the gap left by opportunistic STARTTLS for nearly every sender.

Most email is already transmitted with encryption, yet that protection is voluntary. An attacker can strip the encryption in transit without anyone noticing. MTA-STS turns the recommendation into an obligation. Anyone contacting the domain must honor the published policy.

What MTA-STS delivers

MTA-STS combines a DNS record with a policy file served over HTTPS. Sending servers read the policy and apply it to every delivery.

Encryption becomes mandatory

The policy requires delivery over TLS only. Unencrypted connections are rejected.

The certificate is verified

The sending server checks whether the certificate matches the expected domain and was issued by a trusted authority.

Protection against downgrade

If an attacker tries to strip the TLS negotiation, the policy takes effect and delivery is stopped.

The three operating modes of MTA-STS

The mode determines how strictly sending servers apply the policy. The transition happens step by step.

1none

The policy is published but not active. This mode is used to withdraw an existing policy in a controlled way.

2testing

Violations are reported but not enforced. Together with TLS-RPT this creates a complete picture before you switch to enforcement.

3enforce

The policy is binding. Messages are delivered only with encryption and a valid certificate, otherwise they are held back.

How the policy takes effect

Three steps from the DNS hint to enforced encryption.

Read the DNS hint

A TXT record under the domain signals that an MTA-STS policy exists and states its version.

Fetch the policy over HTTPS

The sending server loads the policy file from a dedicated subdomain over a secured HTTPS connection.

Apply the policy

Delivery requires the listed mail servers, a valid TLS connection, and a matching certificate. Otherwise the message is held back.

MTA-STS and TLS-RPT belong together

In testing mode and during ongoing operation, TLS-RPT provides reports on failed connections. This shows whether the policy is working or whether a recipient is reporting problems, before any messages are lost.

MTA-STS or DANE?

MTA-STS is easier to implement and works without DNSSEC. DANE is cryptographically more robust and mandatory under BSI TR-03108. The two do not exclude each other and together cover all senders.

DANE and TLSA in detail

MTA-STS managed by Conbool MailGuard

The policy is operated, monitored, and updated centrally and securely, without touching your existing mailbox service.

Policy and subdomain provided

The DNS hint and the policy file served over HTTPS are provided and maintained entirely by Conbool.

Guided rollout

The path from testing to enforce is supported, so that no legitimate message is lost because a policy was switched to enforcement too early.

Certificate always valid

The certificate of the policy subdomain is renewed automatically, so the policy stays reachable without interruption.

Works with TLS-RPT

Reports on transport errors are analyzed and presented in a clear form.

Compatible with Microsoft 365 and Google

MTA-STS works independently of the mailbox service and protects inbound deliveries to the protected domains.

Frequently asked questions about MTA-STS

What does MTA-STS mean?

MTA-STS stands for Mail Transfer Agent Strict Transport Security. It is a standard defined in RFC 8461 that makes TLS mandatory for email transport by publishing a policy that sending servers apply.

Does MTA-STS require DNSSEC?

No. MTA-STS works without DNSSEC and instead relies on the public certificate ecosystem together with a policy distributed over HTTPS. This is exactly what makes it easier to implement than DANE.

What is the difference between testing and enforce?

In testing mode, violations are reported but not enforced. In enforce mode, delivery is held back when encryption is missing or faulty. The switch happens only once the reports are clean.

Can MTA-STS block legitimate email?

In enforce mode a message can be held back if the remote server does not offer valid TLS. The guided rollout through testing and the analysis of TLS-RPT rule out this risk before switching to enforcement.

Does MTA-STS act on inbound or outbound mail?

The published policy protects inbound deliveries to your own domain. For outbound messages, the sending server evaluates the policies of the recipients. Conbool MailGuard accounts for both directions.

Does MTA-STS replace the standard encryption STARTTLS?

No, it builds on it. STARTTLS remains the transport protocol, while MTA-STS makes its use mandatory and prevents a silent fallback to plain text.

How can the status of MTA-STS be checked?

The free mail check from Conbool verifies whether an MTA-STS DNS hint is present, whether the policy is reachable, and which mode it runs in. The result comes back as a report.