# MTA-STS and DANE: how mail servers require encryption

> Why encryption between mail servers is optional by default, how MTA-STS and DANE change that and what Domain Autopilot sets up for it.

## Encrypted, as long as nobody interferes

When one mail provider hands a message to another, two servers talk to each other. At the start of the connection, the receiving server states whether it can encrypt. If it does, the sending server switches over. If it does not, the sending server in its usual configuration delivers anyway, in plain text. By default, email puts delivery first.

That leniency is the gap. Anyone sitting between the two servers can remove the statement from the reply, and neither side notices. They can also present a certificate of their own, because many servers do not check it for this optional encryption. Or they forge the DNS answer that names the responsible mail server and receive the mail themselves.

MTA-STS and DANE close this gap in two ways. Both rest on the same idea: the recipient's domain commits in advance and in public that its servers encrypt and identify themselves. A sender that knows this commitment can no longer be talked into plain text.

## The receiver commits. The sender keeps to it.

| Question | MTA-STS (RFC 8461) | DANE for SMTP (RFC 7672) |
|---|---|---|
| Where is the commitment? | TXT record under `_mta-sts` and a policy file served over HTTPS | TLSA record at the mail server's name |
| What does it say? | names of the mail servers, mode, lifetime | which key the server has to present |
| Who vouches for it? | certificate authorities | the zone's DNSSEC signatures |
| Does it need DNSSEC? | no | yes, for the recipient's domain too |
| Protection on first contact? | no, only once the policy has been fetched undisturbed | yes |

With MTA-STS, the sender fetches the policy and remembers it for the stated lifetime. In `enforce` mode it delivers only to the servers named, and only if their certificate is valid. In `testing` mode it delivers anyway and merely reports the failure. The weakness is at the beginning: if a sender has never seen the policy, an attacker can suppress the pointer to it.

With DANE, the commitment itself is signed. The sender can therefore check not only that a record is genuine, but also that there really is none. So an attacker cannot make the record disappear unnoticed. In return, the whole chain in the DNS has to be signed.

## TLS-RPT: finding out when it fails

Strictness has an awkward property: what is not delivered shows up nowhere on the recipient's side. TLS-RPT (RFC 8460) makes such failures visible. The domain names an address in the DNS, and participating senders send a report there every day: how many connections succeeded, how many failed and why. The reports cover both mechanisms. The order follows from that: collect reports first, then enforce.

## What Domain Autopilot sets up

For email on your own domain, the work is spread across three places: Domain Autopilot, the privymail.eu mail servers and your DNS provider.

- **MTA-STS.** The Autopilot sets up the record and the policy for your domain and monitors both.
- **TLS-RPT.** It generates the record, receives the reports and analyses them.
- **DANE.** The TLSA record sits at the mail server's name, that is, with privymail.eu. The Autopilot monitors whether this protection also applies to your domain.
- **DNSSEC.** The Autopilot monitors whether your zone is validly signed. Signing itself is enabled by your DNS provider; the registrar submits the DS record.

You enter the DNS records themselves at your DNS provider. The Autopilot displays them, checks them from outside and flags deviations; it cannot change anything there. A health dashboard shows the state of each domain.

When sending, privymail.eu is the sender. For each recipient domain the server checks DANE first, then MTA-STS. If the domain publishes neither, encryption stays optional. TLS 1.3 is preferred, TLS 1.2 is the minimum.

## The price: rather not at all than in plain text

Enforcing means swapping a silent failure for a loud one. If something does not match, the mail does not arrive unencrypted; at first it does not arrive at all: the sender keeps trying and in the end returns it as undeliverable. That is deliberate, and it demands care.

With MTA-STS, order matters. If the mail servers move, you change the policy file first, then the identifier in the TXT record, and only then the MX records. With DANE, the key matters. If the server gets a new one, the matching record has to be in the DNS beforehand, alongside the old one. And DNSSEC forgives little: if an old DS record remains after a change of DNS provider, validating resolvers discard every answer for the domain, not just those for mail.

## What neither of them solves

- **They only work if the other side takes part.** A sender that honours neither mechanism delivers as it would without them. And outgoing mail is only protected if the recipient's domain publishes a commitment.
- **DANE needs DNSSEC, and far from every domain is signed.** MTA-STS works without it, but relies on certificate authorities and does not protect the first contact.
- **They secure the route, not the content.** Every server involved can read the mail unless its content is encrypted separately. This is not end-to-end encryption.
- **They say nothing about the sender.** Whether a message really comes from the domain it names is a matter for SPF, DKIM and DMARC.
- **They only cover the route between servers.** The connection between your own device and your provider is a different matter.

## Further reading

[SPF, DKIM and DMARC explained](https://privymail.eu/en/email-authentication.md) shows every record with examples and common pitfalls. [Your own domain](https://privymail.eu/en/domains.md) describes Domain Autopilot and its limits, [Security](https://privymail.eu/en/security.md) the encryption in transit and at rest. The building blocks of the service and their order are listed in the [roadmap](https://privymail.eu/en/roadmap.md).

---

- privymail.eu: patchletter UG (haftungsbeschränkt) · Germany
- This page as HTML: https://privymail.eu/en/blog/mta-sts-dane/
- Deutsche Fassung: https://privymail.eu/blog/mta-sts-dane.md