MTA-STS Technical Reference (RFC 8461)

What This Reference Covers

RFC 8461 defines SMTP MTA Strict Transport Security (MTA-STS). Published in September 2018 by the IETF, it provides a mechanism for mail domains to declare that they support TLS for inbound SMTP, and that sending mail servers should refuse to deliver messages over unencrypted connections.

MTA-STS exists because SMTP's STARTTLS extension is opportunistic by default — a man-in-the-middle can strip the STARTTLS advertisement from the server's response, forcing the connection to fall back to plaintext. MTA-STS closes that gap by publishing a policy over HTTPS that senders can discover and cache independently of the SMTP handshake.

When our MTA-STS Checker reports a missing policy file, an MX mismatch, or an expired max_age, the rules come from this RFC. This reference walks through the sections that matter to administrators deploying or troubleshooting MTA-STS, with the RFC's own language quoted where it clarifies the rule.

---

§1 — The STARTTLS Downgrade Problem

"The STARTTLS extension to SMTP [...] is not, by itself, sufficient to guarantee confidentiality of email in transit. An active attacker can interfere with the TLS negotiation." — RFC 8461 §1

SMTP was designed in 1982 without encryption. STARTTLS (RFC 3207) was added later as an opportunistic upgrade — the sending server advertises its willingness to upgrade to TLS, and the receiving server can accept or decline. The problem is structural: the STARTTLS advertisement itself travels in plaintext, before any encryption is established.

An active attacker positioned between two mail servers can:

1. Strip the STARTTLS response from the receiving server's EHLO capabilities, making the sender believe TLS is not available
2. Tamper with the TLS handshake to force a downgrade or connection failure, causing the sender to fall back to plaintext
3. Present a fraudulent certificate — most sending MTAs do not validate certificates during opportunistic TLS

The result: email travels in plaintext even between two servers that both support TLS. This is not theoretical. Network-level STARTTLS stripping has been documented by ISPs, state actors, and compromised network equipment.

MTA-STS addresses this by moving the policy declaration out of the SMTP channel entirely. The policy is published over HTTPS — a channel with its own certificate validation — so an attacker cannot strip or modify it without also compromising the web PKI.

Check it: Use the mxio SMTP Check to verify that your mail servers advertise STARTTLS and present valid certificates.

---

§3 — MTA-STS Policy: The DNS TXT Record

"To indicate that a domain is willing to serve an MTA-STS policy, the domain MUST publish a TXT record at '_mta-sts' in its DNS zone." — RFC 8461 §3.1

MTA-STS uses a two-step discovery process. The first step is a DNS TXT record that signals the existence of a policy and provides a version identifier for cache management.

Record Format

The TXT record is published at _mta-sts.{domain} and contains two fields:

_mta-sts.example.com  TXT  "v=STSv1; id=20260408120000"

The id value can be any string. Its sole purpose is cache invalidation — when a sending MTA sees that the id has changed since its last lookup, it fetches the policy file again. Common conventions include timestamps (20260408120000), sequential numbers, or content hashes.

If the id has not changed, a sender with a cached policy can skip the HTTPS fetch entirely. This is why updating the id when you change the policy file is critical — without a new id, senders may continue using a stale cached policy for the remainder of the max_age window.

Check it: Use the mxio TXT Lookup to verify that your _mta-sts TXT record exists and is correctly formatted.

---

§3.1 — Policy Discovery

"When sending to a recipient at a domain for which the sender has no unexpired, cached MTA-STS policy, the sender MUST query DNS for a TXT record at '_mta-sts.{recipient-domain}'." — RFC 8461 §3.1

The discovery sequence from the sending MTA's perspective:

1. Query DNS for _mta-sts.{recipient-domain} TXT record
2. If no record exists, MTA-STS is not configured — deliver normally (opportunistic TLS only)
3. If a record exists, check the id against any cached policy
4. If the id has changed (or no policy is cached), fetch the policy file over HTTPS
5. Apply the policy according to its mode (enforce, testing, or none)

