Log inTry the sandbox free

Email authentication

MTA-STS record and policy generator

Write both halves of MTA-STS at once: the _mta-sts TXT record and the policy file.

Free, no accountIn your browser

Used to name where each half goes: the TXT record at "_mta-sts." and the file at "mta-sts." plus this domain.

One host per line, exactly as your MX records name them. "*." may replace the left-most label only.

How long a sender may cache the policy from its last fetch. RFC 8461 expects "the range of weeks or greater"; 31557600 is the maximum it allows.

1 to 32 letters and digits. Left empty, the id below is derived from the policy itself, so it changes whenever the file does.

Try

Result

mode: testing, 0 mail hosts, id sts1uay8vo

Fix the problems below before publishing either half.

  • Failed

    The policy lists no mail hosts

    RFC 8461 §3.2 requires at least one "mx" line in every mode except "none", and §5 says a sender applying the policy must not deliver to a host that matches none of them - so an empty list refuses every host.

    Add one mail host per line above, copied from the MX records the domain publishes.

  • Warning

    The policy file has to be served over valid HTTPS at mta-sts.yourdomain.com

    Publishing the TXT record on its own does nothing. A sender fetches https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and only accepts it when the response is 200 - redirects must not be followed - over HTTPS on a certificate that is valid for mta-sts.yourdomain.com, non-expired and chained to a trusted root (RFC 8461 §3.2, §3.3). Senders should also see "Content-Type: text/plain".

    Serve the file below at exactly https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, on that host and that path, before publishing the TXT record. A certificate for yourdomain.com alone is not valid for mta-sts.yourdomain.com.

    version: STSv1 mode: testing max_age: 604800
  • Info

    Testing: failures are reported, and mail still arrives

    A sender that also implements TLS reporting sends a report when applying the policy fails, and delivers the message as though there had been no failure (RFC 8461 §5). It is the mode to publish first, and the reason to publish a TLS-RPT record at the same time.

TXT record to publish

v=STSv1; id=sts1uay8vo;

At _mta-sts.yourdomain.com (TXT)

Publish this at "_mta-sts.yourdomain.com", not at the domain itself. Change the id whenever the policy file changes, or senders keep applying the copy they cached.

Policy file to serve at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

version: STSv1

mode: testing

max_age: 604800

  • This writes the two halves; it does not host the policy file. Nothing is published or served from here, and the file has to be put on your own HTTPS host at that exact name and path before the TXT record means anything.
  • RFC 8461 sets a maximum max_age of 31557600 seconds and no minimum, so no figure here is checked against a lower bound - the warning about a short lifetime quotes the RFC's own expectation rather than a rule.
  • Whether a given sender honours MTA-STS at all is not something this page claims: no provider documentation was read for it, so treat enforce as a request every sender may ignore rather than a guarantee.

What this is

This MTA-STS generator writes both halves of an MTA-STS deployment from the same few answers - the TXT record that goes in DNS and the policy file that has to be served over HTTPS - because publishing one without the other is the most common way MTA-STS ends up doing nothing at all.

MTA-STS asks a sending server to require TLS for your mail and to deliver only to hosts you have named in advance. Half of it is a TXT record at "_mta-sts" carrying a version and a policy id; the other half is a plain text file, listing the hosts and the mode, fetched over HTTPS from a fixed path on a host whose name is "mta-sts." plus your domain.

The id in the record is not a timestamp with any meaning attached: it identifies one revision of the file, in 1 to 32 letters and digits. A sender compares the id in DNS with the one it has cached to decide whether to fetch the file again, which is why the id has to change every time the file does - and why the one below is derived from the file's own contents unless you give it one.

How to read the result

The record is for DNS and the policy file is for your web server, and the order matters: serve the file first, then publish the record. A record pointing at a file that is not there yet leaves senders treating the domain as having no policy, which is harmless but pointless.

Start in testing mode. A sender then reports a policy failure instead of refusing the message, so a host you forgot to list shows up in a report rather than in a bounce. Switch the mode to enforce, change the id, and the same file starts being enforced.

Common mistakes

What goes wrong most often, and how to tell.

  • Publishing the TXT record before the file is reachableA sender that finds the record and cannot fetch the policy continues as though MTA-STS had never been implemented, so the domain gets no protection and no error - the deployment silently does nothing until someone checks the URL by hand.
  • Serving the file on a certificate that is not valid for the policy hostThe certificate has to cover "mta-sts." plus the domain, not the domain alone. A wildcard for the apex often does not cover it either, depending on how it was issued, and a sender rejects the policy rather than warning anyone about it.
  • Using a wildcard where the pattern does not reachAn "mx" wildcard replaces exactly one left-most label, so "*.example.net" covers mail.example.net and nothing deeper or shallower. A host two labels down needs a pattern of its own.
  • Reusing the same id after editing the fileSenders cache the policy against the id, not the file. Edit the file without touching the id and the correction reaches nobody who already has a copy until the lifetime you set runs out.

