MTA-STS, TLS-RPT, and DANE: encrypting SMTP in transit

STARTTLS encrypts most email in transit today, but it's opportunistic. A sending server offers it, a receiving server accepts it, and if that handshake fails for any reason, the message still goes out in plaintext. Neither side raises an alarm. The email just leaves your infrastructure readable to anyone on the path.

The problem with opportunistic encryption

STARTTLS, defined in RFC 3207, upgrades a plaintext SMTP connection to TLS mid-session. The sending server announces STARTTLS support, and if the receiving server accepts, the two negotiate an encrypted channel before the message body crosses the wire.

The weakness is in the word "if." A network attacker positioned between the two servers can strip the STARTTLS keyword out of the receiving server's response before it reaches the sender. This is a STRIPTLS downgrade. The sending server sees no STARTTLS offer, assumes the receiving server doesn't support encryption, and falls back to plaintext. Both sides believe the exchange completed normally.

The base STARTTLS mechanism has no way to alert either side that a downgrade happened. The sender can't require encryption for a specific domain, and can't find out afterward that a message went out unencrypted.

What MTA-STS, TLS-RPT, and DANE add

Three standards close this gap, and each solves a different piece of it. MTA-STS lets a domain require TLS and refuse plaintext fallback for mail addressed to it. TLS-RPT gives that domain visibility into TLS negotiation failures, whether or not MTA-STS is even in place. DANE offers a DNSSEC-anchored alternative to MTA-STS that doesn't depend on the public certificate authority system.

You can deploy any one of these on its own. MTA-STS and TLS-RPT are commonly paired, since the enforcement mechanism benefits from the reporting mechanism.

How MTA-STS works

MTA-STS (SMTP MTA Strict Transport Security), defined in RFC 8461, lets a domain publish a policy that sending servers are expected to fetch and honor.

1. You publish a DNS TXT record at _mta-sts.<domain> announcing a policy ID.
2. You host a policy file over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt, declaring the enforcement mode and the list of authorized MX hosts.
3. A sending server that supports MTA-STS fetches that policy file the first time it sends to your domain, then caches it for the duration given in the policy.
4. On every subsequent delivery attempt, that sending server refuses to deliver over plaintext, and refuses to deliver to any MX host not listed in the policy, for as long as the cached policy stays valid.

How TLS-RPT works

TLS-RPT (SMTP TLS Reporting), defined in RFC 8460, doesn't enforce anything. It reports.

1. You publish a DNS TXT record at _smtp._tls.<domain> with a reporting address, usually a mailto: target.
2. Sending servers that support TLS-RPT track every delivery attempt toward your domain: whether the TLS handshake succeeded, and if not, why.
3. Once a day, those sending servers email you a JSON report summarizing successes and failures, grouped by the policy type they checked (MTA-STS, DANE, or none) and the failure reason for each.
4. You read that report to find out about downgrade attempts or misconfiguration you'd otherwise have no way to detect.

How DANE works

DANE (DNS-based Authentication of Named Entities) for SMTP, defined in RFC 7672 on top of the base DANE specification in RFC 6698, takes a different route to the same goal.

1. You sign your domain's DNS zone with DNSSEC.
2. You publish a TLSA record at _25._tcp.<mx-hostname> binding an expected certificate, or an expected certificate authority, to that specific MX host.
3. A sending server that supports DANE looks up that TLSA record over DNSSEC-validated DNS, so it can trust the record wasn't tampered with in transit.
4. It then validates the certificate the receiving server presents against that TLSA record, instead of, or in addition to, the public CA system.

Anatomy of the three records

• MTA-STS policy pointer (_mta-sts.<domain> TXT): v=STSv1; id=<policy-id>
• MTA-STS policy file (https://mta-sts.<domain>/.well-known/mta-sts.txt): version, mode (testing, enforce, or none), mx (one line per authorized host), max_age (cache duration in seconds)
• TLS-RPT (_smtp._tls.<domain> TXT): v=TLSRPTv1; rua=mailto:<address>
• DANE TLSA (_25._tcp.<mx-hostname> TLSA): usage, selector, matching-type, and certificate-association-data fields

A policy file and a report, worked

An MTA-STS policy file in enforce mode, for a domain with two mail servers:

version: STSv1
mode: enforce
mx: mx1.acme.com
mx: mx2.acme.com
max_age: 604800

mode: enforce tells sending servers to refuse plaintext delivery and to refuse any MX host not on this list. max_age: 604800 caches the policy for seven days, so a sending server doesn't need to refetch it before every message.

A TLS-RPT report covering one day, with zero failures:

{
  "organization-name": "example-reporter.com",
  "date-range": {
    "start-datetime": "2026-08-09T00:00:00Z",
    "end-datetime": "2026-08-09T23:59:59Z"
  },
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "acme.com"
      },
      "summary": {
        "total-successful-session-count": 4821,
        "total-failure-session-count": 0
      }
    }
  ]
}

Without MTA-STS in place, a sending server that hits a stripped STARTTLS offer for acme.com delivers over plaintext, and neither side finds out. With the policy above, that same sending server refuses the delivery outright. TLS-RPT then gives you a report the next day, either confirming zero failures, as shown, or naming the failure if one occurred.

Limits

DANE requires a signed DNS zone. Most domains don't run DNSSEC, and turning it on is a separate, non-trivial operational commitment, which is why MTA-STS sees far more real-world deployment than DANE for SMTP.

MTA-STS also only protects mail addressed to you, the receiving side. It says nothing about the TLS posture of mail your domain sends outbound. Protecting outbound mail depends on the receiving domain's own MTA-STS or DANE setup, not yours.

Check it yourself

Fetch your own MTA-STS policy the same way a sending server would:

curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Query your TLS-RPT record:

dig +short TXT _smtp._tls.yourdomain.com

If either command returns nothing, that protection isn't active for your domain yet.

Where this fits

MTA-STS, TLS-RPT, and DANE protect the connection a message travels over. They say nothing about whether the message itself is authentic. That's the job of SPF, DKIM, and DMARC, and of ARC when a message passes through a forwarder or mailing list. A fully protected domain configures both sets of standards: transport security so the message can't be read or altered in flight, and message authentication so the receiving side can trust who sent it. See the full email RFC standards guide for how these fit into the wider set of email standards.

STARTTLS, the mechanism all three build on, is an extension to SMTP itself, not a separate protocol.

FAQ

Do I need MTA-STS if I already use DANE?

They solve the same problem differently. DANE requires DNSSEC on your domain; MTA-STS doesn't. Most domains without DNSSEC use MTA-STS instead of, or alongside, DANE.

Does MTA-STS protect email I send, or email I receive?

It protects mail sent to your domain, by declaring your own TLS requirements. It says nothing about the TLS posture of mail your domain sends to others.

What happens with none of these three in place?

STARTTLS stays opportunistic. A network attacker can strip the STARTTLS offer, and the connection falls back to plaintext silently, with no alert to either side.

Is TLS-RPT required for MTA-STS to work?

No, they're independent. MTA-STS enforces its policy without TLS-RPT. Without TLS-RPT, though, you have no visibility into negotiation failures.

RFC reference

RFCs covered: RFC 3207 (STARTTLS, referenced as background), RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE for SMTP, base RFC 6698). Superseded / updated by: None for any of the four.