The sending MTA does not need to perform this lookup on every message. Once a policy is fetched and cached, it remains valid until max_age expires or the id changes — whichever comes first.

If the DNS TXT record exists but the HTTPS policy file cannot be retrieved, the sending MTA treats it as if no policy exists. A broken policy file does not block delivery — it degrades to opportunistic TLS. This is a deliberate design choice to prevent MTA-STS misconfiguration from causing widespread mail delivery failures.

---

§3.2 — The Policy File

"The policy is a set of key-value pairs [...] served via HTTPS from the host 'mta-sts' at the Policy Domain." — RFC 8461 §3.2

The policy file is an HTTPS resource hosted at a well-known URL:

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

The URL is non-negotiable. The hostname must be mta-sts.{domain}. The path must be /.well-known/mta-sts.txt. The scheme must be HTTPS. No other location is checked.

Policy File Format

The file is plain text with one field per line, using key: value syntax:

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

Every field is required. A policy file missing any of these fields is invalid and is treated as if no policy exists.

Hosting Requirements

The policy file must be served with these characteristics (§4):

• Valid HTTPS certificate — the certificate for mta-sts.{domain} must chain to a trusted CA. Self-signed certificates are not accepted.
• Content-Type: text/plain — the response must use this content type.
• HTTP 200 — any other status code means the policy fetch failed.
• No redirects across domains — redirects within the same domain are permitted, but a redirect to a different hostname is treated as a failure.

This last point catches organizations that try to serve the policy from a CDN on a different domain. The HTTPS fetch must resolve to mta-sts.{domain} from start to finish.

Check it: The mxio MTA-STS Checker fetches your policy file and validates all of these requirements — certificate chain, content type, response code, field completeness, and MX matching.

---

§5 — Policy Enforcement: Modes

"A sender always attempts TLS when sending to a domain with an MTA-STS policy. If the 'mode' is 'enforce', the sender MUST NOT deliver the message to an MX host whose certificate does not validate." — RFC 8461 §5

The mode field in the policy file controls how the sending MTA behaves when TLS negotiation fails or a certificate is invalid.

Deployment Progression

The recommended deployment path mirrors DMARC's phased approach:

1. Start with testing mode. Publish the policy, configure TLS-RPT (RFC 8460) to receive failure reports, and monitor for problems. Any MX host that fails TLS negotiation or presents an invalid certificate will show up in reports without affecting delivery.

2. Move to enforce mode once reports confirm that all MX hosts successfully negotiate TLS with valid certificates. This is the point where MTA-STS begins protecting against downgrade attacks.

3. Use none mode only to decommission. If you need to remove MTA-STS, publish a none policy first and wait for the previous max_age to expire. This ensures senders flush their cached enforce policy before you remove the DNS TXT record and HTTPS endpoint.

Jumping straight to enforce without a testing phase risks bouncing legitimate email if any MX host has a certificate problem. Run testing for at least one full max_age cycle before switching.

Check it: The mxio MTA-STS Checker reports your current mode and flags testing as an incomplete deployment.

---

§5.1 — MX Matching

"Each 'mx' value is a hostname pattern that is matched against the MX hosts for the Policy Domain." — RFC 8461 §3.2

The mx lines in the policy file declare which MX hostnames are valid for the domain. When a sending MTA connects to deliver mail, it checks that the MX host it selected appears in the policy's mx list. If the MX host does not match any mx line, the sender treats it as a policy violation.

Matching Rules

• Exact match: mx: mail.example.com matches only mail.example.com
• Wildcard match: mx: *.example.com matches any single-level subdomain — mail.example.com, backup.example.com, but not a.b.example.com and not example.com itself
• Case-insensitive: Matching is case-insensitive per standard DNS conventions
• Multiple entries: You can (and should) list all MX hostnames that your domain uses

The wildcard only covers one label. *.example.com does not match deep.sub.example.com. This follows the same wildcard semantics as TLS certificates.

Common Mistakes

The most frequent MTA-STS misconfiguration is an MX mismatch — the policy file lists MX hosts that do not match the domain's actual MX records, or the domain's MX records point to hosts not listed in the policy.

