What Is MTA-STS and TLS-RPT? Opportunistic vs Enforced TLS

MTA-STS (SMTP MTA Strict Transport Security) is a standard that lets a receiving domain declare that mail servers delivering to it must use a valid TLS connection, published as a small policy file over HTTPS plus a DNS TXT records (short text lines in DNS used for email security). TLS-RPT (SMTP TLS Reporting) is the companion standard: a DNS record naming an address where senders email daily reports about TLS failures. Together they turn the default opportunistic encryption between mail servers into something enforceable and observable.

Quick summary

• Before delivering, the sender queries _mta-sts.yourdomain.com. If the TXT exists and the id changed since last time, it fetches the policy file over HTTPS.
• It caches the policy for max_age seconds, so even if DNS is tampered with later, the cached policy still applies.
• It connects to your MX, requires STARTTLS, and checks the certificate matches an mx: pattern in the policy.
• In mode: enforce, any failure means the message is deferred and retried later, never sent in plain text.
• In mode: testing, failures are delivered anyway but reported through TLS-RPT.

Opportunistic vs enforced TLS

Server-to-server SMTP on port 25 starts in plain text and upgrades with STARTTLS if the receiver offers it. The sender does not check the certificate and falls back to plain text if the upgrade fails. That is opportunistic TLS, and it means an attacker on the path can strip the STARTTLS offer and read the mail. MTA-STS closes the gap: a sender that supports it fetches your policy, and if the policy says enforce, it refuses to deliver unless the MX host presents a certificate valid for its name and the connection is encrypted.

The three pieces of MTA-STS

1) DNS TXT at _mta-sts.yourdomain.com
   v=STSv1; id=20260712T090000

2) Policy file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
   version: STSv1
   mode: enforce
   mx: mail.oqumail.com
   max_age: 604800

3) TLS-RPT TXT at _smtp._tls.yourdomain.com
   v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

How a sender uses it

1. Before delivering, the sender queries _mta-sts.yourdomain.com. If the TXT exists and the id changed since last time, it fetches the policy file over HTTPS.
2. It caches the policy for max_age seconds, so even if DNS is tampered with later, the cached policy still applies.
3. It connects to your MX, requires STARTTLS, and checks the certificate matches an mx: pattern in the policy.
4. In mode: enforce, any failure means the message is deferred and retried later, never sent in plain text.
5. In mode: testing, failures are delivered anyway but reported through TLS-RPT.
6. Once a day, senders that support TLS-RPT email a JSON summary of successes and failures to your rua address.

Common mistakes

• Changing the policy file without changing the id in the DNS record, so senders keep using the cached version.
• Serving the policy from a host without a valid HTTPS certificate for mta-sts.yourdomain.com. It must be a real certificate, not self-signed.
• Listing MX hostnames in the policy that do not exactly match the certificate names on those hosts.
• Going straight to mode: enforce. Start with testing, read a week of TLS-RPT reports, then switch.
• Forgetting to update the policy when you change mail providers; a stale enforce policy makes senders defer mail to the new host.

Do you need it?

MTA-STS protects mail sent to you from being downgraded in transit. Gmail, Outlook and other large senders honour it, so if your inbound mail is sensitive, it is a worthwhile addition. It has nothing to do with your outbound deliverability. For a small business, the sensible order is MX, SPF, DKIM and DMARC first, then TLS-RPT alone, which is one TXT records (short text lines in DNS used for email security) and gives you visibility at no risk, then MTA-STS in testing mode, then enforce.

MTA-STS with OquMail

Your MX for OquMail is mail.oqumail.com, which serves a valid certificate for that name, so an MTA-STS policy with mx: mail.oqumail.com works. You host the policy file yourself on a small HTTPS page at mta-sts.yourdomain.com, or through a static host that supports custom domains, and publish the two TXT records at your DNS host alongside the OquMail records. OquMail does not require MTA-STS for setup; the guided verification covers MX, SPF, DKIM and DMARC.

Common questions

Does MTA-STS encrypt the email content?

It encrypts the connection between servers, like HTTPS for mail transport. The stored message is not end-to-end encrypted.

Is MTA-STS the same as DANE?

They solve the same problem differently. DANE uses DNSSEC to pin certificates; MTA-STS uses HTTPS and works without DNSSEC.

What is in a TLS-RPT report?

A JSON attachment with counts of successful sessions and each failure type, for example starttls-not-supported or certificate-host-mismatch, per sending organisation.