How it works

  1. 1. List every host that receives your mailCopy them from your own MX records, including any filtering gateway in front of the mailboxes - a gateway that accepts the connection is the host a sender matches against the policy.
  2. 2. Serve the policy file over HTTPSPut it at the exact path on the exact host shown, answering 200 as text/plain, on a certificate issued for that "mta-sts." name. A redirect to your main site does not count and will fail.
  3. 3. Publish the TXT record, in testing modeWith the file already in place, add the record. Nothing is enforced yet; senders that implement TLS reporting start telling you when the policy would have failed.
  4. 4. Change the mode to enforce, and the id with itOnce the reports show nothing failing, change the mode in the file and the id in the record together. Changing the file alone leaves senders applying the cached testing policy until its max_age expires.

Questions

What people ask about this tool.

  • At "/.well-known/mta-sts.txt" on the host made by prepending "mta-sts." to your domain, over HTTPS, answering 200 with a certificate valid for that host name. The path and the host prefix are both fixed by RFC 8461 §3.2, so neither can be moved to suit an existing site.

  • Testing, in almost every case. A sender applying a testing policy reports the failure and delivers the message anyway, so an unlisted host or a broken certificate costs you a report rather than the mail itself. Enforce is the second step, taken once the reports are quiet.

  • RFC 8461 allows anything up to 31557600 seconds and sets no minimum, saying only that the value is expected to be in the range of weeks or greater. A week is a reasonable starting point; a short lifetime is worth choosing deliberately while rolling out or withdrawing, because it means senders refetch sooner.

  • No. It writes the exact text of both halves and tells you where each one goes; serving the file on an HTTPS host with a valid certificate is the part you do, and the limits on every result say so.

Sources

Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.

Use it from the API

The same check, as one request.

Request
curl -X POST https://resellerhq.com/api/tools/mta-sts-generator \
  -H "Content-Type: application/json" \
  -d '{"domain":"example.com","mode":"testing","mx":"mx1.example.com\nmx2.example.com","maxAge":604800,"id":""}'
Response
{
  "tool": "mta-sts-generator",
  "input": {
    "domain": "example.com",
    "mode": "testing",
    "mx": "mx1.example.com\nmx2.example.com",
    "maxAge": 604800,
    "id": ""
  },
  "result": {
    "verdict": {
      "tone": "warning",
      "headline": "mode: testing, 2 mail hosts, id sts16bdm5h",
      "summary": "Serve the policy file first, then publish the TXT record."
    },
    "findings": [
      {
        "id": "policy-file-must-be-hosted",
        "severity": "warn",
        "title": "The policy file has to be served over valid HTTPS at mta-sts.example.com",
        "detail": "Publishing the TXT record on its own does nothing. A sender fetches https://mta-sts.example.com/.well-known/mta-sts.txt and only accepts it when the response is 200 - redirects must not be followed - over HTTPS on a certificate that is valid for mta-sts.example.com, non-expired and chained to a trusted root (RFC 8461 §3.2, §3.3). Senders should also see \"Content-Type: text/plain\".",
        "fix": "Serve the file below at exactly https://mta-sts.example.com/.well-known/mta-sts.txt, on that host and that path, before publishing the TXT record. A certificate for example.com alone is not valid for mta-sts.example.com.",
        "copy": "version: STSv1\r\nmode: testing\r\nmx: mx1.example.com\r\nmx: mx2.example.com\r\nmax_age: 604800\r\n",
        "copyLabel": "Copy mta-sts.txt"
      },
      {
        "id": "mode-testing",
        "severity": "info",
        "title": "Testing: failures are reported, and mail still arrives",
        "detail": "A sender that also implements TLS reporting sends a report when applying the policy fails, and delivers the message as though there had been no failure (RFC 8461 §5). It is the mode to publish first, and the reason to publish a TLS-RPT record at the same time."
      }
    ],
    "parts": [
      {
        "kind": "record",
        "title": "TXT record to publish",
        "value": "v=STSv1; id=sts16bdm5h;",
        "note": "Publish this at \"_mta-sts.example.com\", not at the domain itself. Change the id whenever the policy file changes, or senders keep applying the copy they cached.",
        "at": {
          "name": "_mta-sts.example.com",
          "type": "TXT"
        }
      },
      {
        "kind": "text",
        "title": "Policy file to serve at https://mta-sts.example.com/.well-known/mta-sts.txt",
        "body": "version: STSv1\n\nmode: testing\n\nmx: mx1.example.com\n\nmx: mx2.example.com\n\nmax_age: 604800"
      }
    ],
    "limits": [
      "This writes the two halves; it does not host the policy file. Nothing is published or served from here, and the file has to be put on your own HTTPS host at that exact name and path before the TXT record means anything.",
      "RFC 8461 sets a maximum max_age of 31557600 seconds and no minimum, so no figure here is checked against a lower bound - the warning about a short lifetime quotes the RFC's own expectation rather than a rule.",
      "Whether a given sender honours MTA-STS at all is not something this page claims: no provider documentation was read for it, so treat enforce as a request every sender may ignore rather than a guarantee."
    ]
  }
}

This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.

Resell mailbox licences for the domains you just checked, under your own brand.

Get started

Company names and logos are trademarks of their owners, shown only to identify each service.