MTA-STS: Should You Enable It, and How to Avoid Breaking Inbound Mail

What MTA-STS actually does (and what it doesn’t)

MTA-STS (Mail Transfer Agent Strict Transport Security) is a way for a receiving domain to tell sending MTAs: “When you deliver mail to my MX hosts, use TLS and validate certificates; if you can’t, don’t downgrade to plaintext.” It’s essentially HSTS for SMTP—except SMTP is weirder, older, and has a long tradition of “best effort” delivery.

Mechanically, MTA-STS is two things:

1. A DNS TXT record at _mta-sts.<domain> that advertises the current policy “id”.
2. An HTTPS policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt describing acceptable MX hosts and the enforcement mode.

Senders that support MTA-STS periodically fetch your policy over HTTPS, cache it, and then use it to decide whether to deliver, defer, or fail delivery when TLS isn’t up to spec.

What it protects you from

• Opportunistic TLS downgrade attacks where a network attacker strips STARTTLS and forces plaintext SMTP.
• Some misrouting scenarios where delivery ends up at a host without a valid certificate for your domain.
• “We tried TLS but accepted anything” behavior from some senders; MTA-STS pushes them into strict validation for your domain.

What it does not protect you from

• Compromised sender or receiver. If the mail server is owned, MTA-STS is a seatbelt on a burning car.
• DNS poisoning at the domain owner level. If your DNS is compromised, you can publish policies that break you or reroute you.
• Mail content integrity. That’s DKIM/DMARC territory, not transport.
• All MITM. MTA-STS relies on HTTPS and CA trust; it is not the same as DNSSEC-anchored authentication like DANE.

One operational subtlety: MTA-STS doesn’t force you to do anything at the receiver; it forces senders to refuse delivery if your TLS posture doesn’t match what you promised. That means MTA-STS failures often look like “inbound mail randomly stopped from certain providers,” which is a classic on-call joy.

One quote worth tattooing on every change request: “Hope is not a strategy.” — Gene Kranz. It’s not email-specific, but it’s painfully relevant when you publish “enforce” and hope every edge case is fine.

Should you enable it?

Yes, if you can meet two basic standards consistently:

• Your MX hosts reliably support STARTTLS with modern ciphers and no broken intermediates.
• Your certificates are valid, unexpired, correctly chained, and match the MX hostnames your policy declares.

If that sounds trivial, good. It should be. But “reliably” is where the bodies are buried: load balancers doing TLS interception, legacy appliances, failover MX at a third-party that doesn’t match your hostname list, or a “temporary” DR mail path that’s been temporary since 2019.

Who benefits most

• Domains receiving sensitive mail: payroll, legal, healthcare, finance, customer auth flows.
• Organizations with strict compliance that already require TLS everywhere and need enforceable posture from senders.
• Anyone tired of opportunistic TLS being “optional until it isn’t.”

Who should delay “enforce”

• Domains with heterogeneous inbound paths (multiple MX providers, on-prem + cloud, legacy gateways).
• Anyone without certificate automation and monitoring.
• Teams who can’t answer “What happens when our policy host is down?” without a meeting.

My opinionated recommendation:

• Enable MTA-STS in mode: testing quickly (days), because it’s low-risk and gives you signal.
• Stay in testing until you have evidence: TLS handshakes succeed from multiple networks, your certificates rotate cleanly, and your backup MX situation is clean.
• Move to mode: enforce only after you’ve done a failover drill that includes the mail path. If you’ve never tested MX failover under real conditions, you don’t have failover; you have a bedtime story.

Joke #1: Email security is like flossing: everyone agrees it’s good, and many people only do it after something painful happens.

Interesting facts and history (quick but useful)

• MTA-STS is an IETF RFC from 2018 (RFC 8461). It’s relatively young compared to SMTP, which is why deployments vary widely.
• SMTP STARTTLS was standardized in 2002 (RFC 3207). For years, most delivery was “opportunistic”: use TLS if offered, otherwise shrug and send plaintext.
• MTA-STS was designed partly because STARTTLS stripping is real. It’s not theoretical; network attackers can tamper with the server’s advertised capabilities.
• DANE for SMTP existed earlier and uses DNSSEC to authenticate TLS keys. MTA-STS took the pragmatic path: HTTPS + public CAs, because DNSSEC adoption for mail remains patchy.
• The policy is fetched over HTTPS from a fixed hostname (mta-sts.<domain>). That’s both convenient and an operational dependency you must keep alive.
• Policies are cached by senders, which means your mistakes can linger and your fixes can take time to propagate. “We fixed it” is not the same as “senders stopped caching the broken policy.”
• The DNS record contains an “id” you bump to signal changes. This is effectively cache-busting for senders.
• TLS-RPT exists as the companion: a reporting mechanism where senders can report TLS failures to you. It’s the closest thing to observability you get from the outside.

