MTA-STS

Why MTA-STS exists

Email doesn't actually have to travel encrypted. It usually does. But "usually" leaves a door open.

Mail servers agree to encrypt a connection using something called STARTTLS, basically a polite request to lock the door before they start talking. Most of the time, both sides agree. But that agreement isn't required. Someone sitting on the network in between (rare, but not impossible) can talk both servers out of locking up, and the email slips through unencrypted instead. 

MTA-STS closes that loophole. Basically, your domain posts a sign that says: only deliver to us through the locked door, no exceptions. Can't verify the lock? Then the message doesn't get through at all.

And here's the part that actually matters to you: you'll never click on this in Gmail or Outlook. It's a setting that lives entirely behind the scenes, usually handled by whoever manages a company's email domain (IT, a hosting provider, an email admin). You're not missing a button in your settings.

What it actually does

You don't need to understand DNS to get the gist here. Two things happen behind the scenes, and neither involves you.

First, a domain publishes a note (technically a small file) that says "always require a locked connection." Second, every server trying to deliver mail there has to check that note first. Can't confirm the lock is real? The message gets held back or flagged.

That strictness has a name: mode. Testing mode just watches and reports what would have failed, without blocking anything yet. Enforce mode is the real deal. If you fail the check there, then the email doesn't arrive. Most domains start in testing mode, and for good reason. Jump straight to enforce, and you risk blocking real email from a server that hasn't caught up.

Who actually needs to worry about this

Honestly? Almost nobody, day-to-day.

If you check email through Gmail, Outlook, or Spark on a normal address, someone else already handles this for you. You don't need to do a thing.

It only becomes your problem if you run your own email domain- say, you're a small business owner, or you manage IT for your company. In that case, MTA-STS is one of those quiet, unglamorous settings worth a five-minute conversation with your hosting provider. Google Workspace and Microsoft 365 both offer built-in tools to check and turn it on if your business runs on either platform.

Setting it up, in plain terms

If you do manage a domain, here's the gist, no jargon required: 

• Your domain needs a small settings file, published publicly, listing your mail servers and how strict to be
• You add a short pointer to that file in your domain's DNS settings
• Start in testing mode, so you can see what would break before anything gets blocked
• Once things look clean, switch to enforce mode for the real protection
• Update it whenever you change email providers, or you risk blocking your own mail

Handing this off to whoever already manages your domain (a hosting provider, an IT person, a developer) is usually the smart move. It's not a weekend project, and getting it wrong can bounce real mail without telling you why.

Why it's worth having

It closes a real gap. Rare doesn't mean impossible, and for anything involving client data or financial details, that gap is worth closing.

It's not your only defense, though. MTA-STS protects how a message travels, not who actually sent it. You still need DKIM and DMARC to confirm the sender is who they claim to be.

Start cautious, always. Testing mode exists for a reason, and skipping it is the single most common way a well-meaning setup accidentally blocks real customers' email.

Ask, don't guess. If you run a business domain and aren't sure whether this is set up, that's one quick question for whoever hosts your email, not a research project for you.

Let the provider handle it when you can. If Gmail and Outlook already covers this on their end, there's genuinely nothing here for you to touch.

Related terms

• SMTP server
• DMARC record
• DKIM
• BIMI