MTA-STS for Beginners – Protecting inbound email with secure delivery rules

NuStart Email Trust Series — Post 6 of 10

MTA-STS for Beginners is a little bit of a stretch – it is a little on the technical side but I have tried to keep it as non-jargon as possible – Email deliverability is full of acronym soup—SPF, DKIM, DMARC, TLS—and most nonprofits and small businesses don’t have time to become part-time email engineers. In this series, I translate the geeky jargon into plain-English concepts and simple actions. You run the organization; I’ll do the nerding.

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) is a way to publish a policy that tells other mail servers:

1. “When emailing my domain, use TLS encryption,” and
2. “Only deliver to these approved MX servers,” and
3. “If you can’t deliver securely, don’t silently downgrade to insecure delivery” (when in enforce mode).

In simple terms: it strengthens inbound email delivery to your domain so messages are harder to intercept or downgrade in transit.

This matters for nonprofits and small businesses because email often includes donor info, invoices, grant paperwork, internal ops, and sensitive coordination.

The two things MTA-STS needs

MTA-STS requires both:

1) A DNS TXT record (the “policy exists” flag)

You publish a TXT record at:

_mta-sts.yourdomain.com

Example:

v=STSv1; id=20251219

That id= value is how you tell senders “I updated my policy—recheck it.”

2) An HTTPS policy file (the actual rules)

You host a plain text file at:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

This file lists:

• mode: (testing / enforce / none)
• allowed mx: hosts
• max_age: (how long senders cache the policy)

The modes (start safe)

mode: testing

This is the recommended starting point. It lets you roll out safely and catch mistakes without accidentally blocking mail.

mode: enforce

Strict mode. If a sender supports MTA-STS and can’t deliver using TLS to your approved MX hosts, delivery should fail (instead of falling back insecurely).

mode: none

Effectively off.

Example MTA-STS policy file

If you use Google Workspace, your policy commonly looks like:

version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com
max_age: 604800

Important: your mx: lines must match your real MX setup. If you migrate email providers later, you must update this policy (and update the DNS id=).

Why nonprofits and small businesses like MTA-STS (in practice)

MTA-STS is not flashy. It’s one of those “quiet reliability” upgrades:

• reduces risk of TLS downgrade during delivery (for senders that support it)
• locks mail delivery to your legitimate MX servers
• adds professionalism and trust signals to your domain’s posture
• pairs well with TLS-RPT (next post) so you can see failures

Hosting the MTA-STS policy with a Cloudflare Worker (simple and reliable)

A common challenge is: “Where do I host this tiny text file so it’s always up, always HTTPS, and not tied to my website platform?”

A Cloudflare Worker is a great fit because it’s:

• fast and globally available
• easy to maintain
• independent from your WordPress stack
• perfect for serving one small static file

How it works

You set up the subdomain mta-sts.yourdomain.com on Cloudflare, then route:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

to a Worker that returns your policy text with a text/plain content type.

Worker example (ready to paste)

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    // Only serve the official policy path
    if (url.pathname === "/.well-known/mta-sts.txt") {
      const policy = `version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com
max_age: 604800`;

      return new Response(policy, {
        headers: {
          "content-type": "text/plain; charset=utf-8",
          // Optional: encourage caching at the edge; senders still obey max_age for policy caching logic
          "cache-control": "public, max-age=3600",
        },
      });
    }

    // Optional: give a friendly response on the root
    if (url.pathname === "/") {
      return new Response("MTA-STS policy host", {
        headers: { "content-type": "text/plain; charset=utf-8" },
      });
    }

    return new Response("Not found", { status: 404 });
  },
};

Cloudflare setup notes (non-geek version)

• Create/ensure the DNS record for mta-sts.yourdomain.com is in Cloudflare.
• Attach the Worker to that hostname using Routes or a Custom Domain.
• Confirm the URL loads in a browser and shows the exact policy text.

/

Implementation checklist (safe rollout)

• Confirm your MX records first (what actually receives mail for your domain)
• Create the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
• Publish _mta-sts TXT record: v=STSv1; id=YYYYMMDD
• Start with mode: testing
• After validation, switch to mode: enforce and update the id=

Common mistakes (so you don’t step on a rake)

1. Policy file path wrong (must be /.well-known/mta-sts.txt)
2. No valid HTTPS on mta-sts. subdomain
3. MX mismatch between DNS and policy file
4. Switching providers and forgetting to update MTA-STS
5. Going to enforce before you’re sure everything is correct

MTA-STS FAQs

Want NuStart to handle this for you?
If you’d rather not wrestle with DNS records, alignment, and testing, NuStart can audit your current setup and implement a clean, reliable Email Trust configuration end-to-end. Request an Email Trust Audit today to get started.

Up next
Next: Post 7 — TLS-RPT: Getting alerts when encrypted delivery fails