How inbound mail breaks with MTA-STS

MTA-STS doesn’t usually break mail immediately when you publish it. The nasty part is delayed failure:

• Senders fetch your policy on their schedule.
• They cache it for a while.
• They only enforce it when delivering to you.

So you can publish “enforce” today, and discover the damage tomorrow when a major sender refreshes policy and suddenly refuses to deliver to your “backup” MX that’s actually a third-party spam appliance with a certificate that expired in May.

Failure mode map (the usual suspects)

• MX list mismatch: your policy lists mx1.example.com and mx2.example.com, but your DNS also advertises mx-backup.vendor.net. Some senders might try it; policy says “no,” and delivery fails under enforce.
• TLS handshake fails: unsupported ciphers, TLS version mismatch, broken SNI behavior, or STARTTLS offered but not actually working reliably.
• Certificate issues: expired cert, wrong hostname, missing intermediate chain, or an RSA key too small for modern clients.
• Misbehaving load balancer: TLS offload that doesn’t pass SNI correctly or presents a default certificate to some senders.
• Policy host unavailable: mta-sts.example.com is down or blocked. Some senders will keep cached policy; others may treat fetch failures differently. You don’t want this to be a surprise dependency.
• Unexpected “DR” path: you fail over inbound mail during an incident, but the DR MX host isn’t in policy, or its cert doesn’t validate. Under enforce, failover turns into self-inflicted outage.

The theme: MTA-STS forces you to align what you say (policy) with what you do (MX + TLS reality). The technical work is manageable. The organizational work—inventorying all inbound paths—is where you earn your keep.

Fast diagnosis playbook

When someone says “we’re not receiving emails,” you can burn hours debating DMARC, spam filtering, and user error. MTA-STS outages have a distinct smell: specific senders failing, TLS errors in their logs, and a recent policy/cert/DNS change.

First: confirm whether MTA-STS is in play

1. Check the domain’s _mta-sts TXT record exists and what the id is.
2. Fetch the policy file and confirm mode and MX patterns.
3. Look for a recent policy id bump or certificate change.

Second: validate MX + TLS from the outside

1. Resolve MX records and list all hosts. Compare to the policy’s mx: lines.
2. Test STARTTLS and certificate validation against each MX host on port 25.
3. Confirm the certificate chain and hostname match what the sender will validate.

Third: correlate with real delivery failures

1. Check your SMTP logs for connection attempts, STARTTLS negotiation, and failures.
2. Look for TLS alert codes, handshake failures, or “no shared cipher.”
3. If you publish TLS-RPT, inspect reports for patterns: specific MX, specific TLS version, specific sender.

If you do those three rounds, you’ll usually land on one of: “policy too strict for reality,” “cert broken,” or “MX changed without policy update.” Then the fix is straightforward.

Practical tasks: commands, outputs, decisions (12+)

These are the checks I actually run when I’m on the hook for inbound delivery. Each task includes the command, an example of what you might see, what it means, and what decision to make.

Task 1: Check if MTA-STS is published in DNS

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T1200Z"

What it means: MTA-STS is enabled for example.com, and senders will cache policy keyed by id.

Decision: If mail is failing and you recently changed MX/TLS, consider whether the policy file matches reality. If you need to push an updated policy, you’ll bump the id after updating the file.

Task 2: Resolve MX records and inventory all inbound targets

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.
50 mx-backup.vendor.net.

What it means: There are three delivery targets, including a vendor backup.

Decision: Ensure the policy includes patterns that match every MX hostname you advertise, or remove the MX you can’t bring into compliance. Under enforce, “forgotten” MX hosts become outages.

Task 3: Fetch the MTA-STS policy file over HTTPS

cr0x@server:~$ curl -fsS https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