; DNS MX records
example.com  MX  10  mail.example.com
example.com  MX  20  mail2.example.com

; Policy file lists only one
mx: mail.example.com
; mail2.example.com is missing — policy violation when senders use it

Every MX host in your DNS must appear in the policy file. Every host in the policy file should correspond to a real MX record. Orphaned entries are harmless but suggest stale configuration.

Check it: The mxio MTA-STS Checker cross-references your policy file's mx lines against your actual DNS MX records and flags mismatches. See MTA-STS MX Mismatch for remediation.

---

§6 — Caching and max_age

"Senders SHOULD cache policies [...] and honor the 'max_age' value in the policy." — RFC 8461 §5.1

The max_age field specifies how long (in seconds) a sending MTA should cache the policy before re-fetching it. During this window, the sender enforces the cached policy even if it cannot reach the policy file — this is by design, and it is the core of MTA-STS's security model.

Why Caching Matters

An attacker who can manipulate DNS could remove or modify the _mta-sts TXT record to disable the policy. But if the sending MTA has already cached the policy, it continues enforcing TLS for the duration of max_age, regardless of what DNS says. The attack window is limited to the gap between cache expiry and the next successful policy fetch.

This means max_age is a security parameter, not just a caching hint. Longer values provide stronger protection against transient DNS manipulation. Shorter values allow faster policy updates but increase the window of vulnerability.

Recommended Values

When deploying MTA-STS for the first time, start with a short max_age (1 day) during testing mode. Once you move to enforce, increase it to at least 1 week. The RFC does not define a maximum value, but values beyond 1 year provide diminishing returns.

Cache Invalidation

The id field in the DNS TXT record is the cache-busting mechanism. Senders periodically re-check the TXT record (typically on each delivery attempt or at a DNS TTL-driven interval). If the id has changed, they re-fetch the policy file. If it has not, they continue using the cached version.

This two-layer design (DNS id for change detection, HTTPS for the full policy) avoids unnecessary HTTPS fetches while ensuring policy updates propagate within one DNS TTL cycle.

---

§7 — Failure Reporting: TLS-RPT (RFC 8460)

MTA-STS works in tandem with SMTP TLS Reporting (RFC 8460), which provides a feedback mechanism for TLS negotiation failures. TLS-RPT is to MTA-STS what DMARC aggregate reports are to SPF/DKIM — the visibility layer that makes deployment practical.

"MTA-STS does not, by itself, provide a reporting mechanism. [...] [RFC 8460] defines a mechanism for sending MTAs to report failures." — RFC 8461 §7

TLS-RPT is configured with a separate DNS TXT record:

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

Reports include:

• Successful and failed TLS negotiations — which MX hosts succeeded, which failed, and why
• Certificate validation failures — expired, untrusted, or mismatched certificates
• MTA-STS policy failures — MX mismatches, policy fetch errors
• STARTTLS failures — connection downgrades, handshake errors

TLS-RPT is not required for MTA-STS to function, but deploying MTA-STS without TLS-RPT is flying blind. In testing mode, TLS-RPT reports are your only signal that something is wrong. In enforce mode, they tell you when legitimate mail is bouncing due to TLS failures.

A full walkthrough of TLS-RPT is outside the scope of this document — it is a separate standard with its own record format and reporting schema.

---

§8 — MTA-STS and DANE

"MTA-STS provides a mechanism for domain owners who do not deploy DNSSEC to indicate a requirement for TLS." — RFC 8461 §8

MTA-STS and DANE (RFC 7672) solve the same problem — preventing STARTTLS downgrade attacks — but they use different trust models.

When to Use Which

MTA-STS is the pragmatic choice for most domains. It requires no DNSSEC infrastructure, uses familiar web hosting tools, and is supported by the major email providers. Its weakness is the trust-on-first-use model — the initial policy fetch is not cryptographically authenticated, so an attacker who can intercept the first HTTPS request could serve a fraudulent policy. Once cached, the policy is resilient to DNS manipulation for the duration of max_age.

