Cybersecurity glossary
What is MTA Strict Transport Security (MTA-STS)?
Learn what MTA-STS is, how MTA-STS policies require authenticated TLS for inbound SMTP delivery, and how MTA-STS relates to TLS-RPT and DANE/TLSA.
Definition
MTA Strict Transport Security (MTA-STS) is a mail-security mechanism in which a receiving domain publishes a DNS signal and an HTTPS-hosted policy telling sending MTAs to require valid TLS and approved MX names when delivering email to that domain.
Why MTA-STS matters
SMTP traditionally tolerated insecure fallback too easily. If a sender could not negotiate trustworthy TLS with the recipient’s MX host, mail delivery often continued with weaker assumptions. MTA-STS gives receiving domains a way to publish stricter expectations for inbound transport security. That does not solve email spoofing, but it does reduce downgrade and misdirection risk on the path to your receiving infrastructure. It also pairs naturally with TLS-RPT, which tells you when senders could not meet the published policy.
What an MTA-STS deployment includes
DNS bootstrap signal
A DNS record tells sending MTAs that the receiving domain publishes an MTA-STS policy and identifies the current policy version.
HTTPS-hosted policy file
The detailed policy is served over HTTPS from the designated `mta-sts` host.
MX name constraints
The policy lists which MX host patterns are acceptable for the domain.
TLS requirement mode
The policy mode determines whether senders should test behavior or strictly require successful authenticated TLS.
How MTA-STS is enforced during delivery
The sender looks for an MTA-STS signal
Before or during SMTP delivery logic, the sending MTA checks whether the recipient domain advertises an MTA-STS policy.
The policy file is fetched over HTTPS
If the DNS signal is present, the sender retrieves the published policy from the recipient’s well-known HTTPS location.
Policy mode and MX rules are parsed
The sender reads whether the domain is in testing or enforce mode and which MX hosts are valid recipients.
SMTP connects to a listed MX host
When delivering mail, the sender chooses an MX endpoint that matches the allowed policy patterns.
TLS must validate successfully
In stricter modes, the sender requires a valid TLS connection to the recipient MX rather than silently downgrading.
Failures can be reported
If policy cannot be satisfied, the event can feed [TLS-RPT](/glossary/smtp-tls-reporting-tls-rpt) reports for the recipient domain to review.
MTA-STS settings operators manage most
The policy is simple in concept, but small mismatches between DNS, HTTPS hosting, and MX operations can break the rollout.
| Element | What it means | Why it matters |
|---|---|---|
| Testing mode | The domain advertises policy details and encourages visibility before strict delivery behavior is fully enforced. | This is useful during rollout because it surfaces issues without creating avoidable mail loss too early. |
| Enforce mode | Sending MTAs that support MTA-STS should require valid TLS and a policy-matching MX target for delivery. | This is where the control becomes materially protective against certain downgrade and redirection scenarios. |
| MX pattern list | The policy identifies which receiving MX names are considered valid for the domain. | If your provider changes MX names and the policy lags behind, legitimate delivery can fail. |
| Policy freshness | A version id and cache lifetime determine when senders refresh the policy. | Operational changes must account for cached policy to avoid long-lived mismatches. |
MTA-STS deployment habits that prevent outages
The main risk is configuration drift between your receiving mail platform and the published policy.
- Publish a correct DNS bootstrap record and ensure the HTTPS policy file is reachable on the required `mta-sts` host with a valid certificate.
- List only MX patterns that truly match your inbound mail provider or self-hosted mail architecture.
- Start in testing mode if you need time to confirm provider behavior, policy hosting, and TLS certificate coverage.
- Monitor [TLS-RPT](/glossary/smtp-tls-reporting-tls-rpt) reports so delivery failures caused by policy mismatches are visible quickly.
- Coordinate MTA-STS changes with MX migrations, certificate renewals, and acquisitions of new receiving platforms.
- Document policy ownership across email, DNS, certificate, and web-hosting teams because the control crosses all four.
- Compare the deployment with [DANE](/glossary/dns-based-authentication-of-named-entities-dane) and [TLSA](/glossary/tlsa-record) if your environment supports DNSSEC-backed mail trust as well.
- Treat policy hosting as production infrastructure: monitor uptime, TLS validity, and content integrity, not just DNS syntax.
MTA-STS solves transport trust, not sender identity
MTA-STS is about how your inbound mail is delivered to you, not whether the sender identity in the message should be believed. That distinction matters because organizations sometimes over-credit it as a phishing control when it is really a transport-assurance control. It also differs from DANE. MTA-STS bootstraps trust through DNS plus HTTPS policy retrieval, while DANE expresses trust through DNSSEC-protected TLSA records.
The practical takeaway
MTA-STS is the SMTP policy mechanism that lets a receiving domain require authenticated TLS and approved MX hosts for inbound mail delivery. The practical takeaway is to deploy it with change discipline: keep DNS, HTTPS policy hosting, MX names, and TLS-RPT reporting aligned, or a transport-security improvement can quickly turn into a mail-delivery problem.
Related security terms
SMTP TLS Reporting (TLS-RPT)
TLS-RPT reports the SMTP TLS failures that MTA-STS can help surface and diagnose.
TLSA Record
TLSA records can express DNSSEC-backed TLS expectations for SMTP through DANE.
DNS-Based Authentication of Named Entities (DANE)
DANE is an alternate trust model for SMTP TLS that relies on DNSSEC and TLSA records.
MX Record
MTA-STS policy constrains which MX hosts are valid for a receiving domain.
Email Spoofing
MTA-STS protects SMTP transport, which complements but does not replace sender-domain authentication.
Frequently asked questions
What is MTA-STS in simple terms?
It is a policy that tells sending mail servers to use valid TLS and expected MX hosts when delivering mail to your domain.
Does MTA-STS stop email spoofing?
No. It protects transport to your receiving mail system, not the claimed sender identity in the message.
How is MTA-STS related to TLS-RPT?
TLS-RPT gives you reports about SMTP TLS failures, which is useful when deploying or monitoring MTA-STS.
How is MTA-STS different from DANE?
MTA-STS uses an HTTPS-hosted policy and DNS bootstrap, while DANE relies on DNSSEC-protected TLSA records.
What are the main MTA-STS modes?
Common modes include testing and enforce, which let domains ramp up policy safely before requiring strict behavior.
Do all sending MTAs honor MTA-STS?
Support is broad but not universal, so you should validate with your mail ecosystem and monitor failures over time.
References
Explore authoritative guidance and frameworks related to mta strict transport security (mta-sts).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.