MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) tells other mail servers to require an encrypted (TLS) connection when they deliver mail to your domain — and to refuse delivery rather than fall back to an unencrypted connection. It closes the door on downgrade attacks, where an attacker between two mail servers strips the encryption and reads or tampers with messages in transit.

SPF, DKIM, and DMARC prove a message came from you. MTA-STS protects mail coming to you — it’s a different layer, and a good one to add once your DMARC house is in order.

What you actually publish

MTA-STS has two parts, and you need both. Either one alone does nothing:

1. A DNS TXT record at _mta-sts.yourdomain.com — a small record that signals “I have an MTA-STS policy” and carries a version ID.
2. A policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt — the actual rules: which mail servers are valid for your domain, and how strictly to enforce.

Sending servers look up the TXT record first; if it’s there, they fetch the policy file and cache it. If the TXT record is missing, they never look for the policy file at all — so a served policy with no TXT record is invisible. (This is the single most common mistake, and the checker flags it directly.)

Worked example

Say your domain is example.com and your mail runs on Microsoft 365 (so your real MX is something like example-com.mail.protection.outlook.com). Here’s the complete, copy-pasteable setup.

1. The DNS TXT record

Field	Value
Type	TXT
Name / Host	_mta-sts.example.com
Value	v=STSv1; id=20260612000000

The id is just a version stamp you control — a common convention is a timestamp (YYYYMMDDHHMMSS). Whenever you change the policy file, bump this id so sending servers know to re-fetch it instead of using their cached copy.

2. The policy file

Serve this exact text at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
max_age: 86400
mx: example-com.mail.protection.outlook.com

• mode — testing, enforce, or none. Start with testing (more on this below).
• max_age — how long sending servers cache the policy, in seconds. 86400 is one day; production setups often use a week or more once stable.
• mx — every mail server that’s valid for your domain. List your real MX host(s). Wildcards like *.mail.protection.outlook.com are allowed if your provider uses multiple hosts.

The

If a hostname that actually receives your mail is missing from the mx: list, then in enforce mode sending servers will refuse to deliver to it — that’s real mail bouncing. Get the mx: list right before you enforce. The safest way to confirm it: publish in mode: testing first.

Where to host the policy file (free)

The policy file just needs to be served over HTTPS at mta-sts.yourdomain.com with a valid certificate. You don’t need a whole web server for one text file. Common free options:

• Cloudflare Workers — a tiny Worker that returns the policy text, mapped to mta-sts.yourdomain.com. The free tier is more than enough for one text file. Sentura’s in-app Help has a ready-to-paste Worker script you can use as-is — find it under Help → MTA-STS setup inside the app.
• GitHub Pages / Netlify / Cloudflare Pages — host a static .well-known/mta-sts.txt on a subdomain.
• Your existing web host — if you already serve mta-sts.yourdomain.com, just drop the file at the .well-known/ path.

What matters: HTTPS, a valid cert for the mta-sts. subdomain, and the file reachable at exactly /.well-known/mta-sts.txt.

Testing → enforce: the safe path

MTA-STS modes are a deliberate on-ramp:

• mode: testing — sending servers honor the policy but still deliver if TLS fails, and (if they support TLS-RPT) report the failure. This lets you confirm your mx: list is correct against real traffic without risking a single bounced message.
• mode: enforce — sending servers refuse delivery when TLS or the policy can’t be satisfied. This is the real protection.
• mode: none — effectively off; used to retire a policy gracefully.

The honest shortcut

If you send mail through a single, known provider — one Microsoft 365 or Google Workspace MX that you can confirm in one lookup — you can reasonably publish straight to enforce. There’s nothing to discover in a testing period when you already know your only mail path. (Sentura’s own sentura.io does exactly this.)

The testing step earns its place when your setup isn’t that simple: multiple mail servers, a third-party relay or marketing platform that also sends as your domain, or any “I’m not totally sure what my mx: list should be.” In that case, spend a week in testing and read the results — it costs you nothing and guarantees you won’t bounce real mail.

The typical journey: publish testing → confirm the checker goes green and no legitimate mail is failing TLS → change mode to enforce and bump the id in the TXT record so servers re-fetch.

Verify it’s live

Once both pieces are published, confirm they actually work together — the TXT record resolves, the policy file is served over valid HTTPS, the mode is what you intended, and your real MX hosts match the policy. The free checker runs all of that end to end and tells you in plain language what’s green and what’s missing:

Verify yours → Run the free MTA-STS checker against your domain.

Where MTA-STS sits in the bigger picture

MTA-STS protects inbound mail in transit. It pairs naturally with TLS-RPT (which delivers reports when a sending server can’t establish TLS to you) — together they give you enforcement plus visibility. Both are separate from SPF/DKIM/DMARC, which authenticate the sender rather than encrypt the connection.