# MTA-STS and TLS-RPT: Setup, Modes and Common Mistakes URL: https://email-validation.org/guides/mta-sts-tls-rpt/ Updated: 2026-11-06 > Documentation index: https://email-validation.org/llms.txt 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.` and a policy file at `https://mta-sts./.well-known/mta-sts.txt`. SMTP TLS Reporting (TLS-RPT) is its companion: a TXT record at `_smtp._tls.` 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](https://email-validation.org/glossary/#smtp) extension from [RFC 3207](https://www.rfc-editor.org/info/rfc3207/). 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](https://www.rfc-editor.org/info/rfc7672/), section 1.3.1, calls this the STARTTLS downgrade attack, and [RFC 8461](https://www.rfc-editor.org/info/rfc8461/), section 1, adds a second one: an attacker who can change the answer to your [MX record](https://email-validation.org/glossary/#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](https://www.rfc-editor.org/info/rfc8461/), 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. ```text _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](https://knowledge.workspace.google.com/admin/gmail/advanced/turn-on-mta-sts-and-tls-reporting) and [Microsoft](https://learn.microsoft.com/en-us/purview/enhancing-mail-flow-with-mta-sts) 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): ```text version: STSv1 mode: enforce mx: mx1.example.com mx: mx2.example.com max_age: 604800 ``` - **`version`**: `STSv1`. - **`mode`**: `enforce`, `testing` or `none` (see below). - **`mx`**: one line per allowed MX host. A pattern can be an exact name or a wildcard such as `*.example.net`, and section 4.1 says the wildcard matches exactly one label: `*.example.com` matches `mail.example.com` but neither `example.com` nor `foo.bar.example.com`. - **`max_age`**: how long, in seconds, senders may cache the policy, up to 31,557,600 (about a year). The RFC expects values of weeks or more once the policy is stable. Section 3.3 is strict about how the file is served. The HTTPS certificate must be valid for `mta-sts.`, 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: | Mode | What senders do on a failure | |---|---| | `testing` | Deliver as usual, and report the failure if both sides support TLS-RPT | | `enforce` | Do not deliver to that host; try the next MX, then treat it as a temporary failure and retry | | `none` | Act 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](https://www.rfc-editor.org/info/rfc8460/), 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. ```text _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: ```text { "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](https://email-validation.org/guides/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](https://www.rfc-editor.org/info/rfc7672/)) 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 - **Google.** Its [MTA-STS overview](https://knowledge.workspace.google.com/admin/gmail/advanced/about-mta-sts-and-tls-reporting) says Gmail follows MTA-STS when it sends to servers with a policy in `enforce` mode. Google Workspace domains can publish their own policy and TLS-RPT record; Google's [setup page](https://knowledge.workspace.google.com/admin/gmail/advanced/turn-on-mta-sts-and-tls-reporting) suggests turning on TLS reporting first, and its overview suggests starting in `testing` mode. - **Microsoft.** Its [Exchange Online page](https://learn.microsoft.com/en-us/purview/enhancing-mail-flow-with-mta-sts) says Exchange Online always validates MTA-STS for outbound mail, and can return a non-delivery report with 5.4.8 (MX host not in the policy) or 5.7.5 (certificate failed validation) when an `enforce` policy fails. Domains whose MX points to Exchange Online can publish a policy with `mx: *.mail.protection.outlook.com`; Microsoft notes that this wildcard is specific to its service and is not general advice. Exchange Online does not host the policy file for you. ## 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./.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 - **The policy file is not served over valid HTTPS.** The certificate covers `www` but not `mta-sts`, it has expired, or the host redirects to another URL. Any of these makes the fetch fail, and RFC 8460 reports it as `sts-policy-fetch-error` or `sts-webpki-invalid`. - **The `mx` list misses a host.** Backup MX hosts are the usual gap. Section 8.4 warns that senders may only reach a backup when the primary fails, so the mistake can hide until the worst moment. - **Forgetting to change the `id`.** Microsoft points out that senders keep the cached policy until its `max_age` runs out if the `id` stays the same. - **Removing the records to switch MTA-STS off.** Cached policies still apply. Section 8.3 says to publish `mode: none` with a short `max_age` and a new `id`, and remove the records only after the old policies expire. - **Two TXT records at `_mta-sts`.** Senders then see no valid policy at all. ## 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](https://email-validation.org/guides/gmail-yahoo-sender-requirements/). A bulk sender that delivers to Gmail without TLS can be rejected with [550 5.7.29](https://email-validation.org/bounce-codes/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](https://email-validation.org/tools/), and test single addresses with the free [email checker](https://email-validation.org/email-checker/). ## Related - [Glossary: SMTP](https://email-validation.org/glossary/#smtp) and [MX record](https://email-validation.org/glossary/#mx-record). - [530 5.7.0](https://email-validation.org/bounce-codes/530-5-7-0/): a server that wants STARTTLS before anything else. - [SPF checker](https://email-validation.org/tools/spf-checker/) and [DMARC checker](https://email-validation.org/tools/dmarc-checker/). ## Related guides - [How to read DMARC aggregate reports](https://email-validation.org/guides/dmarc-aggregate-reports/) - [Gmail and Yahoo sender requirements](https://email-validation.org/guides/gmail-yahoo-sender-requirements/) - [Reverse DNS (PTR records) for mail servers](https://email-validation.org/guides/reverse-dns-ptr/) - [Outlook.com requirements for high-volume senders](https://email-validation.org/guides/outlook-sender-requirements/) - [BIMI requirements explained](https://email-validation.org/guides/bimi-requirements/) - [All guides](https://email-validation.org/guides/) ## Sources - [RFC Editor: RFC 8461, SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/info/rfc8461/): the TXT record, policy file, modes, sender behavior and operational advice. - [RFC Editor: RFC 8460, SMTP TLS Reporting](https://www.rfc-editor.org/info/rfc8460/): the `_smtp._tls` record, report delivery, JSON format and result types. - [RFC Editor: RFC 3207, SMTP Service Extension for Secure SMTP over TLS](https://www.rfc-editor.org/info/rfc3207/): STARTTLS and its downgrade weakness. - [RFC Editor: RFC 7672, SMTP Security via Opportunistic DANE TLS](https://www.rfc-editor.org/info/rfc7672/): the downgrade attack and TLSA lookups. - [Google: About MTA-STS and TLS reporting](https://knowledge.workspace.google.com/admin/gmail/advanced/about-mta-sts-and-tls-reporting): Gmail's outbound support and the testing-first advice. - [Google: Turn on MTA-STS and TLS reporting](https://knowledge.workspace.google.com/admin/gmail/advanced/turn-on-mta-sts-and-tls-reporting): record examples and `id` advice. - [Microsoft: Enhance mail flow with MTA-STS](https://learn.microsoft.com/en-us/purview/enhancing-mail-flow-with-mta-sts): Exchange Online's outbound validation, error codes and inbound policy. ## 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](https://email-validation.org/signin/?new=1) or [open the free email checker](https://email-validation.org/email-checker/).