1The Problem — The "Invisible Pipe"
The security conversation around email has always focused on two questions: is the sender legitimate (SPF), and does the sending domain authorize this message (DMARC)? Both protocols do their job well. But they leave a third question completely unanswered:what happens to the email after it leaves the sender's server?
The envelope vs. the postal van
SPF and DMARC secure theenvelope— they verify who sealed it and that the stamp is authentic. But the envelope then goes into a postal van (the SMTP connection between mail servers) that could be intercepted by anyone. MTA-STS is thearmored truck— it guarantees the van itself is locked and cannot be opened in transit.
The SMTP Downgrade Attack
Email between servers uses SMTP with an optional extension called STARTTLS to upgrade the connection to TLS. The wordoptionalis the problem. Here is exactly what a downgrade attack looks like:
Sender MTA connects to the receiver on port 25 and issues EHLO
The normal SMTP handshake begins — completely standard.
Attacker intercepts the EHLO response mid-network
Via BGP hijack, rogue router, or ISP interception — the receiver's capability list, including STARTTLS, is stripped before the sender sees it.
Sender sees no STARTTLS advertised and proceeds in plaintext
The sender has no reason to suspect anything is wrong. This is a valid SMTP session from its perspective.
Full email transmitted in clear text
Headers, body, attachments — readable by every party in the network path. Zero forensic trace on either server.
No logs. No alerts. No trace.
An SMTP downgrade attack leaves no server-side logs on either end. Both MTAs complete the session normally from their perspective. Your monitoring tools, SIEM, and email provider will not detect it. The attack is particularly dangerous for any domain that processes contracts, financial data, credentials, or NDAs over email.
2What is MTA-STS?
MTA-STS (Mail Transfer Agent Strict Transport Security), standardized inRFC 8461(2018), allows receiving domains to publish a policy declaring three requirements to any sending MTA:
- All inbound SMTP connections must use TLS.No plaintext fallback is permitted under any circumstances.
- The TLS certificate must be valid, publicly trusted, and hostname-matching.Self-signed certificates and expired certificates are rejected — not negotiated.
- If TLS cannot be established, the message must be held and retried.The sending MTA must never silently deliver without encryption.
The Two Components
Component 1 — DNS TXT Record
Published at_mta-sts.yourdomain.com. Signals to sending MTAs that a policy exists and provides a versioned cache key.
v=STSv1; id=202402231200;Component 2 — HTTPS Policy File
Served over HTTPS atmta-sts.yourdomain.com/.well-known/mta-sts.txt. Defines the actual enforcement mode and authorized MX hosts.
version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 604800Why HTTPS and not just another DNS record?
DNS records can be spoofed or poisoned. The policy file is fetched over HTTPS, which means any MTA retrieving it validates the TLS certificate ofmta-sts.yourdomain.combefore trusting its content. HTTPSauthenticates the policy itself— which is why a valid, public-CA-issued certificate on that subdomain is a hard requirement, not a recommendation.
3Step-by-Step Implementation
Create the mta-sts subdomain
Create a DNS A or CNAME record formta-sts.yourdomain.compointing to a server that serves HTTPS responses. This subdomainmust have a publicly-trusted TLS certificate— self-signed certificates cause silent policy retrieval failures.
Cloudflare Pages
Free, zero-config HTTPS. Deploy a single static file.
Easiest option
Netlify / Vercel
Static deployment with automatic TLS renewal. Free tier is sufficient.
Good alternative
Any HTTPS server
nginx, Apache or any web server — add the .well-known path to your config.
For existing infra
Certificate renewal is critical. The TLS certificate onmta-sts.yourdomain.commust never expire while your policy is inenforcemode. Monitor it as carefully as your main domain certificate — DomainRisk.io checks it on every scan.
Host the policy file
Create a plain text file served at/.well-known/mta-sts.txt. The HTTP response must useContent-Type: text/plain. Here is the recommended starting configuration:
version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: mail2.yourdomain.com
max_age: 86400
| Field | Required | Value & Notes |
|---|---|---|
version | Yes | Always STSv1. Any other value is invalid. |
mode | Yes | testing — report failures, deliver anyway. enforce — TLS required, hold on failure. none — disable the policy. |
mx | Yes | One line per MX host. Must match your DNS MX records exactly. Wildcards (*.alt.yourdomain.com) are permitted. |
max_age | Yes | Cache duration in seconds. 86400 = 1 day (recommended during rollout). 604800 = 7 days. 31557600 = 1 year. |
Always start with mode: testing. In testing mode, sending MTAs report TLS failures but still deliver the message. This lets you catch configuration issues without risking delivery failures. Switch tomode: enforce only once your TLS-RPT reports are clean.
Publish the DNS TXT record
Create a TXT record at_mta-sts.yourdomain.com(note the underscore prefix):
v=STSv1; id=202402231200;The id= tag
Any alphanumeric string works, but a timestamp (YYYYMMDDHHMMSS) makes updates traceable. When you update the policy file, youmust change this value— it signals sending MTAs to re-fetch the policy and invalidate their cache.
Keep max_age low at first
Sending MTAs cache your policy for max_age seconds. Start with86400(1 day) during rollout so you can correct mistakes quickly. Increase to604800or higher once the configuration is stable.
4TLS-RPT: Don't Fly Blind
Deploying MTA-STS without TLS-RPT is flying blind.
If your MTA-STS policy blocks a legitimate sending service — because it doesn't support TLS, or because a certificate expired — you will not know. The email simply won't arrive. No bounce. No notification. TLS-RPT is the mandatory feedback loop.
TLS-RPT (SMTP TLS Reporting), defined inRFC 8460, instructs supporting MTAs to send you a daily JSON summary of all inbound TLS connection attempts to your domain. Each report includes:
- Total connection attempts and successful TLS sessions
- Failures due to certificate errors - expired cert, hostname mismatch, untrusted CA
- Failures due to MTA-STS policy violations - server offered plaintext when policy requires TLS
- Source infrastructure that experienced failures - identify legitimate senders with TLS problems before you enforce
The TLS-RPT DNS Record
Publish a TXT record at_smtp._tls.yourdomain.com:
v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com| Tag | Description |
|---|---|
v=TLSRPTv1 | Version identifier. Always TLSRPTv1. |
rua= | Report destination. Use mailto: for email delivery. Multiple destinations are comma-separated (e.g. mailto:addr1,mailto:addr2). HTTPS endpoints are also supported for API ingestion. |
Use a dedicated inbox or a report analyser. Raw TLS-RPT reports are JSON files, similar to DMARC aggregate reports. Tools like Postmark, Dmarcian, and Valimail can parse and visualize them. During the testing phase, review these reports daily — they tell you exactly which sending sources need TLS fixes before you switch to enforce.
5Verifying Your Configuration
After deploying all three components — the HTTPS subdomain, the policy file, and both DNS TXT records — run a new scan in DomainRisk.io. The platform validates each element independently and updates your email security sub-score accordingly.
MTA-STS DNS record
Detected & valid_mta-sts.yourdomain.com resolves as a valid TXT record with a parseable v= and id= value.
Policy file accessible over HTTPS
File served correctlyThe mta-sts.txt file is reachable, served with the correct Content-Type, and contains valid version, mode and mx fields.
SSL certificate on mta-sts subdomain
Certificate validThe certificate is issued by a trusted public CA, matches the hostname, and is not expired. An invalid cert here causes silent policy failures.
Policy mode assessment
Enforce = compliantmode: testing is flagged as medium severity — visibility only, no enforcement. mode: enforce is fully compliant. mode: none is treated as missing.
TLS-RPT record
Reporting active_smtp._tls.yourdomain.com resolves as a valid TXT record with a reachable rua= destination.
Not sure if your domain is protected?
Get a complete Audit Report — MTA-STS compliance, TLS-RPT, DMARC policy, SPF alignment, DKIM and 30+ additional risk factors — in under 60 seconds. Free scan, no credit card required.
6Common Mistakes & FAQ
Can I use a self-signed certificate for the mta-sts subdomain?
No. The entire security model of MTA-STS depends on HTTPS authenticating the policy file. Sending MTAs verify the TLS certificate before trusting the policy content. A self-signed certificate causes the policy to be silently ignored — you get no protection and no error indication. Use Let's Encrypt or any public CA.
What happens if my mta-sts certificate expires while in enforce mode?
Sending MTAs will encounter a certificate error when attempting to fetch your policy and will fall back to their cached version. Once that cache expires (after max_age seconds), behavior varies by implementation: most will refuse to deliver without a valid policy, causing delivery failures. Monitor your mta-sts subdomain certificate as carefully as your main domain — DomainRisk.io checks it on every scan.
Do I need to change the id= value when I update the policy file?
Yes, always. The id= value in the DNS TXT record is the cache invalidation signal. If you update the policy file — for example changing mode from testing to enforce — without changing id=, sending MTAs will continue using their cached policy for up to max_age seconds, which could delay enforcement by days.
Can I deploy MTA-STS on a domain that doesn't send email?
Yes, and you should. Receive-only domains benefit from MTA-STS because it protects inbound connections. Purely parked domains that accept no email should use mode: none alongside their DMARC p=reject policy.
How long should I stay in testing mode before switching to enforce?
Typically 1 to 2 weeks is sufficient. Monitor your TLS-RPT reports daily during this period. When the failure rate for all legitimate sending sources reaches zero, you can safely switch to enforce. Update max_age to a longer value (604800 or higher) at the same time.