MTA-STS & TLS-RPT

Encryption between mail servers is optional by design. When one server hands a message to another over SMTP, it asks "do you support TLS?" using a command called STARTTLS, and if the answer is yes the two sides upgrade to an encrypted channel. The problem is that this negotiation happens in the clear. Anyone sitting on the path can quietly delete the STARTTLS offer, the sending server shrugs, and your mail goes out as readable plaintext. MTA-STS closes that gap by letting you publish a policy that says, in effect, "always use TLS for my domain, and refuse to deliver if you cannot." TLS-RPT then sends you a daily report of any delivery that failed or was downgraded.

Why SMTP encryption is opportunistic, and why that is a problem

SMTP was designed in 1982, long before transport encryption was a concern. TLS was bolted on later through the STARTTLS extension. A sending mail server connects to your domain's MX host on port 25, the two exchange greetings, and your server advertises that it supports STARTTLS. The sender then issues the command, both sides perform a TLS handshake, and the rest of the conversation is encrypted.

The weakness is in the word opportunistic. If the STARTTLS advertisement never arrives, the sending server has no way to know it was ever offered. It falls back to plaintext and delivers anyway, because for forty years the priority has been getting mail through, not protecting it in transit. An attacker on the network path, a compromised router, a hostile Wi-Fi gateway, or a state-level interception point can strip the STARTTLS keyword out of the server greeting. This is called a downgrade attack. The message that you assumed was encrypted travels as plain readable text, and nobody is alerted.

There is a second failure mode that is more common and less dramatic: a misconfigured or expired certificate on the receiving side. Opportunistic TLS does not validate certificates strictly, so a server with an expired or self-signed certificate still gets traffic. That sounds convenient until you realise it means a man-in-the-middle can present any certificate at all and the sending server will accept it.

What MTA-STS actually does

MTA-STS (Mail Transfer Agent Strict Transport Security, defined in RFC 8461) lets your domain publish a policy that tells every compliant sending server two things: TLS is mandatory when delivering to you, and the certificate presented by your MX host must be valid and must match the host name. If either condition is not met, a sender that honours the policy refuses to deliver and queues the message rather than send it in the clear.

That single change flips the relationship. Without MTA-STS, the sender decides whether to bother with encryption. With MTA-STS, you decide, and you make the decision in advance through a published policy that the sender fetches and caches. A stripped STARTTLS offer or a bogus certificate now causes a hard failure instead of a silent downgrade. Gmail, Microsoft and other large providers fetch and enforce MTA-STS policies, so the protection is meaningful for real mail flows, not theoretical.

How an MTA-STS policy is published

MTA-STS uses two pieces, and both must be present and consistent.

The DNS record

You publish a TXT record at _mta-sts.yourcompany.com that looks like this:

v=STSv1; id=20260614000000Z

The id is a version tag. Whenever you change the policy, you change the id. Sending servers compare the id they have cached against the one in DNS, and a new id tells them to fetch the policy file again. This record is small and cheap to check, which is why it lives in DNS: servers can poll it quickly before deciding whether the cached policy is still current.

The policy file over HTTPS

The actual policy is a text file served at a fixed URL:

https://mta-sts.yourcompany.com/.well-known/mta-sts.txt

It is fetched over HTTPS on purpose. The HTTPS certificate for the mta-sts. subdomain is what proves the policy genuinely belongs to your domain, so an attacker cannot forge it. A typical file reads:

version: STSv1
mode: enforce
mx: mail.yourcompany.com
mx: *.yourcompany.com
max_age: 604800

The mx lines list the host names that are allowed to receive your mail, matching what is in your MX records. The max_age is how long, in seconds, a sender may cache the policy; 604800 is one week. The DNS id and the HTTPS file work as a pair: the id signals when to refetch, the file holds the rules, and the HTTPS certificate authenticates the whole thing.

Start in testing, then move to enforce

MTA-STS has three modes, and the order you use them matters.

You start in testing because enforce can bounce real mail. If one of your MX hosts has a certificate whose host name does not match, or a certificate that expired last month, enforce will reject legitimate deliveries to that host. Running in testing for a couple of weeks while you read the TLS-RPT data tells you whether any sender is hitting a problem, without losing a single message. When the reports show zero failures, you change the policy to enforce, bump the id, and the protection becomes real.

TLS-RPT: the reporting half

