Loading...
Loading...
MTA-STS (SMTP MTA Strict Transport Security) lets your domain publish a policy that tells sending mail servers to require TLS with a valid certificate when they connect to your MX hosts, closing the door on silent downgrade-to-cleartext attacks.
SMTP's STARTTLS is opportunistic: an active on-path attacker can strip the STARTTLS keyword from the server's greeting and force the sending MTA to deliver in cleartext, or present a self-signed certificate, and the message goes through anyway because plain SMTP has no way to know TLS was ever expected. Without MTA-STS there is no signal that encryption is mandatory, so message bodies, password-reset links, one-time codes, and attachments can be read or altered in transit. Major senders including Google, Yahoo, and Microsoft 365 honor MTA-STS policies, so publishing one measurably hardens inbound mail from the networks that carry the bulk of it.
MTA-STS is defined in RFC 8461 and has two parts. First, a DNS TXT record at `_mta-sts.yourdomain.com` carrying `v=STSv1` and an `id` (1 to 32 alphanumeric characters). The id's only job is to advertise that a policy exists and to change whenever the policy changes, so senders can detect updates cheaply via DNS. Second, a policy file served over HTTPS at `https://mta-sts.yourdomain.com/.well-known/mta-sts.txt` containing `version: STSv1`, a `mode` (`testing`, `enforce`, or `none`), one `mx:` line per authorized MX pattern (leftmost-label wildcards like `*.example.com` are allowed but `*.example.com` does not match the bare `example.com`), and `max_age` in seconds (0 to 31557600, about one year). The policy host's certificate must be valid for `mta-sts.yourdomain.com` and chain to a public root: MTA-STS deliberately relies on the Web PKI rather than DNSSEC, which is what makes it deployable without signing your zone. Senders fetch the policy once, cache it up to `max_age`, and compare the TXT `id` to notice changes. HTTP 3xx redirects MUST NOT be followed, HTTP caching MUST NOT be used, and the body should be served as `text/plain`. Roll out in `mode: testing` first (TLS failures are reported via TLS-RPT but mail is still delivered), then switch to `mode: enforce` once reports are clean. The `/docs/mta-sts-complete-setup` guide covers the full subdomain, certificate, and DNS build.
MTA-STS needs both a TXT record at `_mta-sts.yourdomain.com` and a policy file reachable over HTTPS at `https://mta-sts.yourdomain.com/.well-known/mta-sts.txt`. A missing TXT record, a policy fetch that returns a redirect instead of a 200, or an invalid certificate on the mta-sts subdomain all mean senders ignore the policy and fall back to opportunistic TLS. A policy in `mode: none` or `mode: testing` is published but not yet enforcing.
dig +short TXT _mta-sts.yourdomain.comcurl -sSv https://mta-sts.yourdomain.com/.well-known/mta-sts.txthttps://www.hardenize.com/report/yourdomain.comBoth force TLS on inbound SMTP, but they anchor trust differently. DANE (TLSA records) relies on DNSSEC to publish certificate fingerprints, so it needs a signed zone. MTA-STS relies on the Web PKI (a normal CA-issued cert on the mta-sts subdomain) plus HTTPS, so it works without DNSSEC. They are complementary and you can publish both.
Testing. In `mode: testing` any TLS failure is reported through TLS-RPT but mail still delivers, so you learn about problems without losing messages. Watch the reports for about a month, confirm no failures, then switch the policy file to `mode: enforce` and bump the id.
No. That is the whole point of the design. Unlike DANE, MTA-STS validates the policy host with a standard public certificate over HTTPS, so you can deploy it even if your DNS zone is not signed.
The large sending providers do, as senders: Google (Gmail and Workspace), Microsoft 365, and Yahoo all fetch and honor published MTA-STS policies. Since these networks carry most inbound mail, a policy meaningfully reduces downgrade exposure even though not every small MTA supports it yet.
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.