What is MTA-STS and how it forces TLS for inbound mail

MTA-STS lets your domain tell other mail servers to deliver inbound email over TLS - or not at all. It closes the downgrade gap that plain SMTP encryption leaves open.

SMTP can use TLS, but in its classic form encryption is optional and unauthenticated - so a network attacker can strip it and read mail in transit. MTA-STS fixes that for inbound mail by publishing a policy that says: encrypt, verify, and don't fall back to plaintext. This guide explains what MTA-STS is, how it works, where it breaks, and how SecRift checks yours.

What is MTA-STS?

MTA-STS stands for SMTP Mail Transfer Agent Strict Transport Security. It is a policy you publish that tells other mail servers they must use TLS with a valid certificate when delivering email to your domain - and if they can't, they should not deliver over an insecure connection.

The problem it solves is opportunistic TLS. When one mail server connects to another, it advertises TLS support with a STARTTLS command. But because that handshake is unauthenticated, an attacker positioned on the network can simply remove the STARTTLS offer, and the sending server quietly falls back to plaintext. MTA-STS removes the "quietly fall back" option for mail coming into your domain.

How MTA-STS works

MTA-STS has two parts that work together:

• A DNS record at _mta-sts.example.com. It is a short TXT record - v=STSv1; id=... - whose only job is to announce that a policy exists and to signal, through its id, when the policy has changed.
• A policy file served over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt. This is where the real rules live.

The policy file contains a few fields:

• mode - enforce requires TLS and a matching certificate, testing reports failures without blocking, and none disables the policy.
• mx - the list of MX hostnames allowed to receive your mail, which the certificate must match.
• max_age - how long a sending server should cache the policy, in seconds. A longer cache makes the policy harder to strip.

A sending server fetches the policy over authenticated HTTPS, caches it, and from then on refuses to deliver to your domain over a connection that doesn't meet it. Because the policy arrives over HTTPS with a valid certificate, an attacker can't forge or remove it the way they can with STARTTLS.

Why MTA-STS matters

Email in transit between servers often carries exactly the content attackers want - password resets, invoices, contracts. Opportunistic TLS looks like protection but offers none against an active attacker, who can downgrade the connection without either side noticing.

MTA-STS in enforce mode shuts that down for inbound mail. Senders that honor it will refuse to hand your messages over an unencrypted or unauthenticated channel, so a downgrade attack results in a deferred delivery rather than a silent interception. It is the practical, HTTPS-based way to require transport security without depending on DNSSEC.

Common MTA-STS mistakes

• Record but no policy file. The DNS record points to a policy that returns a 404 or isn't served over HTTPS, so senders can't apply it.
• Stuck in testing mode. Testing reports problems but never blocks anything - real protection only starts at enforce.
• Incomplete MX list. If the policy's mx entries don't cover every MX host, mail to the missing host fails the policy.
• Certificate mismatch. The certificate on the policy host or MX must be valid and match - an expired or wrong-name certificate breaks enforcement.
• max_age too short. A very small cache lifetime weakens the policy, because a stripped record is re-fetched too often.

How SecRift checks MTA-STS

SecRift fetches both halves of your MTA-STS setup, the way a sending server would, and breaks the result into six findings:

• DNS record - confirms exactly one valid v=STSv1 TXT record exists at _mta-sts, with a correct version and policy id.
• Policy fetch - retrieves the policy file over HTTPS and confirms it is served with a valid certificate at the required URL.
• Policy syntax - validates the policy file's fields against RFC 8461.
• Mode - checks whether the policy is in enforce, testing, or none, and rewards full enforcement.
• MX coverage - confirms the policy's mx list covers your domain's actual MX hosts.
• max_age - checks that the cache lifetime is long enough to be effective.

Each finding includes a plain-language summary and, where something is wrong, one concrete fix. SecRift only reads what you publish in DNS and over HTTPS, so the result reflects what a real sender would enforce.

MTA-STS pairs naturally with TLS-RPT, which collects reports when a sending server can't deliver securely - so you find out about failures instead of guessing.

Run a free scan on any domain at secrift.com and see your MTA-STS posture in seconds.