DANE is cryptographically stronger. Because TLSA records are DNSSEC-signed, there is no trust-on-first-use vulnerability — the authentication is verifiable from the first lookup. But DANE requires DNSSEC to be deployed and correctly maintained for the mail domain's entire chain of delegation. For most organizations, this is a significant operational burden.

The two mechanisms are complementary. A domain that deploys both gets DANE's cryptographic assurance where the sender supports it, and MTA-STS as a fallback for senders that do not perform DANE lookups.

"If both DANE TLSA records and an MTA-STS policy are present, the DANE TLSA records take precedence." — RFC 8461 §8.1

---

§10 — Security Considerations

The RFC's security section identifies several attack surfaces and limitations that administrators should understand.

DNS Spoofing of the TXT Record

An attacker who can manipulate DNS responses could remove or modify the _mta-sts TXT record to prevent senders from discovering the policy. MTA-STS mitigates this through caching — a sender with a cached policy continues enforcing it regardless of DNS changes. But this protection only applies after the first successful policy fetch. New senders who have never cached the policy are vulnerable.

DNSSEC for the domain's TXT records would eliminate this attack vector, but defeats the purpose of MTA-STS (which exists specifically for domains that do not deploy DNSSEC). In practice, the caching mechanism provides adequate protection for most threat models.

Compromised Certificate Authority

MTA-STS trusts the web PKI. If an attacker obtains a valid certificate for mta-sts.{domain} from any trusted CA, they can serve a fraudulent policy file. This is the same trust model as HTTPS — and subject to the same mitigations (Certificate Transparency logs, CAA records, certificate monitoring).

Publishing a CAA record that restricts which CAs can issue certificates for your domain reduces this attack surface.

Policy File Availability

If the HTTPS endpoint for the policy file becomes unavailable (server down, certificate expired, DNS misconfiguration), senders fall back to their cached policy until max_age expires. After expiry, they degrade to opportunistic TLS — effectively disabling MTA-STS protection.

This makes the availability of the mta-sts.{domain} HTTPS endpoint a security dependency. Treat it with the same uptime expectations as your mail servers. A static file on reliable hosting is sufficient — the file does not need dynamic content or a complex server.

No Protection for Outbound Mail

MTA-STS only protects inbound mail — it tells senders how to deliver to your domain. It does not control how your mail servers send to other domains. Your outbound MTA should be configured to respect MTA-STS policies published by recipient domains, but that is a sending-side configuration, not something your policy file controls.

---

Deploying MTA-STS: Checklist

This is not from the RFC, but it distills the spec's requirements into a deployment sequence:

1. Verify STARTTLS — confirm all MX hosts support STARTTLS and present valid certificates with hostnames matching the MX records. Use the mxio SMTP Check.

2. Create the policy file — write the mta-sts.txt file with mode: testing, listing all MX hostnames.

3. Host the policy file — serve it at https://mta-sts.{domain}/.well-known/mta-sts.txt with a valid certificate and Content-Type: text/plain.

4. Publish the DNS TXT record — add the _mta-sts.{domain} TXT record with v=STSv1; id={unique-value}.

5. Configure TLS-RPT — publish the _smtp._tls.{domain} TXT record to receive failure reports.

6. Monitor reports — run in testing mode for at least one max_age period. Review TLS-RPT reports for failures.

7. Switch to enforce — update the policy file to mode: enforce, increase max_age, and update the DNS TXT record's id.

Validate the whole stack: The mxio MTA-STS Checker validates the DNS record, policy file, HTTPS hosting, certificate, MX matching, and mode in a single check.

---

Quick Reference

---

This reference covers RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS), authored by D. Margolis, M. Risher, B. Ramakrishnan, A. Brotman, and J. Jones. Supplementary RFCs referenced: RFC 8460 (SMTP TLS Reporting), RFC 7672 (SMTP Security via DANE), RFC 3207 (SMTP STARTTLS). Content on this page is an editorial interpretation; see the original RFC for normative text. RFC content is subject to the IETF Trust's Legal Provisions.