MTA-STS: Keeping Your Emails Locked in Transit

How MTA-STS Works

Let’s say you send a client an invoice. That email hops between servers before reaching their inbox. Along the way, it could be read by someone else — unless the connection is encrypted. MTA-STS (Mail Transfer Agent Strict Transport Security) ensures that other email servers always deliver mail to your domain over an encrypted channel. Think of it like a “password-protected” sign on your digital mailbox: it announces to the internet, “Only encrypted mail allowed here.” Without it, an attacker can trick a sending server into delivering your messages in plain text — a postcard anyone can read. This matters because email was designed decades ago without built-in privacy. MTA-STS is a modern add-on that fills that gap, and it’s supported by Google Workspace and Microsoft 365, the tools you’re probably already using.

Real-World Analogy

Imagine a busy package delivery service. They’ll hand your parcel to anyone who answers the door. MTA-STS is like a sign that says “ID required before drop-off.” Delivery drivers check the sign before they even knock — and if they can’t verify ID, they refuse to leave the package.

Here’s what happens when a customer sends an email to you. Their email server looks up your domain’s security policy. It’s a short notice you’ve placed at a public web address that says, “I only accept encrypted mail for the next few weeks.” The sending server checks: can I encrypt the connection? If yes, the email goes through. If no, it won’t deliver the message — instead it will queue and retry later, or bounce back to the sender. Encryption becomes mandatory, not optional.

This stops a real attack called STRIPTLS, where a bad actor between the two servers pretends that encryption isn’t available, forcing the email to be sent in readable plain text. With MTA-STS, the sender knows you demand encryption and refuses to send anything unprotected.

Technical Details

▸Policy file: Hosted at with a TXT record pointing to it. Contains mode (, , ), max age, and included subdomains.

▸DNS TXT record: must have a record to signal policy freshness.

▸Reporting (optional): A TXT record can specify where aggregated TLS failure reports go.

▸TLS 1.2 or higher required. MX hosts must present a valid certificate matching the mail server hostname.

Why It Matters for Your Business

Email without MTA-STS is like an open house. Most of the time, servers do encrypt messages voluntarily, but an attacker can force them to drop that protection without anyone noticing. Invoices, contracts, password resets, and sensitive conversations become visible to anyone sitting between you and your client’s email server.

If your domain enforces MTA-STS, you’re telling everyone: “My email is private, always.” That builds trust with partners, customers, and regulators. Many compliance standards (like GDPR or HIPAA) expect you to take reasonable steps to protect data in transit, and MTA-STS checks that box.

On the other hand, a missing or misconfigured policy is a silent vulnerability. You won’t see a red flag in your inbox, but a TechSpy scan will surface it as a critical gap — one that leaves your domain open to interception and reputational damage.

Common Issues and Warning Signs

Because MTA-STS works behind the scenes, you won’t get a daily alert if it’s broken. The first sign is often a security scan result or an audit finding. Here are symptoms that something isn’t right:

Common Issues

You see a “missing MTA-STS” warning in your TechSpy scan → the required DNS record or policy file is absent.

Emails from outside sometimes fail to arrive when sent from heavily secured servers → the sending server might be aborting delivery because your policy is present but unenforceable (e.g., invalid certificate).

Your domain uses a third-party email provider (not Google/Microsoft) and no one has checked for MTA-STS support → older or self‑managed mail systems often don’t set it up by default.

A security audit flags “email encryption downgrade” risk → without MTA-STS, your domain is vulnerable to STRIPTLS attacks.

How to Fix or Improve MTA-STS

The good news: if your email is with Google Workspace or Microsoft 365, they already handle the heavy lifting. You just need to publish two DNS TXT records to activate the policy. If you don’t manage DNS directly, forward this section to your IT team or hosting provider.

Even if you’re not the technical person, you can take action: log into TechSpy, copy the scan result, and email it to your IT support with a note that says, “Our domain needs MTA-STS turned on — here’s what we’re missing.” That one forward can make your business email a whole lot safer.

1Choose your email provider and follow their MTA-STS setup guide: Google Workspace users can turn it on with two TXT records (one for and one for ). Microsoft 365 users can do the same through the Exchange admin center or direct DNS entries.

2Create the policy TXT record at (replace \(yourdomain.com\)). This record tells the world that a policy file exists and its version id.

3(If using a custom mail server) Host the actual policy file at with content like . If you’re on Google/Microsoft, they host this for you.

4Wait up to 24 hours for DNS propagation, then re‑run your TechSpy scan to confirm the warning is gone.