MTA-STS: Protecting Your Domain from TLS Downgrade Attacks

Email was never designed with security in mind. When two mail servers talk to each other over SMTP, they negotiate encryption on the fly using a mechanism called STARTTLS — and that negotiation happens in plain text. That opens the door to TLS downgrade attacks, where an attacker sitting between two servers strips the encryption and reads (or modifies) your messages in transit.

MTA-STS (Mail Transfer Agent Strict Transport Security) is the fix. It tells sending servers, "always use TLS when you email my domain, and here's how to verify you're talking to the right server." In this guide, we'll explain how MTA-STS works, why it matters for New Zealand businesses, and how to deploy it step by step.

What is a TLS downgrade attack?

When your mail server connects to another server to deliver mail, the conversation typically starts in plain text. The servers then use the STARTTLS command to upgrade the connection to encrypted TLS.

The problem? An attacker with network access — a compromised router, a rogue ISP, or a state-level adversary — can simply strip the STARTTLS response from the handshake. The sending server, seeing no TLS offered, falls back to sending the email in plain text. Your confidential invoices, client data, and internal communications become readable.

This isn't theoretical. Research by Google and others has shown downgrade attacks occurring regularly in the wild, particularly against countries and regions with less mature mail infrastructure.

How MTA-STS solves the problem

MTA-STS publishes a policy at a well-known HTTPS URL on your domain. This policy tells sending mail servers:

  • Which hostnames are valid MX servers for your domain
  • That TLS is required (not optional)
  • What to do if TLS fails (enforce or just report)

Because the policy is fetched over HTTPS (with a valid certificate) and cached, an attacker on the SMTP path can't strip or forge it. If TLS is unavailable or the certificate doesn't match, the sender refuses to deliver the mail rather than falling back to plain text.

MTA-STS is supported by all major providers — Gmail, Microsoft 365, Fastmail — which means the majority of email sent to your domain will respect it.

The three pieces of MTA-STS

To deploy MTA-STS you need three things:

  1. A DNS TXT record that signals MTA-STS is enabled and provides a policy ID
  2. A policy file hosted over HTTPS at a specific subdomain
  3. Valid TLS certificates on your MX servers matching the hostnames in the policy

Optionally (and recommended), you should also publish a TLS-RPT record so you get reports when delivery fails due to TLS issues.

Step-by-step: deploying MTA-STS

Let's walk through setting this up for a fictional New Zealand business, kiwibiz.co.nz.

Step 1: Publish the MTA-STS DNS record

Create a TXT record at _mta-sts.kiwibiz.co.nz:

_mta-sts.kiwibiz.co.nz.  IN  TXT  "v=STSv1; id=20240115T120000;"

The id value is a policy identifier. It must change every time you update your policy file — using a timestamp is a common convention.

Step 2: Host the policy file

Your policy must be served from https://mta-sts.kiwibiz.co.nz/.well-known/mta-sts.txt with a valid TLS certificate.

A typical policy looks like this:

version: STSv1
mode: enforce
mx: mail.kiwibiz.co.nz
mx: *.outlook.com
max_age: 604800

Breaking this down:

  • mode: enforce blocks delivery if TLS fails. Start with testing to monitor without breaking mail flow.
  • mx: list every MX hostname that can legitimately receive mail for your domain. Wildcards are allowed.
  • max_age: how long receivers should cache your policy (in seconds). 604800 is one week — the recommended minimum for production.

You can host this file on any web server, a CDN, AWS S3 with CloudFront, Cloudflare Workers, or a dedicated MTA-STS service.

Step 3: Verify your MX certificates

Your MX servers must present TLS certificates that:

  • Are issued by a trusted public CA
  • Match the hostnames listed in your policy
  • Are not expired

If you use Microsoft 365, Google Workspace, or most NZ-based providers (like SMX or MailGuard), this is already handled. If you run your own mail server — say on a VPS here in Auckland — make sure Let's Encrypt or another CA has issued a valid certificate.

Step 4: Add a TLS-RPT record

TLS-RPT tells receivers where to send failure reports. Add this TXT record:

_smtp._tls.kiwibiz.co.nz.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@kiwibiz.co.nz"

You'll start receiving JSON reports from major providers summarising TLS success and failure rates for mail sent to your domain. These are gold for catching misconfigurations.

Step 5: Start in testing mode

For your first week or two, set mode: testing in your policy. Providers will report failures via TLS-RPT but still deliver mail normally. Once you're confident everything is in order, switch to mode: enforce.

Common pitfalls to avoid

  • Forgetting to update the id: if you change your policy file but not the DNS id, receivers will keep using the cached old policy.
  • Certificate mismatches: if your MX is mail.kiwibiz.co.nz but your cert is for kiwibiz.co.nz only, MTA-STS will fail.
  • Short max_age values: a low max-age weakens the protection. Use at least 604800 (one week) in production.
  • Missing MX entries: if you add a backup MX or switch providers, update your policy and bump the id before the change goes live.

Why this matters for NZ businesses

New Zealand organisations — particularly those handling financial data, health records, or dealing with Australian and overseas partners — face the same TLS downgrade risks as anyone else. The Privacy Act 2020 expects reasonable safeguards around personal information in transit, and plaintext email delivery is increasingly hard to defend as "reasonable" when MTA-STS is available and free.

Combined with SPF, DKIM, and DMARC, MTA-STS rounds out a modern email security posture: DMARC protects the From address from spoofing; MTA-STS protects the content from interception.

Check your configuration with xteam MailCheck

Not sure if your MTA-STS policy is valid? Worried your certificates or DNS records might have drifted out of sync?

Run your domain through xteam's free MailCheck tool to instantly audit your MTA-STS, SPF, DKIM, DMARC, BIMI, and TLS-RPT configuration — with clear, actionable recommendations tailored for New Zealand businesses. It's the fastest way to confirm your domain is properly protected against TLS downgrade attacks and other email threats.