Field note · 17 min read

How to Set Up MTA-STS for Your Custom Domains to Prevent Man-in-the-Middle Attacks

Q: How long should I stay in testing mode before enforcing?

You should remain in mode: testing for at least 7 to 14 days. This gives external senders time to deliver messages across normal business cycles and generate aggregate TLS-RPT reports. Review these reports to verify that major mail providers can negotiate TLS with your MX servers without encountering certificate errors before switching your policy to mode: enforce .

Learn how to set up MTA-STS for custom domains in the right order — policy file first, DNS record second, testing mode before enforce — so a typo never costs you a day of inbound mail.

8 October 2026 · Updated 8 October 2026 · FolioInbox

To learn how to set up mta-sts for custom domains, you need two assets: an HTTPS-hosted text file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and a DNS TXT record at _mta-sts.yourdomain.com. Once published, these records instruct sending mail transfer agents to negotiate a valid, authenticated TLS connection before delivering mail to your servers, preventing opportunistic downgrade attacks in transit.

If you run a portfolio of separate domains—such as an independent consulting brand, an operating LLC, and an e-commerce storefront—securing the inbound mail channel across every domain is a common technical hurdle. While outbound security depends on SPF, DKIM, and DMARC, MTA-STS handles the inbound side. Here is exactly how to configure, verify, and maintain the protocol across your domains without breaking incoming delivery.

What MTA-STS actually does, and what it does not

SMTP MTA Strict Transport Security (RFC 8461) is an email security standard that allows receiving domains to declare that their mail servers require Transport Layer Security (TLS) with a trusted certificate. It also dictates what a sending server must do if that secure handshake fails: refuse delivery rather than transmitting the message unencrypted.

To understand why this is necessary, you have to understand the specific problem inbound email security solves. When SMTP was designed, encryption was not part of the base specification. The later addition of transport encryption came via the STARTTLS command, which provides opportunistic TLS. Under opportunistic TLS, a sending server asks the receiving server if it supports encryption. If an attacker on the route strips the STARTTLS response (a STARTTLS stripping attack) or presents an invalid certificate, opportunistic TLS allows the sending server to fall back quietly to cleartext. As detailed in RFC 8461 Section 1, this opportunistic design leaves messages vulnerable to passive eavesdropping and active man-in-the-middle tampering without notifying either party.

MTA-STS closes this gap by allowing you to publish an authoritative policy over HTTPS. Because HTTPS relies on trusted certificate authorities, an eavesdropper on the mail route cannot downgrade the transport connection without causing the sender to abort the delivery.

Securing these transport hops ensures that sensitive client exchanges and authentication tokens are not intercepted when messages cross the public internet.

However, MTA-STS has distinct boundaries:

It does not authenticate the sender: It does not verify who sent a message, nor does it protect your outbound reputation. That remains the job of SPF, DKIM, and DMARC.
It does not stop domain spoofing: It will not prevent a bad actor from spoofing your address to third parties.
It is purely a receiver-side policy: Publishing an MTA-STS policy protects incoming mail directed to your MX host. It does nothing to protect the messages you send out to other people.

MTA-STS requires two components: a DNS TXT record at _mta-sts.yourdomain.com to advertise policy availability, and a web server hosting the actual policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.

Some administrators compare MTA-STS to DANE (DNS-based Authentication of Named Entities, RFC 6698). DANE also enforces TLS for incoming email, but it requires DNSSEC (DNS Security Extensions) to validate TLSA records. If your registrar or DNS provider does not offer stable, automated DNSSEC management, setting up DANE can be fragile. MTA-STS uses standard Web PKI certificates instead of DNSSEC, making it far more practical for independent operators to implement and maintain across multiple domains.

Before you start: the four things MTA-STS needs from your domain

Before you alter any DNS records or deploy web endpoints, ensure your domain meets four prerequisites. Missing any of these steps will cause sending servers to disregard your policy or fail delivery.

