MTA-STS Lookup

What is MTA-STS Lookup?

MTA-STS Lookup checks your _mta-sts DNS TXT record and fetches your policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt to verify that your inbound SMTP TLS enforcement is correctly configured. Use this tool to confirm that your policy file is reachable, your MX hostnames are listed, and your MX server certificates match your published policy.

Why Opportunistic TLS Is Not Enough

Email sent over SMTP has a fundamental security flaw that SPF and DKIM do not address. When one mail server connects to another, the receiving server says "I support STARTTLS." The sending server sees this and upgrades the connection to encrypted TLS. However, because this happens mid-stream, it is vulnerable to a Man-in-the-Middle (MITM) attack.

An attacker sitting on the network between the two servers can strip the STARTTLS command from the conversation. The sending server then believes the receiver does not support encryption and falls back to plain-text delivery. This is known as a Downgrade Attack. The email is delivered successfully, so the user sees no error, but the attacker has intercepted the message in clear text.

• Passive Eavesdropping: Without forced TLS, any actor with access to internet backbone routers can read your business communications in bulk.
• DNS Spoofing: An attacker can redirect your MX traffic to their own server. Without MTA-STS, the sending server might accept a fake certificate and deliver mail to the attacker.
• Legacy Fallback: Many mail servers emphasize delivery at all costs over security, meaning they will always choose unencrypted delivery over a failed handshake unless explicitly told otherwise.

MTA-STS (RFC 8461) eliminates this opportunistic behavior. It provides a mechanism for a domain owner to publish a policy that officially declares: "My mail servers always support TLS, and you should reject the email if you cannot establish a secure, verified connection."

How MTA-STS Works: Dual-Layer Verification

MTA-STS works by providing a trusted source of truth outside of the SMTP handshake itself. It uses two distinct components: a DNS TXT Record and an HTTPS Policy File. The DNS record signals that a policy exists, but the actual security rules are fetched over a secure HTTPS connection to a specific subdomain (mta-sts.yourdomain.com). This dual-layer approach prevents an attacker from simply spoofing your DNS to disable your security.

The MTA-STS Verification Flow:
1. Sender queries DNS for _mta-sts.example.com TXT record.
2. Sender fetches policy from https://mta-sts.example.com/.well-known/mta-sts.txt.
3. Sender verifies your MX server's TLS certificate against the listed hostnames.
4. If the certificate is invalid or missing, the sender blocks the delivery.

The Strict part of MTA-STS comes from the Max Age parameter in the policy file. This tells the sender how long to remember your security rules. Once a sender like Google Workspace caches your Enforce policy, if an attacker tries to perform a downgrade attack tomorrow, Google will remember that you must have TLS. It will see the missing STARTTLS command, realize it is an attack, and stop the delivery.

Policy Configuration: Modes, Syntax, and Host Verification

The heart of your deployment is the mta-sts.txt policy file, which must be hosted at: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

The file must be served with a text/plain MIME type and must be accessible over a valid, CA-signed HTTPS connection.

Never jump straight to Enforce mode without first observing your traffic in Testing mode. The Testing mode allows you to catch certificate mismatches or legacy sender issues before they cause actual bounces.

; Example MTA-STS Policy File (mta-sts.txt):
version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.com
max_age: 86400

The policy syntax requires an mx tag for every authorized mail server. These are the hostnames the sender will look for in your TLS certificate Subject Alternative Name (SAN) field. If your MX is mail.example.com but your certificate is only for example.com, MTA-STS will fail. You can use wildcards (like *.example.com) to cover multiple servers.

TLS-RPT: The Essential Reporting Companion

MTA-STS is practically blind without its companion record: TLS-RPT (TLS Reporting). While MTA-STS tells senders what to do, TLS-RPT tells them where to report failures. If a sender tries to deliver an encrypted email but your certificate fails the MTA-STS check, you would never know why the mail was missing without TLS-RPT. The sender will send you a daily JSON report detailing successful and failed connections.

The TLS-RPT record is a DNS TXT record placed at _smtp._tls.yourdomain.com:

# Example TLS-RPT DNS record:
_smtp._tls.yourdomain.com  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"

Deploy TLS-RPT before you even create your MTA-STS policy. It will show you your current Opportunistic TLS success rate immediately, giving you a baseline before you move to enforce mode.

MTA-STS vs. DANE

DANE is technically more secure because it does not rely on the CA system, but MTA-STS is more practically secure because it is supported by the major email providers that handle the bulk of the world's traffic. Google and Microsoft both fully support MTA-STS for their hosted mail products, but neither currently supports DANE for inbound mail. If you have a perfectly signed DNSSEC zone, you should implement both — they are not mutually exclusive.

Implementation and Verification Workflow

Deploying MTA-STS is a four-step process:

1. Ensure your MX server's TLS certificate is valid and covers its own hostname.
2. Create the mta-sts subdomain and host your mta-sts.txt policy file.
3. Publish your _mta-sts DNS TXT record with a unique id.
4. Observe TLS-RPT reports for at least 14 days before switching to Enforce mode.

# Verify your policy file is reachable and correct:
curl -v https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

# Expected response:
# < HTTP/1.1 200 OK
# < Content-Type: text/plain; charset=utf-8
# version: STSv1
# mode: testing
# mx: mail.example.com
# max_age: 86400

# Verify your DNS TXT record is live:
dig TXT _mta-sts.yourdomain.com +short
# Expected: "v=STSv1; id=20240101000000"

Common deployment failures come from the bootstrap nature of the standard. If your mta-sts subdomain has an expired SSL certificate, the sender cannot fetch the policy to know that your mail server is valid. Monitor the SSL for your web server at mta-sts.yourdomain.com as diligently as you monitor your mail server's certificate — a single expired web certificate can block all of your inbound corporate email.

For Google Workspace or Office 365, the process is simplified: the mail servers are already secured. You just need to point your policy hostnames to the respective cloud endpoints (e.g., *.aspmx.l.google.com). Leave your policy in Testing mode for at least 14 days of clean reports before committing to Enforce.