What it means: Enforce mode is active; only mx1 and mx2 are allowed.

Decision: If you still publish mx-backup.vendor.net in DNS, you either add it to policy (if it can validate) or remove it from MX to avoid senders attempting it and failing.

Task 4: Verify the policy host certificate and chain

cr0x@server:~$ echo | openssl s_client -connect mta-sts.example.com:443 -servername mta-sts.example.com -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mta-sts.example.com
issuer=C = US, O = Example CA, CN = Example Issuing CA 01
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT

What it means: The HTTPS endpoint presents a cert for the correct hostname and it’s not expired.

Decision: If the dates are wrong or CN/SAN mismatches, fix HTTPS first. Senders can’t fetch policy reliably if this breaks, and some will keep enforcing cached policy anyway.

Task 5: Confirm that the policy file is served with HTTP 200 and sane headers

cr0x@server:~$ curl -sSI https://mta-sts.example.com/.well-known/mta-sts.txt | sed -n '1,8p'
HTTP/2 200
content-type: text/plain
cache-control: max-age=300
content-length: 104
date: Fri, 03 Jan 2026 12:15:11 GMT

What it means: It’s reachable and returns plaintext. Short caching is fine; senders still cache based on max_age in the policy.

Decision: If you see redirects to a different hostname, auth challenges, or non-200 codes, fix it. Keep it boring: static text file, stable path, public access.

Task 6: Validate STARTTLS and certificate verification to each MX

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -verify_return_error 2>/dev/null | egrep -i "Verify return code|subject=|issuer="
subject=CN = mx1.example.com
issuer=C = US, O = Example CA, CN = Example Issuing CA 01
Verify return code: 0 (ok)

What it means: TLS negotiates and the cert validates for mx1.

Decision: Repeat for every MX. If any MX fails validation, you either fix that MX or ensure it’s not advertised/allowed when enforce is on.

Task 7: Check SMTP banner and STARTTLS support

cr0x@server:~$ printf 'EHLO test.example\r\nQUIT\r\n' | nc -w 5 mx2.example.com 25
220 mx2.example.com ESMTP Postfix
250-mx2.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 CHUNKING

What it means: The server advertises STARTTLS. Good.

Decision: If STARTTLS isn’t advertised consistently (intermittent), you have a load balancer or backend variance problem. MTA-STS will amplify that into hard delivery failures.

Task 8: Detect “default certificate” problems behind a load balancer (SNI)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 2>/dev/null | openssl x509 -noout -subject
subject=CN = lb-default.example.net

What it means: Without SNI, the server presents a default cert that doesn’t match mx1.example.com.

Decision: Many MTAs do not send SNI on SMTP STARTTLS. Don’t rely on it. Fix the frontend to present the correct certificate by default for that IP:port, or dedicate listener IPs per hostname.

Task 9: Confirm TLS versions and ciphers (spot legacy breakage)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_2 -brief /dev/null | egrep -i "Protocol|Ciphersuite|Verification"
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Verification: OK

What it means: TLS 1.2 works and verifies.

Decision: If only TLS 1.0 works, modern senders may refuse even without MTA-STS. With MTA-STS enforce, you’re demanding strict validation, so bring your TLS stack into the current decade.

Task 10: Check Postfix TLS settings (receiver side)

cr0x@server:~$ postconf -n | egrep "smtpd_tls|smtpd_tls_security_level|smtpd_tls_cert_file|smtpd_tls_key_file"
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.example.com/privkey.pem
smtpd_tls_loglevel = 1

What it means: The server offers TLS (“may”), and you can see which cert it uses.

Decision: Ensure the cert paths match the hostname you advertise. If you have multiple MX names on one server, you can’t magically present different certs without careful listener/IP design.

Task 11: Spot TLS failures in mail logs quickly

cr0x@server:~$ sudo grep -E "TLS|SSL|handshake|STARTTLS" /var/log/mail.log | tail -n 8
Jan  3 12:07:51 mx1 postfix/smtpd[18291]: warning: TLS library problem: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
Jan  3 12:08:02 mx1 postfix/smtpd[18302]: warning: TLS library problem: error:0A0000C1:SSL routines::no shared cipher
Jan  3 12:08:15 mx1 postfix/smtpd[18310]: Anonymous TLS connection established from mail-oi1-f172.google.com[209.85.167.172]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256