MTA-STS on its own is silent. If a delivery is being downgraded or rejected, you would never know unless someone complained that mail was missing. TLS-RPT (RFC 8460) fixes that by asking sending servers to send you a daily summary of how TLS went.

You enable it with one more TXT record:

_smtp._tls.yourcompany.com IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourcompany.com"

The rua= address is where reports are sent. Each report is a JSON document covering a 24 hour window. It records how many delivery attempts succeeded with TLS, how many failed, and the reason for each failure: a certificate that did not validate, a host name mismatch, a STARTTLS command that was rejected, or a policy that could not be fetched. A report from Google for a domain with a broken certificate might show a block of certificate-expired failures against one MX host, which points you straight at the fix.

These reports are how you build confidence before turning on enforce, and how you catch a regression afterwards. If someone renews a certificate incorrectly six months from now, the next day's TLS-RPT will tell you. The catch is that raw JSON from several providers, every day, is tedious to read by hand. DMARC Engine parses every report and shows you success and failure rates per receiving host, so you see a problem as a clear line on a chart rather than buried in an attachment.

How this fits with DMARC

MTA-STS and DMARC are often confused because both involve TXT records and email security, but they protect different directions and different threats. It helps to keep them straight.

DMARC stops someone sending a fake invoice from accounts@yourcompany.com to your customers. MTA-STS stops someone reading or tampering with the genuine mail arriving at your servers. You want both, and they share no settings, so publishing one does nothing for the other. If you have not yet locked down outbound spoofing, start with DMARC, then add MTA-STS for the transport side. Once DMARC is enforcing at quarantine or reject, you also have the prerequisite for BIMI, which puts your logo next to your mail in supporting inboxes.

The operational catch nobody warns you about

MTA-STS has a failure mode that bites people months after they set it up: the HTTPS endpoint and its certificate have to keep working. A sender fetches your policy from https://mta-sts.yourcompany.com/.well-known/mta-sts.txt, and if that request fails, the host is unreachable, the certificate has expired, the certificate does not chain to a trusted root, then the sender treats the policy as absent and falls back to ordinary opportunistic delivery.

The dangerous part is that this fails open, not closed. Your mail keeps flowing, so no alarm goes off, but the protection you thought you had is gone. The most common cause is a certificate on the mta-sts. subdomain that nobody remembered to renew, because it is a subdomain that exists purely to serve one text file and is easy to forget. Hosting the policy file is also slightly awkward, you need a web endpoint that is always up, serves the right content type, and presents a valid certificate for the right host name.

How DMARC Engine handles MTA-STS and TLS-RPT

We host the moving parts so the failure modes above stop being your problem. DMARC Engine serves the policy file at the correct /.well-known/mta-sts.txt path for your domain, manages and auto-renews the HTTPS certificate on the mta-sts. subdomain, and keeps the DNS id in step with the policy so sending servers refetch when you make a change. When you move from testing to enforce, that is a click, and we update the id for you.

On the reporting side, we collect the TLS-RPT JSON from every sending provider, parse it, and present TLS success and failure rates per receiving host with the failure reasons spelled out. If a certificate is heading towards expiry or a host name stops matching, you see it on the dashboard before it becomes an enforced bounce. You publish two delegating records once, point them at us, and the endpoint, certificate and report parsing run without further attention.

If you would like to see where your domain stands first, run a free scan, it checks for an existing MTA-STS policy, the state of your TLS reporting, and your DMARC posture in one pass. From there you can read how monitoring works to understand what the reports tell you week to week.

Getting started

The path is straightforward. Confirm your MX hosts all present valid certificates that match their host names, since that is what enforce will check. Publish the policy in testing mode and turn on TLS-RPT so you start collecting data. Read the reports for a week or two, fix anything they flag, then move the policy to enforce. With DMARC Engine the certificate, the endpoint and the report parsing are handled, so the only ongoing work is reacting to a report if one ever shows a problem.

Opportunistic TLS was a reasonable compromise for the internet of the 1990s. It is not a reasonable compromise for mail that carries invoices, contracts and personal data today. MTA-STS turns "encrypt if convenient" into "encrypt or do not deliver," and TLS-RPT makes sure you can prove it is working. Paired with DMARC on the outbound side, it covers both halves of the problem: nobody can convincingly pretend to be your domain, and nobody can quietly read the genuine mail on its way in.