How to set up MTA-STS for Microsoft 365

Publish an MTA-STS policy for each receiving domain, starting in testing mode.

Every Microsoft 365 security check · Threat Protection · NL-EML-004

What this check looks at

Checks mail-receiving custom domains publish an MTA-STS policy, so senders must use encrypted, authenticated connections.

Mail servers encrypt SMTP opportunistically: if one side does not offer TLS, or someone on the network path strips the STARTTLS offer, the message goes in clear, and a sending server cannot tell a genuine certificate from a forged one. MTA-STS (RFC 8461) lets a domain declare that its mail servers support TLS with valid certificates, so senders that honour it, including Microsoft 365 and Gmail, refuse to deliver over an unencrypted or unverified connection. It needs a TXT record at _mta-sts.<domain> and a policy file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt.

The check looks at each custom domain that receives mail and only ever warns, as this is a defence-in-depth control. It passes a domain whose policy file is fetched and in enforce mode. It warns when there is no MTA-STS record, when the record exists but the policy file was not fetched or is not valid, when the policy is in testing mode, and when its mode is none, which switches MTA-STS off.

Without MTA-STS, an attacker able to intercept traffic between a sending server and the organisation’s (through a compromised network provider or manipulated DNS) can downgrade the connection and read or alter mail in transit. It is rare against small organisations, but the mail concerned, such as contracts, payroll files and legal correspondence, is exactly what such an attacker wants.

Why it matters

Without MTA-STS, mail to the organisation can be silently downgraded to an unencrypted connection by anyone positioned on the network path. It is a defence-in-depth control, not a first priority.

For most small and medium organisations MTA-STS is not the first priority, which is why this check only warns. It matters more for firms that receive sensitive personal or financial data by email: solicitors, accountants, recruitment agencies, healthcare providers. A downgraded connection exposes that data without anyone noticing, and UK GDPR expects personal data to be protected with appropriate technical measures, in transit as well as at rest.

Once set up it costs very little: a small text file and two DNS records. TLS reporting (TLS-RPT), published alongside, also tells the organisation when senders fail to connect securely, which can reveal a certificate or configuration problem before customers notice delays.

NIST CSF 2.0 PR.DS-02 (data in transit protected), CIS Controls v8 3.10 (encrypt sensitive data in transit), ISO 27001 A.5.14 (information transfer) and A.8.24 (use of cryptography) and NCSC CAF B3.b (data in transit) all apply. The NCSC’s email security guidance recommends MTA-STS and TLS-RPT for receiving domains.

How to fix it

Where: Your DNS provider and a web host for the policy file

Before you start

  • You need a web host for https://mta-sts.yourdomain/.well-known/mta-sts.txt and a TXT record at _mta-sts.yourdomain.
  • Start in testing mode, with TLS reporting (TLS-RPT) set up.

Step by step

  1. Decide where the policy file will live. The file must be served at https://mta-sts.<domain>/.well-known/mta-sts.txt with a publicly trusted certificate for mta-sts.<domain>, as plain text and without redirects. Any small web host will do: an Azure Static Web App, the client’s website host, or a worker at the DNS provider. Create the mta-sts host name (CNAME or A record) pointing at it and confirm the certificate is issued.
  2. Write the policy in testing mode. Create the file with these lines: version: STSv1, then mode: testing, then one mx: line per MX host, then max_age: 86400. For the usual Microsoft 365 MX (contoso-com.mail.protection.outlook.com) the line is mx: *.mail.protection.outlook.com; if the domain uses the newer MX ending in mx.microsoft, list the MX host name exactly as published. Upload it and open the URL in a browser to check it loads.
  3. Publish the MTA-STS TXT record. At the DNS host add a TXT record with the host name _mta-sts and the value v=STSv1; id=20261004 (any string of letters and numbers up to 32 characters). Change the id every time you change the policy file, because senders cache the policy until they see a new id.
  4. Turn on TLS reporting. Add a TXT record with the host name _smtp._tls and the value v=TLSRPTv1; rua=mailto:tls-reports@<domain> (or your reporting service’s address). Senders then send daily reports of successful and failed TLS connections to the domain.
  5. Read the reports, then enforce. After two weeks or so, check the TLS reports show no failures from genuine senders. Edit the policy file to mode: enforce and max_age: 604800 (one week), then change the id in the _mta-sts record so senders pick up the new policy.
  6. Confirm the policy is valid. Run an MTA-STS checker against the domain, or fetch the file with Invoke-WebRequest https://mta-sts.contoso.com/.well-known/mta-sts.txt and check the record with Resolve-DnsName -Name _mta-sts.contoso.com -Type TXT. The policy should be found, in enforce mode, with mx lines matching the domain’s MX records. The next assessment passes the domain.

What users will notice

None. Mail sent to you insists on an encrypted connection.

How to confirm it worked

Use an MTA-STS checker: the policy is found, valid, and lists Microsoft 365’s MX host.

Frameworks and controls

This check maps to controls in 12 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.

The frameworks and controls NL-EML-004 maps to
FrameworkControl
NCSC CAFB3.b Data in transit
DSPTStandard 9: IT protection
NIS2Art. 21(2)(h) Cryptography and encryption
Microsoft Cloud Security BenchmarkDP-3 Encrypt sensitive data in transit
Zero TrustNetworks
SOC 2CC6.7 Restricting the transmission, movement and removal of information
NIST SP 800-1713.13.8 Use cryptography to protect CUI in transit
CMMC Level 2SC.L2-3.13.8 Data in Transit
ISO 27001:2022A.5.14 Information transferA.8.24 Use of cryptography
CIS Controls v8.13.10 Encrypt sensitive data in transit (IG2)
NIST CSF 2.0PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected
NCSC 10 StepsData security

The framework mappings were last checked against the published standards in October 2026.

Microsoft’s documentation

The full Microsoft 365 security checklist, worst first

Check this in every tenant.

ConfigCheckup runs this check on every tenant you connect and offers an approved fix once you have made the choice it needs. You see a dry run of exactly what will change, approve it, and can roll it back.

14 days of daily monitoring and alerts, every finding with its fix guide, and reports on up to 3 tenants, from your first connected tenant. No card. Then choose the plan that fits.Where this check fits: Microsoft 365 security assessment for MSPs