SPF, DKIM, and DMARC prove who sent a message. MTA-STS and TLS-RPT protect the message while it is moving — they make sure the connection carrying your mail is genuinely encrypted, and they tell you when it isn't. MTA-STS (SMTP MTA Strict Transport Security, defined in RFC 8461) lets a domain declare that mail bound for its servers must arrive over TLS with a valid certificate. TLS-RPT (SMTP TLS Reporting, RFC 8460) asks the sending servers to file a daily report on whether that encryption succeeded or failed. Neither authenticates content — together they close a different gap, the one that plain opportunistic TLS leaves wide open. Here is what each does and how to roll them out without breaking your inbound mail.
The short answer#
MTA-STS is a policy you publish so that other people's mail servers encrypt the
mail they send to you. It has two moving parts: a DNS TXT record at
_mta-sts.yourdomain.com that flags the policy exists, and an HTTPS-hosted policy
file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt that lists your MX
hostnames, a mode (none, testing, or enforce), and how long to cache it.
TLS-RPT is a second TXT record at _smtp._tls.yourdomain.com that names an address
to receive daily reports on how those TLS connections went. The safe rollout mirrors
DMARC: publish in testing mode first, read the TLS-RPT reports until you are sure
every connection negotiates TLS cleanly, then switch to enforce.
The gap that MTA-STS closes#
Modern SMTP already encrypts most mail in transit using STARTTLS — the sending server asks "do you support TLS?", the receiver says yes, and the two negotiate an encrypted channel. The problem is that this handshake is opportunistic and unauthenticated. If either side doesn't offer TLS, mail falls back to plaintext rather than failing. Worse, an attacker sitting between the two servers can strip the STARTTLS offer out of the conversation — a downgrade attack — and the sending server, seeing no TLS on offer, quietly delivers the message in the clear. The certificate isn't verified either, so a man-in-the-middle can present its own and intercept the connection.
MTA-STS fixes both weaknesses. By publishing a policy, you tell compliant senders: mail for this domain must go over TLS, the receiving server must present a certificate that is valid and matches one of my listed MX hostnames, and if those conditions aren't met, do not deliver — defer and retry instead of falling back to plaintext. Because the policy is fetched over HTTPS, its own certificate acts as the trust anchor, which is what stops an attacker from forging or stripping it. The result is that a passive eavesdropper or an active downgrade attacker can no longer force your inbound mail into the clear.
What TLS-RPT adds#
MTA-STS on its own is enforcement without visibility — you'd be telling senders to refuse insecure connections, but you'd have no way to see how often that actually happens or which senders are failing. TLS-RPT is the feedback channel. It works exactly like DMARC's aggregate reporting, and pairs naturally with the habit of reading DMARC reports.
When you publish a TLS-RPT record, participating senders send you a daily JSON
report summarising every TLS session they opened to your MX hosts: how many
succeeded, how many failed, and — crucially — why they failed. A report might show
an expired certificate on one of your MX servers, a hostname mismatch, a STARTTLS
negotiation that was interrupted, or a policy-fetch problem. That is exactly the
information you need before you dare turn MTA-STS to enforce, because a failure in
enforce mode means deferred or bounced inbound mail. TLS-RPT is what makes the
rollout safe rather than a leap of faith.
Setting up MTA-STS: the DNS record and the policy file#
MTA-STS needs three things in place: a DNS record, a policy file, and a subdomain to host the file over HTTPS.
1. The DNS TXT record. Publish a TXT record at _mta-sts.yourdomain.com. Its job
is small — it announces that a policy exists and carries an id that senders use to
notice when the policy changes.
_mta-sts.example.com. TXT "v=STSv1; id=20260725090000"
The id is an arbitrary string of up to 32 alphanumeric characters. A timestamp is
the common convention. The one rule that matters: whenever you edit the policy
file, change the id. Senders cache your policy, and a new id is the signal that
tells them to re-fetch it. Forget to bump it and your changes may go unseen for as
long as your max_age.
2. The policy file. Host a plain-text file at the fixed path
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It lists the mode, every
valid MX hostname, and a cache lifetime:
version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.com
max_age: 86400
Each mx line must match a hostname from your domain's MX records, and the wildcard
form (*.example.com) matches a single left-most label. Every MX host you list has
to serve a certificate that is currently valid, chains to a public CA, and matches
its hostname — otherwise a sender in enforce mode will refuse it. The max_age is
the cache lifetime in seconds; RFC 8461 allows values up to 31557600 (about a
year). Keep it short (a day or so) while you are testing so changes propagate
quickly, then raise it once you are confident in enforce — receivers such as Google
recommend a long max_age in production, though the exact value is yours to choose.
3. The mta-sts subdomain over HTTPS. The policy file must be reachable over
HTTPS on the mta-sts subdomain with a certificate valid for
mta-sts.yourdomain.com. In practice you point that subdomain (via A/AAAA or CNAME)
at whatever serves the file — a small static host or a CDN is typical — and make sure
it responds with Content-Type: text/plain. Many DNS and hosting providers now offer
a managed MTA-STS option that handles the file and certificate for you.
Setting up TLS-RPT#
TLS-RPT is by far the simpler of the two: a single TXT record, no policy file.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
The rua tag names where reports go. It accepts a mailto: address, an https:
endpoint that receives POSTed reports, or a comma-separated list of both. Raw TLS-RPT
JSON is dense, so most teams point rua at a monitoring service that parses the
reports into a readable dashboard — the same way DMARC reports usually flow into a
parser rather than a human inbox. You can publish TLS-RPT on its own, and it is worth
doing so before MTA-STS: it gives you a picture of your current TLS health with zero
risk to mail flow.
Rolling out MTA-STS and TLS-RPT safely#
The order of operations for MTA-STS and TLS-RPT matters more than the records themselves — get it wrong and you can defer your own inbound mail. Follow the same monitor-then-enforce discipline that governs a good DMARC rollout.
1. Publish TLS-RPT first. With no MTA-STS policy yet, the reports simply tell you how much of your inbound mail is already using TLS and whether any of your MX certificates are misconfigured. Fix anything obvious here.
2. Publish MTA-STS in testing mode. Add the DNS record and the policy file with
mode: testing. In this mode senders evaluate your policy and report failures via
TLS-RPT, but they still deliver the mail normally. Nothing about your mail flow
changes — you are only gathering data. Leave it here long enough to capture a full
cycle of your regular correspondents, ideally a couple of weeks.
3. Read the TLS-RPT reports and fix failures. Watch for certificate problems,
hostname mismatches, and MX hosts you forgot to list. Every failure in testing mode
is a failure you would have caused in enforce mode. Keep iterating on your
certificates and policy file until the reports are clean.
4. Switch to mode: enforce. Once failures have gone quiet, edit the policy file
to enforce and bump the id in the DNS record so senders re-fetch it. From this
point, compliant senders will refuse to deliver over an unauthenticated or
downgraded connection. Consider raising max_age now for stronger protection against
downgrade attempts.
Where this sits alongside SPF, DKIM, and DMARC#
It is worth being precise about what MTA-STS and TLS-RPT do and don't do, because it is easy to file them under "deliverability" and expect the wrong thing.
SPF, DKIM, and DMARC answer is this message really from who it claims to be? — they authenticate identity and content. MTA-STS and TLS-RPT answer a different question: was the connection that carried this message actually encrypted and verified? — they protect confidentiality in transit. The two layers are complementary and independent. A message can pass DMARC while travelling over plaintext, and it can travel over enforced TLS while failing DMARC. A complete setup wants both.
Two honest caveats. First, MTA-STS and TLS-RPT are not part of the Google and Yahoo bulk-sender requirements that took effect in 2024 — those mandate SPF, DKIM, DMARC, one-click unsubscribe, and a low spam rate, not transport-security policies. That said, the major providers do publish and honour MTA-STS as receivers, so a policy you publish is genuinely enforced by Gmail and others when they deliver to you. Second, MTA-STS is not a spam-folder fix. It hardens inbound transport security; it does not, on its own, improve where your outbound marketing lands. Inbox placement is still decided by sender reputation, engagement, and list hygiene, and if your mail is going to spam the reasons live in those signals, not in your TLS setup. Treat MTA-STS and TLS-RPT as the transport-security chapter of a mature sending domain — worth doing, but distinct from the levers in the deliverability guide that actually move inbox placement.
If you want an analogy, MTA-STS is a close cousin of DANE, the older DNSSEC-based way of enforcing SMTP TLS. Both aim at the same downgrade problem; MTA-STS was designed so domains without DNSSEC could still get most of the protection, using the web certificate system instead. If you already run DANE you may not need MTA-STS, but the two can coexist.
Frequently asked questions#
Does MTA-STS replace SPF, DKIM, or DMARC?#
No — they operate on different layers and you want both. SPF, DKIM, and DMARC authenticate the sender and content of a message, proving it is really from your domain and wasn't altered. MTA-STS and TLS-RPT secure the transport: they force the connection carrying the message to use verified TLS and report when it doesn't. A message needs authentication and encrypted delivery, so MTA-STS sits alongside DMARC rather than replacing any of it.
Are MTA-STS and TLS-RPT required by Google and Yahoo?#
Not as part of the 2024 bulk-sender requirements, which mandate SPF, DKIM, DMARC, one-click unsubscribe, and a spam rate under 0.3% — MTA-STS is not on that list. But the large providers publish MTA-STS policies themselves and honour yours as receivers, so a policy you publish is genuinely enforced by Gmail and others. It is a recommended best practice for a mature sending domain, just not a formal gate for reaching the inbox.
What is the difference between MTA-STS and DANE?#
Both enforce TLS on inbound SMTP and defend against downgrade attacks; they differ in how they establish trust. DANE publishes certificate information in DNS and relies on DNSSEC to make those records tamper-proof. MTA-STS avoids the DNSSEC requirement by serving its policy over HTTPS, using the ordinary web certificate system as the trust anchor. MTA-STS is generally easier to deploy for domains without DNSSEC; the two can also run together.
Will MTA-STS improve my inbox placement?#
Not directly. MTA-STS is a transport-security control for mail coming into your domain — it does not change how your outbound marketing is filtered. Inbox placement is driven by sender reputation, engagement, complaint rates, and list quality. MTA-STS is worth setting up for security and completeness, but if your mail is landing in spam, the fix is in your list hygiene and reputation, not your TLS policy.
MTA-STS and TLS-RPT harden the pipes your mail travels through, but the inbox is won on list quality. The free email checker catches dead domains and typos before they bounce, and the free plan runs the full verification pipeline on your list — because a secure, well-authenticated domain only earns placement when the list behind it is clean.