A valid TLS certificate for the mta-sts subdomain: Your web endpoint must resolve over HTTPS at mta-sts.yourdomain.com. This requires a certificate issued by a recognized root Certificate Authority (CA) such as Let's Encrypt. A wildcard certificate (*.yourdomain.com) works cleanly. A certificate issued only for the apex domain (yourdomain.com) will fail validation.
Direct static HTTPS file serving: Senders must fetch your policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The endpoint must return an HTTP 200 status code with a Content-Type: text/plain header. There can be no authentication prompts, no CAPTCHAs, and no HTTP-to-HTTPS redirects. Some sending MTAs strictly reject policies served behind redirects.
Access to your domain's DNS zone: You need permission to publish TXT records at _mta-sts.yourdomain.com and _smtp._tls.yourdomain.com. If your registrar supports Domain Connect, records can often be published directly rather than manually keyed in.
A hosting plan for the policy file: You must decide where this static file lives. If your email provider automatically serves the MTA-STS policy on your behalf, you only need to manage the DNS records. If your host does not provide this endpoint, you must host the file yourself (via Cloudflare Workers, AWS S3 with CloudFront, GitHub Pages, or a traditional web server) and maintain certificate renewals.

Before changing your transport security, make sure your core identity records are healthy. If your domain has broken SPF syntax or misaligned DKIM signatures, adding MTA-STS only secures the transport of mail that might already be landing in spam folders. Review your current setup using the free domain health audit to verify your SPF, DKIM, and DMARC baseline before adding transport enforcement.

Remember that this setup is evaluated per domain. If you own four brands across four domains, you will need four separate DNS records and four policy endpoints.

Step 1: Publish the policy file before the DNS record

The order of deployment matters when configuring how to set up mta-sts for custom domains. If you publish the DNS TXT record first, sending servers that check your domain will notice the MTA-STS record, attempt to fetch the HTTPS policy file, encounter a 404 error or certificate failure, and potentially delay or refuse delivery. often ensure the HTTPS endpoint is live and serving the correct content before publishing the DNS record.

The file must be placed at:

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

Here is an example of a baseline policy file configured for testing:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.com
max_age: 86400

Each field serves a specific purpose defined by RFC 8461:

version: STSv1: The protocol version identifier. RFC 8461 defines STSv1 as the standard version string.
mode: testing: The operational mode. In testing mode, sending servers will attempt to establish an authenticated TLS connection. If TLS negotiation fails or the certificate is invalid, the sending server will still deliver the message over cleartext, but it will send an error report via TLS-RPT (if configured). Do not start with enforce mode.
mx: [hostname]: The MX hostnames allowed to handle incoming mail for your domain. You must include an mx: entry for every single MX record published in your DNS zone. You can use explicit hostnames (such as mail.example.com) or single-level wildcards (such as *.example.com). If an inbound message arrives at an MX server not explicitly listed in your policy file, sending MTAs enforcing the policy will refuse to deliver it.
max_age: 86400: The time-to-live (TTL) of the policy in seconds. This tells the sending MTA how long to cache the policy. During your setup and testing phase, set this to 86400 (24 hours). This prevents senders from caching mistakes for weeks. Once everything is verified, this value is typically increased to 604800 (one week) or 1209600 (two weeks).

Test the URL in a standard browser or with curl from a command line:

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

Verify that the response returns HTTP/1.1 200 OK or HTTP/2 200, that the content-type header starts with text/plain, and that no 301 or 302 redirects are executed.

Step 2: Add the _mta-sts TXT record

Once the policy file is reachable over HTTPS, publish the DNS record that advertises MTA-STS support to sending MTAs.

Create a TXT record in your DNS zone with the following values:

Record Name / Host: _mta-sts (or _mta-sts.yourdomain.com, depending on whether your DNS provider automatically appends your domain name)
Record Type: TXT
TTL: 300 or 3600 (use a short TTL during initial setup)
Record Value: v=STSv1; id=20261008000000;

The record consists of two semi-colon-separated tags:

v=STSv1: The protocol version identifier.
id=20261008000000: An alphanumeric string (1 to 32 characters) representing the version of your policy. When a sending mail server checks your domain, it compares this id against the id stored in its local cache. If the id has not changed, the sender continues using its cached copy of the policy. If the id has changed, the sender immediately re-fetches the policy file from your HTTPS endpoint. Using a UTC timestamp format like YYYYMMDDHHMMSS makes it easy to track updates.

Avoid common DNS formatting errors:

Publish only one MTA-STS record. If you have two TXT records at _mta-sts, resolvers will return both, and senders will treat the policy as invalid.
Ensure the entire string is contained in a single value. It fits well within standard 255-character string limits.
Verify that your DNS manager does not add extra quotes around the value.