What it means: You’re seeing cipher/handshake issues with some clients, but success with others. That points to compatibility variance.

Decision: Decide whether to broaden cipher support (carefully) or accept that some legacy senders will fail under enforce. If those legacy senders matter, you’ll need a compatibility plan.

Task 12: Confirm policy id and caching behavior (did you bump id?)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T1200Z"

What it means: If you changed the policy file but not the id, many senders will keep using cached policy until it expires.

Decision: When changing mode or mx lines, bump id. Treat it like a config version.

Task 13: Verify TLS-RPT is published (observability from the outside)

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tls-reports@example.com"

What it means: Senders that support TLS reporting may send you aggregated failure reports.

Decision: If you’re going to enforce, publish TLS-RPT and make sure that mailbox is monitored. Otherwise you’re flying IFR with the instruments turned off.

Task 14: Check the certificate actually contains the MX hostname in SAN

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx2.example.com:25 -servername mx2.example.com 2>/dev/null | openssl x509 -noout -text | sed -n '/Subject Alternative Name/,+1p'
            X509v3 Subject Alternative Name:
                DNS:mx2.example.com, DNS:mx2.internal.example.com

What it means: The certificate covers the public MX name. Good.

Decision: If SAN doesn’t include the public MX hostname, fix cert issuance. CN-only is not enough for many modern validators.

Task 15: Confirm the vendor backup MX can do validated TLS (or remove it)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx-backup.vendor.net:25 -verify_return_error 2>/dev/null | egrep -i "subject=|Verify return code"
subject=CN = mx-backup.vendor.net
Verify return code: 0 (ok)

What it means: The vendor MX supports validated TLS for its own hostname. That’s necessary but not sufficient.

Decision: You must decide whether to include mx-backup.vendor.net in your MTA-STS policy. If you keep it in DNS but exclude it from policy while in enforce, some deliveries will fail when senders try lower-priority MX.

Three corporate mini-stories from the trenches

1) The incident caused by a wrong assumption: “Of course our backup MX is fine”

A mid-sized company had a clean mail setup: two MX hosts in active-active, certificates automated, and a “backup” MX pointing to a third-party hygiene gateway with a higher priority number. That backup was meant to queue mail if the primary site went dark.

They rolled out MTA-STS in mode: enforce after a security review. The policy listed only their two main MX hosts. The assumption was simple: “Senders will try the primary MX first; the backup is just a safety net.”

Then a maintenance window introduced a short-lived routing issue to one primary MX IP range from a major sender’s region. Not a total outage, just a partial path failure. The sender did what SMTP is designed to do: it tried alternate MX records. The next choice was the vendor hygiene gateway.

Under MTA-STS enforce, that vendor hostname wasn’t allowed. The sender refused delivery rather than “downgrade” to a non-policy MX. From the company’s perspective, inbound mail failed only from certain senders, for certain recipients, during a window that didn’t correlate with their own monitoring.

The fix was not heroic. They either had to remove the vendor MX from DNS, or include it in the policy and verify its TLS posture. The lesson was the painful one: SMTP failover behavior is not a theoretical feature; it’s what happens when the internet burps.

2) The optimization that backfired: “Let’s put everything behind one IP”

An enterprise mail team decided to simplify their edge: one anycast VIP in front of multiple MX hostnames, one load balancer fleet, one certificate bundle, fewer firewall rules. On paper it was tidy. In diagrams, it was beautiful.

In reality, SMTP STARTTLS does not behave like modern HTTPS traffic. Some sending MTAs don’t send SNI. Others behave inconsistently across versions. The load balancer relied on SNI to pick the correct certificate per hostname. When SNI was absent, it served a default certificate that didn’t match the MX hostname.

Before MTA-STS, this caused “some TLS sessions fail, then delivery falls back to plaintext” behavior. Ugly, but mail arrived. After MTA-STS enforce, those same sessions became hard failures because the sender was required to validate certificates. The optimization didn’t just fail; it failed loudly and selectively.

They backed out the design: dedicated listener IPs per public MX hostname, each presenting a certificate that matches without relying on SNI. It cost a few more IPs and a bit more config. It bought them reliable delivery.

Joke #2: The load balancer promised “single pane of glass,” and delivered “single point of sadness.”

3) The boring but correct practice that saved the day: “Treat policy like config with a deployment pipeline”

