Hosted MTA-STS: switch it on and enforce

Hosted MTA-STS lets DMARCER create and serve your MTA-STS policy and look after its TLS certificate, so sending mail servers always use an encrypted connection to your domain. You just publish a couple of DNS records, then move from testing into full enforcement when you are ready.

Published 29 Jun 2026 3

MTA-STS tells sending mail servers that they must use a valid, encrypted (TLS) connection when they deliver mail to your domain. With hosted MTA-STS, DMARCER creates the policy, serves the policy file, and looks after the TLS certificate for you. All you do is publish a couple of DNS records, then choose when to move the policy from reporting only into full enforcement.

What hosted MTA-STS does

When DMARCER hosts the policy, it serves the file from its regional infrastructure at https://mta-sts./.well-known/mta-sts.txt and keeps the TLS certificate for that address renewed for you automatically. The policy lists your live MX hostnames so receiving servers know which destinations are genuine. You never run a web server or manage a certificate yourself: you only publish the DNS records that DMARCER shows you.

  • DMARCER serves the policy file and renews the TLS certificate, so there is no certificate upkeep for you.
  • You can move the policy from testing to enforce (and back again) from the Policy tab.
  • The mx: lines are built from a live MX lookup, and you can rebuild them at any time with Refresh MX from DNS.
  • If your MX points to Microsoft 365, the policy automatically uses Microsoft's recommended wildcard entry (mx: *.mail.protection.outlook.com) rather than your specific tenant host.

Choosing hosting or self-host

Open the domain on the Domain Management page and open its MTA-STS panel. If MTA-STS is not set up yet, you will see the heading 'Choose how to publish MTA-STS for ' with two options.

  • Let DMARCER host it: DMARCER serves the policy and manages the certificate, and you publish two DNS records. Click 'Use DMARCER hosting' to carry on. If no hosting region is currently available, this button is replaced by 'No active hosting region'.
  • Self-host the policy: you serve the policy file from your own web server and manage the TLS certificate for mta-sts. yourself. Click 'Show self-host steps' to see the policy file and DNS record to publish.

Activating DMARCER hosting

  1. Click 'Use DMARCER hosting'. A 'Confirm DMARCER hosting' panel appears. If more than one hosting region is available, pick the region from the dropdown; if only one is available, it is simply shown as a fixed badge.
  2. Click 'Activate hosting' and confirm. DMARCER creates the first policy in TESTING mode using your live MX records and starts serving it from the region you chose.
  3. Publish the two DNS records shown on the DNS Records tab (see below). Until they are live, receivers cannot find the policy.
  4. Leave the policy in testing while you review your TLS-RPT reports, then promote it to enforce from the Policy tab once you are confident.

If no live MX records are found when you activate, the policy is created with a placeholder mx: line. Add your MX records at your DNS provider, then use Refresh MX from DNS to rebuild the policy with the real hostnames. Please note that MTA-STS is not available for Parked domains: a parked domain has no MX, so you would need to convert it to a Standard domain first.

Publishing your DNS records

The DNS Records tab lists each record with a status of Live, Mismatch, or Not published, so you can see exactly what receivers can find at the moment.

  • CNAME record: the host mta-sts. pointing at the region's host name. This is what makes the hosted policy file reachable.
  • TXT record: the host _mta-sts. with a value like v=STSv1; id=. This is the signal receivers use to spot a new version of your policy.
  • TLS-RPT TXT record: the host _smtp._tls.. This opts you in to nightly delivery reports from senders so you can spot any TLS problems. If the region has no reporting mailbox set up, this row shows 'Region intake not configured', and a Platform admin will need to set it up.

If the domain is linked to a DNS integration in Domain Management, a 'Publish DNS records' button appears that writes only the records that are not yet live. If the domain is not linked to an integration, copy each value using the clipboard buttons and add the records at your DNS provider yourself.

Testing and enforce: what each mode means

The Policy tab shows the current mode as a pill (Testing or Enforce) along with the policy body being served. The mode controls what receiving servers do when a TLS connection to your MX cannot be validated.

  • Testing: receivers report TLS failures through TLS-RPT but never block any mail. This is the safe starting point, and it lets you find problems without affecting delivery.
  • Enforce: receivers that honour the policy will refuse to deliver mail when TLS validation fails. This is the protection you are aiming for, but it can block legitimate inbound mail if your policy is wrong.

To move into enforcement, click 'Promote to enforce' on the Policy tab and confirm. We recommend reviewing two to four weeks of clean TLS-RPT reports first, because promoting too early can block legitimate mail. The Activity tab shows policy fetches over the last seven days: if no receivers are fetching the policy, it is too soon to promote. If an enforce policy ever causes trouble, use 'Revert to testing' as an emergency rollback. If your MX records change, use 'Refresh MX from DNS' so the published mx: lines match, because in enforce mode an out-of-date mx: list can quietly block legitimate inbound mail.

Certificate, activity and TLS-RPT tabs

  • Certificate: shows the hosted TLS certificate, including when it was issued and when it expires. A re-issue option is available, but it is limited to three re-issues per domain in any seven days, and a re-issue causes a brief gap (around 30 seconds) while the new certificate is installed.
  • Activity: a seven-day chart of how many times receivers fetched the policy, which helps you judge whether you are ready to promote.
  • TLS-RPT: a summary of delivery successes and failures over the last 7, 30 or 90 days, with examples of any failures. Use this to confirm there are no TLS problems before you promote to enforce.

Common pitfalls

  • Records not live yet: until the CNAME and the _mta-sts TXT record both show Live, receivers cannot use the policy. Check the hosted-setup checklist on the Overview tab.
  • MX mismatch under enforce: if your live MX records do not match the mx: lines in the policy, sending servers will refuse to deliver to the hosts that are not listed. Run Refresh MX from DNS after any MX change.
  • Promoting too early: move to enforce only after you have reviewed your TLS-RPT reports and confirmed that receivers are fetching the policy.
  • Permissions: changing the hosting state, promoting, refreshing MX or re-issuing the certificate needs a role with domain management rights. Read-only users cannot do these things.
  • Parked domains: MTA-STS cannot be enabled on a Parked domain. Convert it to Standard first.

Was this article useful?

Be the first to vote.
Got feedback for our team? Send us a comment