You can verify propagation using dig:

dig TXT _mta-sts.yourdomain.com +short

The output should return exactly: "v=STSv1; id=20261008000000;".

Step 3: Read the TLS reporting before you switch to enforce

Publishing an MTA-STS policy without monitoring incoming connection reports creates unnecessary risk. If your email host rotates certificates and introduces a name mismatch, or if an MX host renewal fails, you will not receive alerts—your incoming mail will simply stop arriving from enforcing senders. To avoid this, set up SMTP TLS Reporting (TLS-RPT, RFC 8460).

TLS-RPT instructs sending servers to generate automated aggregate reports detailing their ability to negotiate secure connections with your MX servers.

To enable TLS-RPT, publish another TXT record in your DNS zone:

Record Name / Host: _smtp._tls (or _smtp._tls.yourdomain.com)
Record Type: TXT
Record Value: v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com;

Reports arrive as gzipped JSON files (.json.gz) sent to the address specified in the rua= tag. A typical report includes:

The reporting organization.
The date range covered by the report.
The receiving policy evaluated (MTA-STS or DANE).
Total successful connection sessions.
Total failure sessions, categorized by failure type: certificate expired, hostname mismatch, negotiation failure, or validation timeout.

Leave your MTA-STS policy in mode: testing for at least 7 to 14 days. During this window, review incoming reports. If a remote sender encounters a certificate error when connecting to your MX hosts, testing mode ensures your mail is still delivered over opportunistic TLS while the failure is documented in the report.

If you see a recurring certificate-host-mismatch error, your mail host's certificate does not cover the hostnames listed in your DNS MX records. You must resolve that certificate configuration before enforcing your policy.

Once you have observed clean reports with zero critical failures across normal traffic volumes, update the policy file to enforcement mode:

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 604800

After editing the file on your server, increment the id tag in your DNS TXT record (for example, to id=20261015000000). Senders will see the new ID, re-fetch the updated file, and begin strictly requiring TLS for all inbound delivery.

MTA-STS for small business: what it costs you in time and attention

Deploying mta-sts for small business is rarely a question of direct software expense; it is a question of operational overhead. The actual technical deployment takes about an hour per domain, but ongoing maintenance requires discipline.

The primary operational liability is TLS certificate expiration for the mta-sts subdomain. If you host the .well-known/mta-sts.txt file on an independent server or cloud bucket, you are responsible for renewing that web certificate. If that web certificate expires, sending servers in enforce mode will fail to validate the policy endpoint and will refuse to deliver incoming email to your business. An expired web certificate on your policy host can drop your email just as effectively as a broken MX record.

Consider the arithmetic for an operator managing several distinct brands or entities:

1 Domain: 1 HTTPS endpoint, 1 TLS certificate to monitor, 1 TXT record, 1 TLS-RPT mailbox. Manageable manually.
6 Domains: 6 HTTPS endpoints, 6 TLS certificates, 6 TXT records, 6 TLS-RPT streams.

Multiply this maintenance routine across multiple business entities, and manual server configurations quickly become an operational headache. Email transport security should be automated wherever possible to minimize maintenance burdens.

If your email provider automatically serves your MTA-STS policy file and provisions its SSL certificate, your operational footprint drops to managing standard DNS TXT records. If your provider does not handle this, serverless functions (like edge workers on Cloudflare or AWS CloudFront functions) that terminate SSL automatically via managed certificates are far safer than running a self-managed VPS just to host a static text file.

often prioritize your protocol layers pragmatically. Solid SPF, per-domain DKIM signatures, and a DMARC policy with a quarantine or reject disposition provide essential protection against spoofing. Ensure your domain maintains proper anti-spoofing safeguards before spending operational energy debugging MTA-STS web servers.

Common mistakes, and how each one fails

MTA-STS relies on the intersection of DNS, web infrastructure, and mail transfer protocols. A mistake in any of these three layers will prevent the protocol from working properly.

1. Publishing the DNS TXT record before the HTTPS endpoint is live

If you create the _mta-sts TXT record before your web server correctly serves the policy over HTTPS, validating MTAs will detect the record, attempt to fetch the policy, receive an HTTP error or SSL failure, and fail to validate the destination. often verify the HTTPS URL in your browser before adding the DNS record.