A financial services company enabled MTA-STS in testing mode early and kept it there longer than the security team wanted. The mail team insisted on boring process: a git repo for the policy file, peer review, and a tiny CI job that validated syntax and compared policy MX entries against live DNS.

They also automated certificate expiry checks for every MX hostname and the policy host. Not “someone gets an email 30 days before expiry,” but actual monitoring wired to paging during business hours with clear runbooks.

When a datacenter migration required changing MX hostnames, they staged it: publish new MX alongside old, update MTA-STS policy to include both, bump the id, wait for caching windows, then remove old entries. Slow, deliberate, and slightly annoying.

During the migration, a vendor tried to “help” by inserting a temporary relay MX. The CI check flagged that the new MX wasn’t in policy and would break enforce later. The change got caught before it hit production DNS.

Nothing dramatic happened. That’s the point. In operations, the highest compliment is “it was uneventful,” followed closely by “nobody noticed.”

Common mistakes: symptom → root cause → fix

1) Symptom: Gmail/Microsoft defers delivery with TLS-related errors

Root cause: Your MX offers STARTTLS but presents an invalid certificate (wrong hostname, expired, missing intermediate) or fails negotiation intermittently.

Fix: Validate with openssl s_client -starttls smtp against each MX. Ensure the presented certificate matches the MX hostname and chain is complete. Fix load balancer default cert behavior.

2) Symptom: Only some senders fail; others deliver fine

Root cause: Policy caching and sender heterogeneity. Some senders fetched your policy and enforce it; others haven’t yet, or treat failures differently. Alternatively, only some senders hit the problematic MX/IP due to routing.

Fix: Identify which senders fail, then reproduce from outside networks. Check TLS-RPT if available. Verify every MX endpoint, not just the one you usually see in logs.

3) Symptom: Mail fails during failover/maintenance but works normally

Root cause: Your DR/backup MX isn’t included in policy or can’t pass strict TLS validation.

Fix: Include the DR MX in policy and keep its TLS posture compliant, or don’t advertise it in MX. Test failover under enforce before you need it.

4) Symptom: You updated the policy file but senders still behave as if it’s old

Root cause: You forgot to bump the DNS TXT id, so senders continue using cached policy.

Fix: Update the policy file, then bump the id in DNS. Plan for caching delays based on max_age and sender behavior.

5) Symptom: Policy fetch fails (404/redirect/auth) and enforcement becomes unpredictable

Root cause: Your mta-sts host is behind WAF rules, redirects HTTP→HTTPS incorrectly, requires authentication, blocks certain user agents, or has intermittent availability.

Fix: Serve the policy as a simple static file over HTTPS with a valid cert. Avoid auth, avoid geo-blocking, avoid cleverness.

6) Symptom: Some MTAs complain about “no shared cipher” or TLS version alerts

Root cause: Over-hardened TLS config on your MX, or old TLS stack on the sender. Under enforce, some senders will fail rather than downgrade.

Fix: Decide business-appropriate minimums. Support TLS 1.2 broadly. Keep ciphers modern but not absurdly restrictive. Monitor who fails and whether they matter.

7) Symptom: Everything looks correct, but inbound still fails for a subset of recipients

Root cause: MX records differ by region due to split-horizon DNS, CDN DNS steering, or stale resolver caches returning old MX. Your policy may not cover all variants.

Fix: Query public resolvers from multiple regions (or via your monitoring). Ensure the policy covers all public MX hostnames that might be returned.

Checklists / step-by-step plan (safe rollout)

Step 0: Inventory the real inbound mail path

• List all MX records (including “backup” and vendor gateways).
• List any inbound SMTP proxies/load balancers and how certificates are presented.
• List DR/failover scenarios and what MX changes during an incident.

Step 1: Make TLS boring (before you publish enforce)

• Automate cert issuance/renewal for every public MX hostname.
• Ensure full chain is served (use fullchain.pem where appropriate).
• Confirm STARTTLS is consistently offered and works across all backends.
• Avoid relying on SMTP SNI to select certificates. Prefer dedicated IP:port listeners per hostname if needed.

Step 2: Stand up the policy host correctly

• Provide mta-sts.<domain> in DNS with stable hosting.
• Serve /.well-known/mta-sts.txt as a static plaintext file over HTTPS.
• Use a valid certificate and don’t block access with WAF rules that treat the world as hostile (senders are the world).

