A field-by-field reference for the MTA-STS policy file format defined in RFC 8461. Covers every permitted field, the exact content-type and HTTP requirements, hosting patterns, real UK deployment examples, and how to debug common policy-file failures.
version fieldmode fieldmx fieldmax_age fieldThe MTA-STS policy file must be served at exactly:
https://mta-sts.DOMAIN/.well-known/mta-sts.txtFor the domain firm.co.uk, the URL is https://mta-sts.firm.co.uk/.well-known/mta-sts.txt. The mta-sts subdomain is a convention fixed by RFC 8461. No other subdomain works.
The path /.well-known/mta-sts.txt is equally fixed. The .well-known prefix follows RFC 8615 for URI reservations. The file name is lowercase, .txt suffix.
The file is plain text. UNIX line endings (LF or CRLF — both accepted). UTF-8 encoding. No BOM. Each line contains one field in the form name: value. Blank lines are ignored. Comments are not supported.
A minimal valid file:
version: STSv1
mode: enforce
mx: mail.firm.co.uk
max_age: 1209600
Fields are order-independent though convention places version first. Whitespace around the colon is tolerated.
version fieldRequired. Must have the value STSv1. The only defined version. A file without this line is invalid.
version: STSv1mode fieldRequired. Three permitted values:
| Value | Behaviour |
|---|---|
none | Disable enforcement. Equivalent to having no MTA-STS. Used briefly to turn the policy off without removing the records. |
testing | Log failures (via TLS-RPT) but still deliver mail. Initial deployment state. |
enforce | Refuse to deliver mail if TLS negotiation or certificate validation fails. Production state. |
Progression for a new deployment: testing for 1-2 weeks, then enforce after TLS-RPT reports show clean operation.
mx fieldRequired. Lists the hostnames senders should expect as valid MX targets. Multiple values allowed, each on its own line:
mx: mail1.firm.co.uk
mx: mail2.firm.co.uk
mx: backup-mail.firm.co.ukWildcards permitted on the leftmost label:
mx: *.firm.co.ukMatches any hostname at the first level under firm.co.uk. Does not match multi-label subdomains — mail.east.firm.co.uk does not match *.firm.co.uk.
When a sender connects to your MX, it:
mx: entries in your policy.mx: entry matches the certificate's hostname coverage.If your MX resolves to mail.firm.co.uk and the certificate covers only firm.co.uk (without the mail prefix), the match fails in enforce mode. Ensure certificates cover the exact MX hostname.
max_age fieldRequired. The number of seconds senders should cache the policy. Common values:
max_age: 86400 — 24 hours. Short, for rapid iteration during initial deployment.max_age: 604800 — 7 days. Reasonable during testing mode.max_age: 1209600 — 14 days. Steady state. Most UK production deployments use this.max_age: 2592000 — 30 days. Long-term cache, reserved for very stable deployments.RFC 8461 minimum is 86400 (24 hours); maximum 31557600 (approximately 1 year). Practical sweet spot is 7-14 days.
Shorter max_age means policy changes propagate faster but senders fetch more often. Longer means slower change propagation but less fetching load. Balance accordingly.
Requirements from RFC 8461:
mta-sts.domain must chain to a trusted root.Most modern HTTP servers (nginx, Apache, Caddy) return 200 with text/plain for .txt files by default. Sometimes MIME configuration needs a tweak; test with curl -v.
The HTTPS certificate on mta-sts.firm.co.uk must:
mta-sts.firm.co.uk.A wildcard certificate covering *.firm.co.uk works if it includes the mta-sts subdomain in its scope. A dedicated certificate for just mta-sts.firm.co.uk also works. Let's Encrypt is fine.
version: STSv1
mode: enforce
mx: mail.firm.co.uk
max_age: 1209600version: STSv1
mode: enforce
mx: mail1.firm.co.uk
mx: mail2.firm.co.uk
max_age: 1209600version: STSv1
mode: enforce
mx: *.mail.firm.co.uk
max_age: 1209600Matches any hostname like server1.mail.firm.co.uk, server2.mail.firm.co.uk.
version: STSv1
mode: testing
mx: mail.firm.co.uk
max_age: 604800Shorter max_age (7 days) during testing allows faster iteration.
version: STSv1
mode: enforce
mx: mail.epost.plus
max_age: 1209600Single MX, enforce mode, 14-day cache. A hardened production configuration.
If your main site is at https://firm.co.uk, add mta-sts.firm.co.uk as another vhost on the same web server. Simplest approach for small UK businesses.
Larger organisations with separate web infrastructure can point mta-sts.firm.co.uk at a tiny dedicated host — even a small EC2 instance or a shared hosting account. MTA-STS traffic is minimal.
The policy is a static file; static hosting services work fine. Configure:
mta-sts.firm.co.uk with HTTPS./.well-known/mta-sts.txt.application/octet-stream for .txt — override to text/plain).Front the policy with a CDN for global low-latency delivery. Cache TTL on the CDN can match max_age. Useful for large UK businesses with international receiver traffic.
Providers like SmartXHosting host MTA-STS for customers automatically. No separate web server needed.
Path wrong — must be /.well-known/mta-sts.txt. Check with curl -v.
Must be Content-Type: text/plain. Fix the web server's MIME mapping for .txt files.
Run openssl s_client -connect mta-sts.firm.co.uk:443. Confirm valid cert chain.
dig TXT _mta-sts.firm.co.uk. Must return v=STSv1; id=....
Check version is exactly STSv1; mode is one of the three permitted values; mx matches your real MX; max_age is a reasonable integer.
Common cause of enforce-mode rejection. Verify with openssl s_client -connect mail.firm.co.uk:25 -starttls smtp and inspect the cert's subject and SAN fields. Must cover the MX hostname or a matching wildcard.
The _mta-sts.domain TXT record signals to senders that a policy exists and carries the id that changes whenever the policy changes. Senders compare their cached id against the current DNS value — a different id triggers a re-fetch of the policy file.
Practical implication: update the id every time you change the policy file. A timestamp is the simplest pattern (id=20260423120000).
If you add or remove MX records, update the MTA-STS policy at the same time. An MX pointing at a hostname not listed in the policy will fail validation under enforce mode.
Let's Encrypt certificates renew every 60-90 days. The policy file does not need updating on certificate renewal as long as the certificate continues to cover the MX hostname. Automated renewal processes should verify the SAN fields remain correct.
MTA-STS does not require DNSSEC, but DNSSEC-signing your zone protects the _mta-sts TXT record from DNS spoofing attacks. The HTTPS policy fetch provides independent trust, but DNSSEC closes a small remaining gap.
The HTTPS server hosting the policy file must be reliable. Brief downtime does not break mail (senders use cached policies) but extended downtime across the max_age window means new senders cannot fetch the policy — they fall back to opportunistic TLS.
For UK business operations, host the policy on infrastructure with the same reliability expectations as your main web presence: monitor with your uptime service, alert on outages.
Treat the policy file as infrastructure-as-code. Typical workflow:
id simultaneously.curl and dig.Deploying MTA-STS without TLS-RPT is flying blind. TLS-RPT reports reveal whether your policy is actually being respected and whether TLS negotiation is succeeding. Always deploy both together.
Q: Can I combine MTA-STS with DMARC in the same infrastructure?
A: Yes — they are independent. DMARC covers authentication; MTA-STS covers transport. Deploy both for layered protection.
Q: Does MTA-STS require DNSSEC?
A: No. MTA-STS is designed to work without DNSSEC by relying on HTTPS trust for policy distribution. DNSSEC is still valuable (it protects the _mta-sts TXT record itself) but not required.
Q: What is the minimum mode to be considered "MTA-STS deployed"?
A: testing counts as deployed — you are publishing a policy and collecting reports. enforce is the fully-protective state. NCSC Mail Check scores testing positively, enforce more so.
Q: Can I use MTA-STS for outbound mail rather than inbound?
A: MTA-STS is published by the receiving domain. Your outbound mail respects other domains' published MTA-STS policies. For your own outbound, you publish your policy and receivers enforce it. The protocol is one-directional in terms of who publishes.
Q: How do senders know to look for my MTA-STS policy?
A: They query DNS for _mta-sts.yourdomain before delivering mail. If the TXT record exists, they fetch the HTTPS policy file and cache it.
Q: What is the difference between mode: none and removing the DNS record?
A: mode: none is an explicit "this domain used to have a policy but does not now" — senders that previously cached the policy respect the update. Removing the DNS record and policy file is equivalent to having never deployed; senders fall back to opportunistic TLS.
Q: If my MTA-STS HTTPS is down during an update, does that matter?
A: Senders with cached policies continue using them. New senders (or senders after cache expiry) see the DNS record but cannot fetch the policy — they fall back to opportunistic TLS. Downtime of hours does not break mail delivery.
Q: Can I serve the policy over HTTP/2 or HTTP/3?
A: Yes. The HTTP version does not matter; senders just need to retrieve the content over HTTPS. HTTP/2 and HTTP/3 are both supported.
Q: Does MTA-STS affect client-side mail access (IMAP, POP3)?
A: No. MTA-STS governs only server-to-server SMTP transport. Client access is separately protected by IMAPS/POP3S.
Q: Can I use MTA-STS for subdomain mail?
A: Yes — each subdomain that has its own MX can have its own MTA-STS. Publish the DNS record and policy file at the subdomain level (e.g. mta-sts.sub.firm.co.uk, _mta-sts.sub.firm.co.uk).
Q: How often do major UK receivers respect MTA-STS policies?
A: Gmail, Microsoft 365, Fastmail and most modern UK receivers respect MTA-STS. Older or smaller receivers may ignore it. For the majority of UK business mail traffic, MTA-STS is enforced.
Q: What is the overhead of MTA-STS on a mail server?
A: Zero. The mail server does not need to change — the policy is served by a separate web server and enforced by sending mail servers. Your infrastructure just publishes a file.
Q: How do I test my MTA-STS with tools like Hardenize?
A: Enter your domain at hardenize.com. The report shows every layer of transport security including MTA-STS deployment status. For UK public sector domains, NCSC Mail Check is the equivalent.
Q: Can MTA-STS cause outage for my inbound mail if misconfigured?
A: Only in enforce mode. In testing mode, misconfigurations produce report data but do not block mail. The safe path is always testing first, enforce after reports confirm clean operation.
Q: Does MTA-STS work if my MX is at a different organisational domain?
A: Yes. If your MX for firm.co.uk resolves to mail.provider.net, the MTA-STS policy lists that provider hostname. The sender checks the certificate on the provider host against your policy. Common for hosted mail setups.
Q: What if I have multiple brand domains — do I need separate MTA-STS per domain?
A: Yes. Each domain publishes its own _mta-sts TXT and policy file at its own mta-sts.domain. No shortcut.
Q: How do UK regulators view MTA-STS deployment?
A: NCSC mandates it for central government (.gov.uk) domains. NHS supplier frameworks expect it. PCI DSS 4.0 and similar frameworks treat it as part of transport security best practice. For private sector UK businesses, MTA-STS is strong best practice without formal mandate.
Q: Is there a simpler alternative to running my own MTA-STS hosting?
A: Yes — hosted mail platforms (SmartXHosting, Fastmail, Proton Business) typically manage MTA-STS for their customers. For DIY mail servers, lightweight MTA-STS hosting services exist (some DMARC platforms offer it). Rolling your own on existing web infrastructure is also straightforward.
Q: Does MTA-STS interact with content inspection / DLP?
A: Indirectly. Content inspection appliances that sit inline on mail delivery may need to present their own certificate to senders. That certificate must match the MX hostname in the MTA-STS policy. Plan certificate coverage at the appliance.
Q: Can I publish MTA-STS on a domain that has no MX (non-sending, non-receiving)?
A: MTA-STS is meaningful only for domains that receive mail. For non-sending/non-receiving domains, publishing MTA-STS is pointless — use DMARC p=reject and null SPF/DKIM instead to lock down the name.
Q: How quickly does an MTA-STS change propagate?
A: The DNS TXT record change propagates in minutes to hours (at standard TTLs). Cached policies at senders continue using the old policy until the old max_age expires. Short initial max_age values speed this up during active changes.
Q: What are the biggest common MTA-STS deployment mistakes in UK businesses?
A: The top three: (1) certificate does not cover the MX hostname, (2) HTTPS policy file not served or at wrong path, (3) id not updated when policy changes. All three produce silent failures visible only in TLS-RPT reports.
Q: Can I audit the policy file content from the command line?
A: Yes: curl https://mta-sts.firm.co.uk/.well-known/mta-sts.txt. Output should be the plain-text policy content with HTTP 200 and Content-Type text/plain.
Q: How does MTA-STS differ from "Require TLS" mail flow rules in Microsoft 365?
A: "Require TLS" is a rule applied at the receiving mail server — it affects inbound filtering based on whether the inbound connection used TLS. MTA-STS is published policy telling senders they must use TLS. Both achieve transport enforcement but operate at different layers.
Q: Do small UK businesses benefit meaningfully from MTA-STS?
A: Yes — proportionally more, in fact. A small business is more vulnerable to targeted TLS downgrade because it lacks the detection capability to notice unencrypted traffic. MTA-STS removes the question of whether TLS was used.
Q: Can I gradually roll out MTA-STS across a portfolio of UK domains?
A: Yes. Deploy testing mode across all domains first; monitor reports; progress each to enforce at its own pace based on the reports. Staged rollout is the standard pattern for organisations with many domains.
Q: Does MTA-STS have any privacy impact?
A: Minimal. The policy file is public; anyone can fetch it. It contains no personal data, just infrastructure hostnames. No privacy concern.
Q: Is there a way for a sender to "force" MTA-STS on a domain that has not published it?
A: No. MTA-STS is pulled by senders from the receiving domain's DNS. A sender cannot inject a policy that the receiver has not published.
Q: Will MTA-STS eventually become mandatory rather than opt-in?
A: Unclear. Trajectory suggests it will become expected best practice across UK business email, possibly mandated by some regulatory frameworks in the next few years. Deploy now to be ahead of the curve.
Q: What is the simplest UK deployment pattern for a small business?
A: Use a managed mail platform that handles MTA-STS for you (SmartXHosting, Fastmail Business, Microsoft 365 Business). For DIY deployments on shared hosting, the vendor usually supports static file serving at the required path — just upload the policy file and publish the DNS record.
Q: Can I combine MTA-STS with end-to-end encryption like S/MIME?
A: Yes, and this is the ideal layered model. MTA-STS ensures transport encryption and certificate validation between servers; S/MIME encrypts the message content end-to-end. Both operate independently.