2. Omitting secondary or backup MX hostnames

Your policy file must include an mx: line for every MX record in your DNS zone. For example, if your DNS points to:

example.com.   IN MX 10 mx1.mailhost.com.
example.com.   IN MX 20 mx2.mailhost.com.

And your policy file only lists:

mx: mx1.mailhost.com

Any incoming mail routed to mx2.mailhost.com will be rejected by an enforcing sender because the secondary MX host is not authorized by your MTA-STS policy.

3. Serving the policy behind an HTTP-to-HTTPS redirect

Some administrators configure their web server to listen on HTTP port 80 and issue a 301 Moved Permanently redirect to HTTPS port 443. RFC 8461 requires sending MTAs to fetch the policy directly over HTTPS. While some sending systems follow redirects, others will fail the fetch immediately. Ensure your server responds directly to HTTPS requests on port 443 with an HTTP 200 status.

4. Forgetting to bump the id tag when updating policies

If you change your policy from mode: testing to mode: enforce, or add a new MX server, you must change the id value in your _mta-sts TXT record. If you fail to update the id, remote sending MTAs will rely on their cached copy of the old policy until the max_age expires, ignoring your updates.

5. Enforcing before testing

Switching immediately to mode: enforce without checking TLS-RPT reports is risky. Under RFC 8461 Section 4.2, an enforcing sender that encounters a certificate validation failure must abort the delivery attempt rather than falling back to unencrypted cleartext. Because the session aborts at the transport stage before handing data to your MX host, the incoming message will not reach your destination mailbox or spam folder.

6. Setting a large max_age value on day one

Setting max_age: 2592000 (30 days) during your initial deployment locks senders into caching your early configuration. If you make a syntax error or misconfigure your MX entries, senders that fetched that policy will cache that broken configuration for an entire month. Keep max_age at 86400 (1 day) until you are ready to enforce.

7. Assuming MTA-STS protects your outbound email

MTA-STS does nothing to secure messages sent from your domain to external recipients. It protects inbound messages sent from other servers to your domain. To safeguard outbound identity and protect clients from fraud, follow standard FTC phishing guidance by securing outbound mail with aligned SPF, DKIM, and DMARC records.

Where MTA-STS fits when you run several domains alone

When you operate as a solo founder managing several business entities—such as a services firm, a side project, and an e-commerce store—email infrastructure overhead compounds quickly. If you run five domains, every protocol you implement must be maintained five times over.

Traditional hosted platforms like Google Workspace or Microsoft 365 charge on a per-user, per-month basis. If you add secondary domains to an existing seat to save money, configuring distinct DKIM keys and managing independent transport policies can become complicated. Alternatively, stitching together budget hosts can leave you managing web servers, certificate renewals, and DNS records by hand across multiple dashboards.

The right technical sequence for multi-domain operators is clear:

Per-domain DKIM signing: Ensure every domain signs its outbound mail with its own 2048-bit DKIM key.
DMARC policy alignment: Publish a DMARC policy (moving from p=none to p=quarantine or p=reject) so recipients can authenticate your sender identity.
MTA-STS enforcement: Implement inbound transport protection once your core authentication records are working cleanly.

If you prefer an integrated approach, FolioInbox is designed specifically for this workflow. Folio is a single-operator inbox, not a team or shared mailbox — there are no per-user seats and no team collaboration features. Under the FolioInbox pricing schedule, billing is flat per plan rather than per user: Solo is $2.99/mo billed annually ($35.88/yr) or $3.50 monthly for up to 3 domains; Studio is $12/mo billed annually ($144/yr) or $15 monthly for up to 10 domains; and Holding Co. is $29/mo billed annually ($348/yr) or $39 monthly for unlimited domains. Monthly send caps are 1,000, 6,000, and 30,000 messages respectively.

Folio encrypts mail in transit (TLS) and at rest, but is not end-to-end or zero-knowledge encrypted: mail is stored server-side and readable by Folio for spam filtering and search. Inbound transport security, handled via MTA-STS, ensures that remote servers negotiate verified TLS before handing messages over to that infrastructure.

If you already have your domains configured through providers like Migadu, Purelymail, or Fastmail and your delivery paths are stable, that setup works well. The primary reason operators migrate is to avoid per-seat cost models and messy alias routing while keeping per-domain DKIM and setup simple across their entire portfolio.

