Skip to content
iBlockSpam
Get started
Check your domain Get started Log in
How it works
Platforms
Microsoft 365 Google Workspace cPanel / WHM Exchange Server
Solutions
Small business MSPs Hosting providers Law firms Accounting firms Healthcare practices Real estate & title
Free tools Pricing
Blog
All guides
By topic
Email security basics Phishing & threats SPF, DKIM & DMARC Setup guides Running email day to day Switching & migration Choosing a filter
Reference
Glossary Research: top 1,000 sites
Free tool

MTA-STS & TLS-RPT Record Generator

Enter your domain and MX hosts to get the three things MTA-STS needs: the _mta-sts DNS record, the policy file to host over HTTPS, and a TLS-RPT record so you get reports.

One per line: every host in your MX records, or a wildcard such as *.example.net. Find them with the MX Lookup.

Email addresses or https:// URLs, up to 5, separated by commas. Leave empty to skip the TLS-RPT record.

Up to 32 letters and digits. Empty: we use the current date and time.

No DNS lookups; nothing is published for you.

What the generator builds

MTA-STS (RFC 8461) lets your domain tell sending mail servers to use encrypted, authenticated connections when they deliver to you, instead of falling back to plain text when an attacker interferes. It needs three pieces, and this generator writes all of them:

  1. The _mta-sts TXT record, such as v=STSv1; id=20261023120000. It tells senders a policy exists and which version it is.
  2. The policy file, served at https://mta-sts.<your domain>/.well-known/mta-sts.txt. It lists the mode, your MX hosts and how long senders may cache it.
  3. The _smtp._tls TXT record for TLS reporting (RFC 8460), such as v=TLSRPTv1; rua=mailto:tls-reports@yourcompany.com. Senders that support it email or post you a daily report of connections that succeeded and failed.

The generator makes no DNS lookups and publishes nothing; you copy the results to your DNS host and web server. When they're live, the MTA-STS Checker fetches your policy and compares it with your real MX records.

The policy file, line by line

Line Allowed values Our default Notes
version STSv1 STSv1 The only version defined
mode testing, enforce, none testing Testing asks for reports but doesn't block delivery
mx A host name or a *. wildcard, one per line What you enter Required at least once unless the mode is none
max_age 0 to 31557600 seconds 604800 (1 week) RFC 8461 expects "weeks or greater"

The generator writes one mx: line per host, as RFC 8461 requires, converts international names to their punycode form, and skips MX preference numbers if you paste lines like 10 mail.example.com. Google's MTA-STS policy help recommends a max_age between 604800 and 1209600 seconds (one to two weeks) for testing mode.

Which mx values? Every host in your MX records must match one of the lines, or senders in enforce mode won't deliver to it. If your MX points directly to Exchange Online, Microsoft says you can use mx: *.mail.protection.outlook.com, the same value Microsoft uses itself (Microsoft Learn: MTA-STS). If a filtering service receives your mail first, list that service's MX hosts. Our MTA-STS and TLS-RPT guide covers the gateway case.

How to publish it

  1. Check your MX hosts support TLS with valid certificates for their names. That's what enforce mode requires; testing mode tells you if they don't.
  2. Create the policy host. Add an A, AAAA or CNAME record for mta-sts.<your domain> pointing at a web server you control, and get an HTTPS certificate for that name.
  3. Upload the policy file so that https://mta-sts.<your domain>/.well-known/mta-sts.txt returns it with HTTP 200 and the text/plain content type. RFC 8461 says senders must not follow redirects, so the URL has to answer directly.
  4. Publish the TLS-RPT record at _smtp._tls.<your domain>, so reports start arriving.
  5. Publish the _mta-sts TXT record last. Senders only look for the policy once this record exists.
  6. Read the reports for a few weeks. Our TLS-RPT Report Analyzer opens them in your browser.
  7. Switch to enforce: change mode to enforce in the file, then change the id in the TXT record.

Whenever you change the policy file, change the id too. Microsoft's documentation makes the same point: without a new id, senders keep the cached policy until its max_age runs out.

Turning MTA-STS off

RFC 8461 describes a clean opt-out: publish a policy with mode: none and a small max_age (it suggests one day), change the id, and remove the TXT record and the policy file only after all previously served policies have expired. Choose none in the generator to build that policy.

TLS-RPT addresses

The rua in the TLS-RPT record takes a mailto: address or an https:// URL, or several separated by commas. Reports arrive as JSON, usually compressed, roughly once a day from each sending organization that supports TLS-RPT. RFC 8460 says reports sent by email must be DKIM-signed by the reporting domain. Use a mailbox that can take automated mail: a shared or dedicated address works better than a person's inbox.

Limitations

  • It doesn't look up your MX records. Enter them yourself, or copy them from the MX Lookup.
  • It can't check that your MX hosts offer valid TLS, or host the policy file for you.
  • MTA-STS protects mail sent to your domain by senders that support it. It doesn't change how your own outgoing mail is sent.

Sources

Frequently asked questions

What max_age should an MTA-STS policy use?

Start with one to two weeks (604800 to 1209600 seconds) in testing mode, which is what Google recommends. RFC 8461 allows up to 31557600 seconds and expects values of weeks or more, because longer caching leaves fewer chances to tamper with a policy refresh. Raise it once enforce mode is stable.

Where do I host the MTA-STS policy file?

At https://mta-sts.yourdomain/.well-known/mta-sts.txt, on any web server that can serve a plain text file over HTTPS with a valid certificate for the mta-sts host name. Senders don't follow redirects, so the file must answer directly with HTTP 200 and the text/plain content type.

When do I change the MTA-STS policy id?

Every time you change the policy file, for example when you add an MX host or switch from testing to enforce. Senders compare the id in the _mta-sts TXT record with the one they cached; if it hasn't changed, they keep using the old policy until its max_age runs out.

Can I use a wildcard in the MTA-STS mx line?

Yes. RFC 8461 allows a pattern such as *.example.net, and Google says the wildcard replaces only the leftmost label. Microsoft's own example for domains whose MX points directly to Exchange Online is mx: *.mail.protection.outlook.com.

How do I turn MTA-STS off safely?

Publish a policy with mode: none and a short max_age, such as one day, and change the id so senders fetch it. Remove the TXT record and the policy file only after every previously cached policy has expired, which can take as long as the old max_age.

Related guides

SPF, DKIM & DMARC

MTA-STS and TLS-RPT explained: how to set them up safely

What MTA-STS and TLS-RPT protect against, the DNS records and policy file you need, testing vs enforce mode, and safe rollout behind a filtering gateway.

9 min read Email security basics

Is my email encrypted in transit? STARTTLS, MTA-STS and DANE explained

What STARTTLS does for email, why opportunistic TLS can be downgraded, how MTA-STS and DANE enforce it, what Gmail's lock icons mean, and where TLS stops.

9 min read Running email day to day

Email security checklist for small businesses in 2026

A practical 2026 email security checklist for small businesses: MFA, SPF, DKIM and DMARC, filtering, backups, staff training and an incident plan.

9 min read