Skip to main content
CaptainDNS

Free MTA-STS Generator

Create MTA-STS DNS record & policy file for any domain

MTA-STS forces inbound email to travel over encrypted TLS and closes the door on downgrade attacks. This generator builds both pieces you need, the DNS record and the hosted policy, then walks you through deploying them safely, from testing to enforce.

1Your domain and your receiving servers

The domain for which to generate MTA-STS configuration.

An exact host (mail.example.com) or a wildcard *.example.com. 20 patterns maximum.

2Protection level

Start in testing, move to enforce once validated.

How long receiving servers should cache your policy.

Advanced

Must change every time the policy is modified.

Free MTA-STS Hosting

Don't want to self-host your MTA-STS policy? We host it for free.

Try MTA-STS Hosting

Key features

Simple configuration

Enter your domain, select a mode, and add your MX servers. We handle the formatting and syntax for RFC 8461 compliance.

Flexible modes

Start with testing to monitor without enforcement, then switch to enforce for production. Disable with none if needed.

Wildcard MX support

Use exact hostnames or wildcards (*.mail.captaindns.com) to cover multiple MX servers with a single pattern.

Copy-ready output

One-click copy for both DNS record and policy file. Ready to paste into your DNS provider and web server.

Step-by-step guide

Clear deployment instructions included. Know exactly where to add the DNS record and host the policy file.

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) is an email security standard defined in RFC 8461. It lets a domain owner declare that their mail servers support TLS encryption, and require sending servers to refuse delivery rather than send a message in plain text.

The problem it solves is an old one. SMTP negotiates TLS opportunistically: if the STARTTLS command fails, the message is sent anyway, unencrypted. An attacker sitting on the network path abuses that tolerance, stripping STARTTLS to force a clear-text send they can intercept, the so-called downgrade attack. MTA-STS removes that fallback. Without a valid TLS connection to your MX servers, the email simply isn't delivered.

Beyond protecting against interception and man-in-the-middle attacks, publishing MTA-STS signals that your domain follows transit-encryption best practices. Google and Microsoft 365 both honor it on the sending side, and pair it with TLS-RPT to surface connection failures.

MTA-STS Components

An MTA-STS setup rests on two components published separately: a DNS record that advertises the policy, and the policy itself, hosted over HTTPS. The two must stay consistent for a sending server to apply your rules.

1. DNS record

A TXT record published at _mta-sts.yourdomain.com advertises that your domain supports MTA-STS:

_mta-sts.captaindns.com.  IN  TXT  "v=STSv1; id=20240115120000"
  • v=STSv1: protocol version (always STSv1)
  • id: version identifier of the current policy; change it on every policy update

2. Hosted policy file

The policy is a text file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.captaindns.com
mx: *.backup-mail.captaindns.com
max_age: 604800

The mx directive can appear several times to list all your receiving servers. The mode field accepts enforce, testing or none.

Deployment checklist

Deploy MTA-STS in this order: the policy and its HTTPS certificate first, the DNS record only afterwards. As long as the policy isn't reachable, the record has no effect: sending servers have nothing to apply.

Step 1: Set up the policy host

  1. Create a subdomain: mta-sts.yourdomain.com
  2. Obtain an HTTPS certificate (Let's Encrypt works)
  3. Configure your web server to serve the policy file

Step 2: Create and host the policy file

  1. Use the generator above to create your policy
  2. Save it as mta-sts.txt
  3. Host it at /.well-known/mta-sts.txt

Step 3: Add the DNS record

  1. Generate the DNS record with the tool above
  2. Add it to your DNS as a TXT record at _mta-sts

Step 4: Test and monitor

  1. Validate your setup with the MTA-STS Record Checker
  2. Stay in testing mode while you identify any issues
  3. Switch to enforce mode once the setup is confirmed

FAQ - Frequently asked questions

Q: What is MTA-STS and why do I need it?

A: MTA-STS (Mail Transfer Agent Strict Transport Security) is a standard defined in RFC 8461 that lets a domain owner declare that its mail servers require TLS. Without it, SMTP falls back to plain text as soon as the TLS negotiation fails, which an attacker can trigger on purpose to intercept your mail. MTA-STS removes that fallback and protects your inbound email against interception and man-in-the-middle attacks.

Q: What's the difference between testing and enforce modes?

A: In testing mode, sending servers report failures via TLS-RPT but still deliver the mail if TLS fails: nothing is blocked, you simply observe. In enforce mode, they must establish a valid TLS connection or refuse delivery. Always start in testing to confirm that every one of your MX servers answers over TLS, then switch to enforce.

Q: How do I deploy the MTA-STS policy file?

A: Host the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The mta-sts subdomain must present a valid HTTPS certificate, serve the file with the Content-Type: text/plain header, and stay reachable without redirects. If a single one of these conditions is missing, the policy is ignored.

Q: What max_age value should I use?

A: The max_age directive sets how long, in seconds, senders keep your policy in cache. Common values range from 86400 (1 day) during the testing phase to 604800 (1 week) in production, up to 31557600 (1 year) for a stable setup. Avoid going below 86400: some providers such as Gmail ignore a policy whose cache window is too short.

Q: Can I use wildcards in MX patterns?

A: Yes. MTA-STS accepts an asterisk (*) as the leftmost label of an MX pattern. For example, *.mail.captaindns.com covers any subdomain of mail.captaindns.com, so you don't have to list each server one by one.

Q: Do I need a TLS-RPT record too?

A: It isn't mandatory, but it's strongly recommended. A TLS-RPT record (RFC 8460) asks sending servers to send you a daily report of TLS connection failures. It's your only visibility into what MTA-STS blocks or lets through: without it, a certificate problem goes unnoticed.

Q: How do I configure MTA-STS for Microsoft 365 / Office 365?

A: Enter your domain in the generator, choose the mode (start with testing) and add the MX pattern *.mail.protection.outlook.com, which covers the Exchange Online servers. Copy the DNS TXT record, then host the policy file on the mta-sts subdomain of your domain.

Q: How do I configure MTA-STS for Google Workspace?

A: Enter your domain, then add the MX patterns your domain actually publishes: smtp.google.com for a recent Workspace domain (single MX at priority 1 since 2023), or the legacy set aspmx.l.google.com for the primary MX, *.aspmx.l.google.com for the four alternate MX hosts and *.googlemail.com for the backup ones. The generator produces the DNS TXT record and the policy file, ready to deploy.

Ready to lock down your transit encryption? Generate your configuration above, deploy the policy, then validate the whole thing with the MTA-STS Record Checker.

Complementary tools

ToolDescription
MTA-STS Record CheckerValidate your published MTA-STS configuration
MTA-STS Syntax CheckerCheck MTA-STS syntax offline
DMARC GeneratorCreate your domain's DMARC record
MTA-STS HostingHost your MTA-STS policy for free

Useful resources