Step 3: Publish MTA-STS in testing mode

Start with:

• mode: testing
• MX patterns that match all your actual inbound MX hosts
• max_age set to something modest (a week is common; shorter during early iteration can be reasonable)

Then publish the TXT record with a clear id.

Step 4: Add TLS-RPT and actually read it

• Publish _smtp._tls TXT pointing reports to a monitored address.
• Set up a mailbox rule or ingestion pipeline so reports don’t rot.
• Look for: which MX fails, why (certificate vs handshake vs DNS), and whether it’s consistent.

Step 5: Do a failover drill while still in testing

• Simulate primary MX loss (or route change) and observe which MX senders choose next.
• Confirm the alternate path is allowed by policy and validates TLS.
• Fix the drift now, not during an outage.

Step 6: Move to enforce with a change window and rollback plan

• Update policy file to mode: enforce.
• Bump id in DNS.
• Monitor logs and TLS-RPT for at least one caching window.
• Rollback plan: revert to mode: testing and bump id again if you see material delivery failures.

Step 7: Keep it alive (the part everyone forgets)

• Monitor certificate expiry for: every MX + mta-sts host.
• Monitor HTTPS availability of the policy file.
• Treat MX changes as a coupled change: DNS + policy + certs, shipped together.

FAQ

1) Will MTA-STS stop spam?

No. MTA-STS is transport security. It helps prevent TLS downgrade and enforces certificate validation. Spam control is primarily SPF/DKIM/DMARC plus filtering.

2) Is MTA-STS redundant if we already use STARTTLS?

STARTTLS alone is typically opportunistic: if TLS fails, many senders fall back to plaintext. MTA-STS tells supporting senders not to fall back for your domain.

3) Should we go straight to enforce?

Not unless you’ve validated every MX endpoint, including DR and vendor paths, and you have certificate automation and monitoring. Testing mode is cheap insurance.

4) What does the policy id actually do?

It’s a version signal. Senders cache policy; when the id changes, they know to fetch a new policy. If you change policy without changing id, many senders won’t notice quickly.

5) Can we list IP addresses in MTA-STS instead of hostnames?

No. MTA-STS policies match MX hostnames (with exact or wildcard patterns). That’s one reason load balancer and certificate behavior matters so much.

6) What if our MX hostnames are managed by a vendor and change?

Then you need an operational contract: stable hostnames, or a process to update policy and bump id reliably. If the vendor can’t provide stability, enforce mode becomes a recurring incident generator.

7) Does MTA-STS require DNSSEC?

No. That’s a key difference from DANE. MTA-STS relies on HTTPS and the public CA ecosystem for policy authenticity.

8) If our policy host goes down, does mail stop?

Usually not immediately, because senders cache policies. But it creates ambiguity and delayed failures. Keep mta-sts.<domain> highly available anyway; it’s a small service with outsized blast radius.

9) What max_age should we use?

Common values are on the order of days to weeks. Shorter ages reduce how long mistakes linger but increase fetch frequency. Pick something you can operationally support, and remember caching behavior still varies by sender.

10) How do we “roll back” if enforce breaks inbound mail?

Update the policy to mode: testing (or temporarily loosen MX patterns), then bump the DNS id. Expect some senders to keep enforcing cached policy until they refresh.

Conclusion: next steps you can ship this week

MTA-STS is worth enabling because opportunistic TLS is not a security boundary; it’s a polite suggestion. But enforce mode is a promise, and the internet will hold you to it.

Practical next steps:

1. Inventory all MX targets and compare them to reality (including vendor and DR paths).
2. Stand up the policy host as a static HTTPS file with a valid certificate and boring availability.
3. Publish MTA-STS in testing mode with correct MX patterns and a sane max_age.
4. Validate STARTTLS + certificate verification to every MX from outside your network.
5. Publish TLS-RPT and route reports to something monitored.
6. Do one failover drill while still in testing. Fix what breaks. Then move to enforce with a rollback plan.

If you do this like a production change—versioned config, monitored endpoints, rehearsed failover—MTA-STS becomes one of the rare email security wins that doesn’t punish you later. If you do it like a checkbox, it will eventually page you at 2 a.m. and demand a sacrifice.