Patchkit

Free tool

MTA-STS Policy Generator

Write the MTA-STS policy file and the DNS records that announce it. Pick a mode, list your MX hosts and get the file, the _mta-sts record and an optional TLS-RPT record, all built in your browser.

Mode
MX patterns

One line per mail server that receives your mail: a host name such as mail.example.com, or *. followed by a host name to cover exactly one more label.

Pressing this button sends the domain to Patchkit's server, which looks up its MX records. Generating the policy sends nothing: everything else you enter stays in your browser.

TLS reporting

An email address, or an https:// address if a reporting service gave you one.

The policy file and the records are built in your browser. Generating them sends nothing to Patchkit and stores nothing.

By Ahmet Karaca · Updated · Checked against RFC 8461 (MTA-STS), RFC 8460 (SMTP TLS Reporting), RFC 5321 (SMTP) and RFC 7505 (null MX) on

What MTA-STS does

Mail servers usually encrypt with STARTTLS only when it works, so an attacker on the path can strip the upgrade or pose as your mail server (RFC 8461 §1). MTA-STS lets you publish a policy that tells senders your MX hosts support TLS with a valid certificate and which host names they use. Senders that apply the policy in enforce mode won't deliver over a connection that fails those checks (§5).

A policy needs three pieces, and the generator writes all of them: the policy file, the _mta-sts TXT record that announces it, and optionally the _smtp._tls TXT record for TLS-RPT reports (RFC 8460). For the background, read MTA-STS and TLS-RPT explained.

What the generator produces

The policy file holds one key and value per line: version: STSv1 first, then the mode, one mx: line for each pattern and the max_age in seconds, the same order as the example in RFC 8461 §3.2. The section calls the lines CRLF-separated, and its grammar accepts LF too, so the file uses CRLF line endings, with one after the last line. International host names must be written in their xn-- form.

The file is served at https://mta-sts.yourdomain/.well-known/mta-sts.txt. Senders fetch it over HTTPS and require a certificate valid for the mta-sts host, a 200 status and no redirect (§3.3), and they should check that it is served as text/plain (§3.2). The _mta-sts record then carries v=STSv1 and the id of this version of the policy (§3.1).

Fill from my MX records looks up your MX hosts so you don't miss one. A domain with a null MX (RFC 7505) accepts no mail, so it has nothing for MTA-STS to protect. A domain with no MX records at all receives mail at its own A or AAAA address, the implicit MX of RFC 5321 §5.1, so the domain itself becomes the pattern.

Roll out in testing, then enforce

  1. Publish the TLS-RPT record, so reports start arriving.
  2. Host the policy file in testing mode with an mx: line for every MX host.
  3. Publish the _mta-sts record. RFC 8461 §8.1 says to update the file before the TXT record, so a sender that sees the new id never caches the old file.
  4. Read the TLS reports for a while. In testing mode, senders that implement TLS-RPT report policy failures, and messages may still be delivered (§5).
  5. When the failures are fixed or explained, generate the file again in enforce mode and publish it with its new id.

The MTA-STS checker confirms each step from the outside: it fetches the file, parses it the way senders do and compares the mx: lines with your MX records.

If an MX host is missing from the policy

Under enforce, a sender that applies the policy checks that at least one mx: pattern matches the MX host it selected (RFC 8461 §4), and it must not deliver to a host that fails that match (§5). A forgotten backup MX is easy to miss: senders try MX hosts in their usual order, so a problem that only affects a lower-priority host may surface only when the primary fails (§8.4). Before you add or rename an MX host, add its pattern to the policy and publish a new id. Senders keep a cached policy until it expires or they see a new id, for up to 365.25 days with the largest max_age.

Withdrawing a policy

Deleting the record and file isn't enough, because senders keep applying a cached policy until it expires. RFC 8461 §8.3 describes a clean exit instead: publish a new policy with mode: none and a small max_age (its example is one day, 86400 seconds), publish a new TXT record so senders fetch it, and remove the record and the file only after every previously served policy has expired. Choose mode none above to generate that file; it needs no mx: line.

Related tools and guides

Frequently asked questions

+Is my domain sent to Patchkit?

Not when you generate. The policy file and both TXT records are built in your browser, and generating sends nothing to our servers and stores nothing. The domain reaches Patchkit only if you press Fill from my MX records: that button sends it to our server, which looks up the domain's MX records and returns them. Opening the MTA-STS checker afterwards also sends the domain, because the checker reads your live records.

+Should I start in testing or enforce mode?

Start in testing. In that mode, senders that also implement TLS-RPT send reports of policy failures, as long as your domain publishes a TLS-RPT record, and messages may still be delivered as if nothing failed (RFC 8461 §5). Read the reports, fix what they show, then switch the file to enforce and publish a new id. Under enforce, senders must not deliver to a host that fails the MX match, doesn't offer STARTTLS or fails the certificate check.

+Why does the id change every time I generate?

RFC 8461 §3.1 says the id must uniquely identify one instance of the policy, so senders can tell when it changed by comparing it with the id they cached. The RFC allows 1 to 32 letters and digits and implies no ordering. We use the current UTC date and time as 14 digits, like the timestamp in the RFC's own example, so each run gets a new id. Publish the file and the record from the same run.

+What max_age should I choose?

RFC 8461 §3.2 caps max_age at 31557600 seconds (365.25 days) and expects it to "typically be in the range of weeks or greater", to mitigate attacks when senders refresh the policy. Its example policy uses 604800 seconds, one week, which is our default. The MTA-STS checker warns below 7 days, except in mode none, where §8.3 suggests a small value such as one day.

+Do I need the TLS-RPT record?

MTA-STS works without it, but in testing mode RFC 8461 §5 has senders report failures only if the recipient domain also implements TLS-RPT, so without the _smtp._tls record you won't hear about failures. RFC 8460 §3 lets rua= point to a mailto: or an https: address. Reports arrive as JSON, so send them to a mailbox or service that can read that format.

+Can I use a wildcard mx pattern?

Yes. A pattern such as *.example.com matches exactly one extra label: mail.example.com, but not example.com or foo.bar.example.com (RFC 8461 §4.1). Each MX host still needs a certificate valid for its own name (§4.2). If your MX names change often, a wildcard saves you from editing the policy, but list the bare domain separately if it receives mail itself.

We use Google Analytics cookies only if you accept. Privacy policy