Email

MTA-STS & TLS-RPT Generator

Policy & Records

Build your MTA-STS policy

Choose how strictly senders must verify TLS, which mail servers they may deliver to, and where TLS reports go.
DomainrequiredWhat's this?
The domain receiving mail. MTA-STS tells senders to require encrypted, certificate-verified delivery to it.
Needs two things live: a TXT record at _mta-sts.yourdomain.com and a policy file served over HTTPS. “Look up existing” reads the policy already published.
Step 1 of 3

Finish the wizard to build your policy

Work through the three steps above, then press Generate on the last step to produce your policy file and DNS records.

Tool features

Everything you need to deploy MTA-STS and TLS reporting
4 features

Guided three-step wizard

Domain, policy, then caching and reporting — no MTA-STS syntax to memorize

Prefill from live DNS

Reads the policy already published on the domain, and fetches its real MX hosts

TLS-RPT record included

Generates the _smtp._tls record so receivers report TLS failures daily

Share & export

Download the policy file, a zone file, JSON, or a branded PDF report

What is MTA-STS & how it works

Forcing verified TLS on the mail arriving at your domain

MTA-STS (RFC 8461) lets a domain declare that inbound mail must arrive over TLS, to a server presenting a certificate that matches one of the MX names you list. It closes the downgrade attack that plain opportunistic STARTTLS leaves open, where an attacker on the path simply strips the encryption offer.

A policy has two halves that must agree: a policy file served over HTTPS from mta-sts.yourdomain, and a TXT record at _mta-sts.yourdomain carrying an id that changes whenever the file changes. This generator builds both, plus the separate _smtp._tls TLS-RPT record that gets you daily reports of TLS failures.

Every field in the wizard — the policy mode, the allowed MX hosts, max_age and the TLS-RPT address — is explained one by one in MTA-STS Generator: Every Input Explained — the same copy behind every “What's this?” link above.

mode
testing reports failures but still delivers; enforce refuses delivery; none retires the policy.
mx
The hostnames a sender may deliver to. Every MX record on the domain must match one of them.
max_age
How long senders cache the policy. Longer is safer once the policy is stable.

How to use this tool

Build and publish an MTA-STS policy in four steps
1
Enter your domain
The domain that receives mail, for example example.com. Look up an existing policy to edit it instead.
2
Choose a mode and MX hosts
Start in testing mode and list every mail server senders are allowed to deliver to.
3
Set caching and reporting
Pick a max_age and add a TLS-RPT address so receivers report TLS failures to you.
4
Publish both halves
Serve the policy file over HTTPS from mta-sts.yourdomain and add the _mta-sts TXT record in DNS.

Related tools

Keep debugging with tools from the same suite
4 tools
MTA-STS & TLS-RPT Checker
Check a domain MTA-STS policy and TLS-RPT record, validating DNS records and the live HTTPS policy file
DMARC Generator
Generate DMARC policy records for email authentication with policy configuration options
DKIM Generator
Generate DKIM keys and records for email message signing and authentication
Email Health Checker
Comprehensive email deliverability check including SPF, DKIM, DMARC, and MX records

Frequently asked questions

Common questions about MTA-STS and TLS-RPT
6 Q&A

Start with testing. Senders still deliver mail if the TLS check fails, but they report the failure through TLS-RPT — so you find broken paths without losing mail. Move to enforce after one to two clean weeks.

The policy itself is not in DNS. It is a small text file served over HTTPS at https://mta-sts.yourdomain/.well-known/mta-sts.txt, and the certificate on that subdomain must be valid. The DNS record only announces that a policy exists and gives its current id.

It tells senders whether their cached copy of the policy is stale. If you edit the policy file without publishing a new id, senders keep using the old policy until max_age expires. Always change both together.

Yes. In enforce mode a sender refuses to deliver to any host whose certificate does not match one of your mx: patterns. A single wildcard label is allowed, so *.acme-corp.com covers mx1.acme-corp.com.

No, but without it testing mode tells you nothing. TLS-RPT is a separate TXT record at _smtp._tls.yourdomain that asks receivers to send you a daily JSON summary of TLS successes and failures.

Both force verified TLS on inbound mail. DANE pins the certificate in DNS and requires a DNSSEC-signed zone; MTA-STS uses HTTPS and the public CA system instead, so it works without DNSSEC. Many domains publish both.