What Is MTA-STS? Records, Policy, and Setup Explained

MTA-STS (SMTP MTA Strict Transport Security) is a standard, defined in RFC 8461, that lets your domain tell other mail servers to deliver inbound email only over authenticated TLS. Without it, SMTP encryption is opportunistic, meaning a sending server tries STARTTLS but silently falls back to plaintext if the handshake is stripped or the certificate is invalid. MTA-STS closes that gap by publishing a policy that says, in effect, "if you cannot verify TLS to my mail servers, do not deliver the message at all."

You set it up with three pieces: a DNS TXT record at _mta-sts.yourdomain.com, a policy file hosted over HTTPS, and an optional reporting record for failures. The sections below walk through what each part does, how to publish them, and how to confirm the policy is live and parsing correctly.

The Problem MTA-STS Solves

MTA-STS solves the plaintext-fallback weakness in SMTP encryption. Because STARTTLS is opportunistic, a sending server that cannot complete a TLS handshake delivers the message in cleartext instead of failing, which lets an attacker downgrade or intercept email in transit. MTA-STS lets a domain declare that authenticated TLS is mandatory, so senders refuse to fall back.

SMTP was built without encryption. STARTTLS was added later so two mail servers could upgrade a plaintext connection to TLS, but it is opportunistic by design. If the TLS handshake fails, or the certificate does not validate, the sending server usually delivers the message in cleartext rather than fail. That fallback is the weakness.

An attacker who can tamper with the SMTP session can exploit it directly. RFC 8461 describes the two main attacks: an attacker who deletes the server's 250 STARTTLS response performs a downgrade, forcing plaintext delivery, and an attacker who overwrites the resolved MX record can redirect the whole session to a machine they control, a man in the middle. Both work because opportunistic STARTTLS has no way to know the connection was supposed to be encrypted and authenticated.

MTA-STS removes the ambiguity. It states whether senders should expect PKIX-authenticated TLS support for your domain, and it requires the sending server to validate the receiving server's certificate against a trusted certificate authority. This is different from authentication layers like SPF, DKIM, and DMARC, which verify who sent a message rather than encrypt the connection it travels over. MTA-STS protects the transport; the others protect the identity.

The Moving Parts of MTA-STS

A working MTA-STS deployment is made of three pieces: a DNS TXT record that signals the policy exists, a policy file hosted over HTTPS that carries the actual rules, and a TLS-RPT record that collects failure reports. The record points senders to the policy, the policy lists which MX hosts to trust and in what mode, and the reporting record tells you when TLS breaks.

Component	Location	Purpose
DNS TXT record	_mta-sts.yourdomain.com	Signals a policy exists and carries its version id
Policy file	https://mta-sts.yourdomain.com/.well-known/mta-sts.txt	Lists allowed MX hosts, the mode, and the cache lifetime
TLS-RPT record	_smtp._tls.yourdomain.com	Where sending servers send TLS failure reports

The _mta-sts DNS TXT record

This TXT record does not contain the policy itself. It tells a sender that a policy exists and gives it a version id so senders can detect changes. It looks like this:

_mta-sts.example.com.  IN TXT "v=STSv1; id=20260101120000Z;"

The v field is the version, and only STSv1 is currently valid. The id is a short alphanumeric string (up to 32 characters) that must uniquely identify the current policy. When you change the policy file, you also change the id so senders know to refetch it. A common convention is a timestamp, but any unique string works.

The policy file

The policy lives at a fixed HTTPS path on a dedicated subdomain: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It must be served over valid HTTPS with a Content-Type of text/plain. A typical file looks like this:

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

The fields are:

• version, always STSv1.
• mode, one of testing, enforce, or none, covered in the next section.
• mx, one line per allowed MX host. A wildcard like *.example.net matches a single leftmost label, so it covers mail.example.net but not example.net or foo.bar.example.net.
• max_age, how long senders cache the policy, in seconds. The maximum is 31557600 (about a year), and the RFC expects values in the range of weeks or longer. Many operators start around 604800, one week.

MTA-STS Policy Modes: Testing, Enforce, and None

MTA-STS has three policy modes, and the mode field decides what a sending server does when a TLS check fails: testing delivers mail and still reports failures, enforce blocks delivery when TLS or MX matching fails, and none signals no active policy. Choosing the right one is the difference between a safe rollout and blocked mail.

Mode	What sending servers do	When to use it
testing	Deliver the message even if MX matching or TLS validation fails, and send a TLS-RPT report about the failure	During initial rollout, to catch problems without losing mail
enforce	Refuse to deliver to any host that fails MX matching, certificate validation, or does not support STARTTLS	After testing confirms your MX hosts pass cleanly
none	Treat your domain as having no active policy	To cleanly remove MTA-STS without leaving a stale record

The safe path is to publish in testing first. You get reports on any TLS failures while mail keeps flowing, so a misconfigured certificate or a missing MX entry surfaces before it can block a single message. Only move to enforce once the reports are clean.

How to Set Up MTA-STS Step by Step

Setting up MTA-STS takes six steps: confirm every MX host supports valid TLS, host the policy file in testing mode over HTTPS, publish the _mta-sts TXT record, add a TLS-RPT record, monitor failure reports for one full policy cycle, then switch the policy to enforce and bump the id. The detail for each step follows.

