Sign in Get up to 500 free credits

MTA-STS and TLS reporting explained

MTA-STS lets a domain tell sending servers that its mail servers support TLS with a valid certificate, and that mail should not be delivered to them over a connection that fails those checks. You publish it with a TXT record at _mta-sts.<domain> and a policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt. SMTP TLS Reporting (TLS-RPT) is its companion: a TXT record at _smtp._tls.<domain> asks senders for a daily JSON report of the TLS connections they made to you, failures included. Start in testing mode, read the reports, then switch to enforce.

Why STARTTLS alone is not enough

Servers encrypt mail between them with STARTTLS, the SMTP extension from RFC 3207. The server announces it in plain text, and the client then asks to switch to TLS. Section 6 of the RFC points out the weakness: an attacker in the path can delete the server's 250 STARTTLS line, and the client never tries TLS. Section 4 also forbids a public mail server from requiring STARTTLS, so senders that cannot negotiate TLS fall back to plain text by design.

RFC 7672, section 1.3.1, calls this the STARTTLS downgrade attack, and RFC 8461, section 1, adds a second one: an attacker who can change the answer to your MX record lookup can send your mail to a server of their choosing. In both cases the sender has no way to know that encryption, or a valid certificate, was expected. MTA-STS and DANE exist to give it that knowledge.

How MTA-STS works

The TXT record

RFC 8461, section 3.1, defines a TXT record at _mta-sts with two fields: v=STSv1 first, and an id of 1 to 32 letters and digits that changes every time the policy changes.

_mta-sts.example.com. IN TXT "v=STSv1; id=20261106T0900Z"

Senders look up this record to learn that a policy exists, and compare the id with the one they cached to decide whether to fetch the policy again. If the lookup returns more than one record that starts with v=STSv1, senders treat the domain as having no policy. A date and time makes a practical id; both Google and Microsoft suggest it.

The policy file

The policy itself is a short text file served over HTTPS from the host mta-sts under your domain (section 3.2):

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

Section 3.3 is strict about how the file is served. The HTTPS certificate must be valid for mta-sts.<domain>, chain to a trusted authority and not be expired. Only a 200 response counts: senders must not follow redirects. The RFC also suggests senders check for the text/plain media type, and gives one minute and 64 KB as reasonable limits for the fetch.

The three modes

Section 5 defines what a sender does when a connection fails the policy, meaning the MX host is not in the mx list, does not offer STARTTLS, or presents a certificate that is not valid for its name:

ModeWhat senders do on a failure
testingDeliver as usual, and report the failure if both sides support TLS-RPT
enforceDo not deliver to that host; try the next MX, then treat it as a temporary failure and retry
noneAct as if the domain had no policy; used to remove MTA-STS cleanly

Before a sender gives up on a message under enforce, section 5 makes it check DNS for a newer policy id first, so a fixed policy can rescue mail that is waiting in queues.

SMTP TLS Reporting

RFC 8460, section 3, defines the reporting record at _smtp._tls. It holds v=TLSRPTv1 and an rua with one or more destinations, separated by commas. Two kinds are allowed: a mailto: address, or an https: URL that receives the report by POST.

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

Reports sent by email must carry a DKIM signature from the reporting organization, and the receiver must ignore reports without one. Reporters must deliver them even when TLS to your server fails, so a report can arrive unencrypted.

Each report is a JSON file that should cover one full UTC day (section 4.1). For every policy it lists the policy type (sts, tlsa for DANE, or no-policy-found), the policy text, a count of successful TLS sessions and a count of failed ones. Failures come with details. A shortened example in the section 4.4 format:

{
  "organization-name": "Example Mail Provider",
  "date-range": { "start-datetime": "2026-11-05T00:00:00Z", "end-datetime": "2026-11-05T23:59:59Z" },
  "report-id": "2026-11-05-example.com",
  "policies": [{
    "policy": { "policy-type": "sts", "policy-domain": "example.com", "mx-host": ["mx1.example.com", "mx2.example.com"] },
    "summary": { "total-successful-session-count": 4180, "total-failure-session-count": 12 },
    "failure-details": [{ "result-type": "certificate-expired", "receiving-mx-hostname": "mx2.example.com", "failed-session-count": 12 }]
  }]
}

The result-type names the problem. Section 4.3 lists, among others, starttls-not-supported, certificate-host-mismatch, certificate-expired and certificate-not-trusted, plus sts-policy-fetch-error, sts-policy-invalid and sts-webpki-invalid for problems with the policy itself. The success count also works as a heartbeat: it shows that reporting works even on a day with no failures. If you already read DMARC aggregate reports, the idea is the same, with TLS connections in place of authentication results.

DANE, the DNSSEC alternative

DANE for SMTP (RFC 7672) solves the same problem with DNSSEC instead of web certificates. The mail server's operator publishes a TLSA record, such as _25._tcp.mx1.example.com, that says which certificate or key the server presents (section 2.2.3). Because the records are signed with DNSSEC, an attacker cannot remove or alter them without detection, and senders that validate DANE refuse a downgrade. The cost is that the zones involved must be signed with DNSSEC. RFC 8461, section 2, describes MTA-STS as the option for domains where DNSSEC is impractical, and says a passing MTA-STS check must never override a failing DANE check. You can publish both.

Who supports MTA-STS

Rollout steps

  1. List your MX hosts, including backups, and check that each one offers STARTTLS with a certificate valid for its own host name (RFC 8461, section 4.2).
  2. Publish the TLS-RPT record first, with a mailbox or endpoint that someone reads.
  3. Serve the policy in testing mode at https://mta-sts.<domain>/.well-known/mta-sts.txt. A short max_age while you test keeps a mistake from staying in caches for long.
  4. Publish the _mta-sts TXT record with a fresh id.
  5. Read the reports until the senders that matter to you show successful sessions to every MX and no unexplained failures. Google notes that you may receive few reports, since not every provider sends them.
  6. Switch to enforce, raise max_age, and change the id. Section 8.1 says to update the policy file before the TXT record, so senders that see the new id fetch the new file.
  7. Keep the policy in step with DNS. Add a new mail host to the mx list before you point MX records at it, because senders keep using the cached policy.

Common mistakes

Questions

Does MTA-STS protect the mail I send?

No. Your policy protects mail that others send to your domain. For mail you send, your own server or provider has to honor the policies of the domains it delivers to, as Gmail and Exchange Online say they do.

Do Gmail and Yahoo require MTA-STS?

Their sender rules ask for TLS on the connection at Gmail, not for MTA-STS; see Gmail and Yahoo sender requirements. A bulk sender that delivers to Gmail without TLS can be rejected with 550 5.7.29.

Should I use MTA-STS or DANE?

Both if you can. DANE needs DNSSEC on your zones and on your MX hosts' zones; MTA-STS needs only DNS and a web server. They do not conflict, and RFC 8461 tells senders to respect a failing DANE check either way.

Try it

Check your domain's other mail records with the DNS tools, and test single addresses with the free email checker.

Sources

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.

Get up to 500 free credits. No card needed.

New accounts get 500 free credits (100 when you sign up with a free email provider such as Gmail, Outlook or Yahoo, or another personal mailbox such as a paid one like Fastmail or one from your internet provider). Try it on your own list before you buy.

Create your account Open the free email checker

Updated · Maintained by the email-validation.org team