How to verify your MTA-STS setup actually works

Once you have deployed your HTTPS policy file and published your DNS TXT records, verify the configuration across all layers:

Verify DNS TXT resolution: Query your _mta-sts record using a public DNS resolver:
```
dig TXT _mta-sts.yourdomain.com @1.1.1.1 +short
```
Ensure it returns a single string starting with v=STSv1 and containing your active id.

Test the HTTPS policy endpoint directly: Confirm your web endpoint is reachable, serves the right content type, and does not redirect:
```
curl -ILs https://mta-sts.yourdomain.com/.well-known/mta-sts.txt | head -n 10
```
Look for an HTTP/2 200 or HTTP/1.1 200 OK response code with content-type: text/plain.

Audit MX host alignment: Double-check that every MX record returned by dig MX yourdomain.com +short matches an mx: entry in your policy file. A missing entry will trigger delivery failures once you switch to enforcement mode.
Verify TLS reporting records: Confirm that your reporting record resolves:
```
dig TXT _smtp._tls.yourdomain.com @8.8.8.8 +short
```
Verify that it returns v=TLSRPTv1 with an active reporting email address.

Send external test messages: Send test messages from major providers (such as Gmail or Outlook) to your domain while in mode: testing. Check the email headers of the received messages to ensure TLS was negotiated successfully during transport.

Frequently Asked Questions

Does MTA-STS replace DMARC or DKIM?

No. MTA-STS does not replace SPF, DKIM, or DMARC. DKIM and SPF verify that an outbound email was legitimately sent by your domain, and DMARC specifies how receivers should handle unauthenticated messages. MTA-STS protects inbound messages by ensuring that external senders connect over an authenticated TLS session rather than unencrypted cleartext. You need both inbound transport security and outbound identity authentication to secure your email.

What happens if I set MTA-STS to enforce mode and get it wrong?

If your policy is set to mode: enforce and your mail host has an invalid, expired, or mismatched TLS certificate, sending MTAs that support MTA-STS will refuse to deliver the message. Because delivery fails before the message reaches your mail server, the email will not appear in your inbox or spam folder. The sending party will receive an undeliverable bounce notice. This is why you should often run your domain in mode: testing for at least a week before enforcing.

Do I need DNSSEC to use MTA-STS?

No. MTA-STS was intentionally designed to operate without DNSSEC. It uses standard Web PKI (HTTPS certificates verified by public Certificate Authorities) to establish the validity of your policy. This makes MTA-STS simpler to deploy across most domain registrars than DANE, which requires working DNSSEC validation.

Can I use MTA-STS on a domain that only receives mail?

Yes. MTA-STS is designed specifically for receiving domains. If a domain has an MX record pointing to an active mail server, deploying an MTA-STS policy ensures that incoming messages arrive over an authenticated, encrypted transport layer.

How long should I stay in testing mode before enforcing?

You should remain in mode: testing for at least 7 to 14 days. This gives external senders time to deliver messages across normal business cycles and generate aggregate TLS-RPT reports. Review these reports to verify that major mail providers can negotiate TLS with your MX servers without encountering certificate errors before switching your policy to mode: enforce.

The short version

Securing inbound mail for your custom domains comes down to a clear technical sequence:

Publish your policy file over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with mode: testing and every MX hostname listed.
Add the DNS TXT record at _mta-sts.yourdomain.com with an id tag corresponding to your deployment timestamp.
Add a TLS-RPT record at _smtp._tls.yourdomain.com to receive aggregate delivery reports.
Monitor your reports for at least a week, and only switch the policy to mode: enforce once you confirm zero certificate mismatch errors.
Configure per-domain DKIM signing and DMARC policies before spending time on inbound transport security.

Before editing your DNS records, run a free audit using our domain health audit. It inspects your SPF, DKIM, DMARC, and MTA-STS records per domain with no email gate on the results, helping you spot configuration issues immediately.

If you want a simpler way to manage email across multiple brands, FolioInbox provides a single-screen setup with automated Domain Connect record publishing and independent DKIM keys for every domain. Folio has no free plan. A free preview of 100 sends on one domain, no card required. Paid plans (Solo, Studio, Holding Co.) start with a 14-day trial, card required. Review the pricing plans to choose the right