1. List every MX host that receives mail for your domain and confirm each one supports STARTTLS with a valid, publicly trusted certificate. MTA-STS only works if the underlying TLS is already sound.
2. Create the policy file and host it at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over HTTPS, served as text/plain. Start with mode: testing.
3. Publish the _mta-sts DNS TXT record with v=STSv1 and a unique id.
4. Publish the _smtp._tls TLS-RPT record so you begin receiving failure reports.
5. Monitor the reports for a policy cycle. Confirm no legitimate senders are hitting TLS or MX matching failures.
6. Switch the policy file to mode: enforce and update the id in the DNS record so senders refetch it.

Microsoft documents the same testing-then-enforce sequence for hosted mail in its guidance on enhancing mail flow with MTA-STS, which is a useful reference if your MX hosts sit behind a managed provider.

How to Validate and Check Your MTA-STS Policy

To check that an MTA-STS policy is live, query the _mta-sts TXT record, fetch the policy file over HTTPS, and confirm the two agree. A policy that does not resolve, does not parse, or disagrees with your real MX list is worse than none, because senders may cache the broken version. Check both before and after every change.

• Query the DNS record directly: dig +short TXT _mta-sts.yourdomain.com. Confirm it returns v=STSv1 and the id you expect.
• Fetch the policy file: curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Confirm it returns over valid HTTPS, as text/plain, and that the mx lines match your actual MX records.
• Run an MTA-STS checker. A hosted validator resolves both the TXT record and the policy file, verifies the HTTPS certificate on the mta-sts subdomain, parses the fields, and flags any mismatch between the policy mx list and your published MX records.

The failures a checker catches most often are a missing or expired certificate on the mta-sts subdomain, the wrong Content-Type on the policy file, an mx list that no longer matches your MX records, and a policy that was edited without bumping the id, so senders keep serving the cached version. Treat the checker as part of routine monitoring, not a one-time step, and fold it into how you track your email deliverability tools.

TLS-RPT: Reporting on TLS Failures

TLS Reporting (TLS-RPT) is a companion standard that shows you TLS delivery problems you would otherwise never see. You publish a TXT record at _smtp._tls.yourdomain.com naming where reports should go, and supporting senders return periodic JSON summaries of which sessions used authenticated TLS and which failed. It is what makes MTA-STS testing mode worth running.

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Sending servers that support the standard then send you periodic JSON reports summarizing how many sessions succeeded or failed and why. This is what makes testing mode useful: without TLS-RPT, a testing policy fails silently and you learn nothing. With it, you can see whether real senders are able to connect over authenticated TLS before you turn on enforcement.

MTA-STS vs STARTTLS and Why It Matters for Deliverability

STARTTLS and MTA-STS are not competitors. STARTTLS is the mechanism that actually encrypts the connection; MTA-STS is the policy that says the encryption is mandatory and must be authenticated. STARTTLS on its own is opportunistic and can be stripped. MTA-STS turns it into a requirement backed by certificate validation.

The direct payoff is security: your inbound mail resists downgrade and interception attacks. The deliverability angle is more indirect. MTA-STS does not by itself lift inbox placement, and it is not a substitute for list hygiene or authentication. What it does is strengthen the trust signals your domain sends, which is part of the same posture that makes mailbox providers treat you as a legitimate sender. Think of it as one more control in a broader effort to improve email deliverability, sitting alongside authentication and clean sending practices rather than replacing them.

Before your next campaign, run your list through BounceCheck to remove the invalid addresses that inflate your bounce rate, then let MTA-STS keep the valid ones flowing over encrypted, authenticated connections.

FAQs

What is MTA-STS and how does it work?

MTA-STS is a standard that lets a domain require inbound email to arrive over authenticated TLS. It works by publishing a DNS record and an HTTPS-hosted policy file that tell sending servers which MX hosts to trust and to refuse delivery if TLS cannot be verified.

How do I set up an MTA-STS record and policy?

Host a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt in testing mode, publish a _mta-sts TXT record with v=STSv1 and a unique id, add a TLS-RPT record for reports, monitor for failures, then switch the policy to enforce.

What are the MTA-STS policy modes?

There are three: testing delivers mail even on TLS failure but sends reports, enforce refuses delivery when TLS or MX matching fails, and none tells senders to treat the domain as having no policy, which is used for clean removal.

How do I check if my MTA-STS policy is live and working?

Query the TXT record with dig TXT _mta-sts.yourdomain.com, fetch the policy file over HTTPS, and run an MTA-STS checker that confirms both resolve, the certificate is valid, the file parses, and the mx list matches your real MX records.

What is the difference between MTA-STS and STARTTLS?

STARTTLS is the mechanism that encrypts an SMTP connection but is opportunistic and can be downgraded. MTA-STS is the policy that makes authenticated TLS mandatory, so a stripped or invalid handshake blocks delivery instead of falling back to plaintext.

What is TLS-RPT and how does it relate to MTA-STS?

TLS-RPT is a reporting standard published at _smtp._tls.yourdomain.com. Sending servers send JSON reports on TLS successes and failures, which is what makes MTA-STS testing mode useful because it surfaces problems before you move to enforcement.