Hosted MTA-STS

21 June 2026 · 23 min read

What MTA-STS does and why it matters

SMTP was designed in an era when nobody worried about someone quietly downgrading a mail connection to plaintext. By default, when one mail server sends to another, TLS is opportunistic: the sending server offers to encrypt, but if the connection is interfered with - or the receiving server's certificate looks wrong - most mail transfer agents (MTAs) will happily fall back to sending the message unencrypted rather than bounce it. That's great for deliverability and terrible for confidentiality, because it means an on-path attacker can force a downgrade and read (or tamper with) your mail in transit.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) closes that gap. It lets you publish a signed policy that tells the sending world two things about your domain's inbound mail servers:

1. Which hostnames are allowed to receive mail for you (your MX hosts).
2. Whether connections to those hosts must use TLS with a valid certificate - and, if verification fails, whether the sending server should refuse to deliver rather than fall back to plaintext.

Senders that support MTA-STS (Gmail, Outlook.com/Microsoft 365, Fastmail, and a growing list of others) fetch your policy over HTTPS, cache it, and enforce it for the length of time you specify. Alongside MTA-STS sits TLS-RPT (SMTP TLS Reporting, RFC 8460), which asks those same senders to email you daily reports of any TLS negotiation failures they saw when trying to reach you - so you can see problems (and attacks) before you flip the switch to full enforcement.

Together, MTA-STS + TLS-RPT do for inbound mail transport what DMARC does for sender authentication: MTA-STS locks down how mail reaches you, while DMARC governs who is allowed to send as you. They're complementary, not competing, controls, and most organisations that run one should run the other.

Note MTA-STS only protects inbound mail - messages arriving at your domain's mailboxes. It has no bearing on the SPF, DKIM or DMARC checks that protect messages you send outbound. If you haven't already set those up, see the Hosted DMARC, Hosted SPF and Hosted DKIM guides.

The three moving parts

MTA-STS on the wire is made of three separate DNS records plus one HTTPS-served file:

With DMARC Engine's hosted model you don't hand-author any of this. You delegate all three pieces to us with CNAMEs, we run the HTTPS policy host on our SSL-for-SaaS certificate infrastructure, we keep the policy content in sync with your MX records, and we collect and parse the TLS-RPT reports for you. The rest of this guide walks through exactly how.

Hosted vs manual: which model are you using?

DMARC Engine supports two ways to run MTA-STS, and it's worth being clear about the difference up front.

• Hosted (recommended): you publish three CNAME records that point at DMARC Engine. We serve the policy file over HTTPS on our own SSL-for-SaaS certificate, we keep the policy in step with the MX hosts you've told us about, and we receive and parse your TLS-RPT reports automatically. Rotating MX providers, adding a second mail platform, or moving from testing to enforce mode is a settings change in the app - no DNS edits, no certificate renewals to babysit.
• Manual (self-managed): you publish the TXT records and the policy file content yourself, and you run your own HTTPS host (or static file bucket) for mta-sts.<domain>, plus you set up your own inbox or parser to receive TLS-RPT reports.

This guide leads with the hosted path because that's what almost every DMARC Engine customer should use - it removes the two hardest parts of MTA-STS (running a reliable HTTPS endpoint with a valid cert, and parsing TLS-RPT JSON) entirely. The manual alternative is documented at each step for completeness, and for organisations with policy requirements against CNAME delegation.

Tip Not sure whether you're already on hosted or manual for this domain? Open Domains, select the domain, and check the MTA-STS panel - it shows the CNAME targets we expect and live DNS lookup results for what's actually published.

Before you start: gather your MX hosts

MTA-STS policy is fundamentally a list of hostnames permitted to be your mail exchangers. Before you touch any DNS, you need to know your current MX records, because the policy must match them or mail could be rejected by strict senders.

Step 1: Find your current MX records

1. Open the free DNS Lookup tool and run an MX lookup against your domain, or from a terminal run:

   dig MX yourdomain.com +short
   

1. Note every hostname returned. A typical Microsoft 365 tenant looks like:

   10 yourdomain-com.mail.protection.outlook.com.
   

1. A typical Google Workspace tenant looks like:

   1  aspmx.l.google.com.
   5  alt1.aspmx.l.google.com.
   5  alt2.aspmx.l.google.com.
   10 alt3.aspmx.l.google.com.
   10 alt4.aspmx.l.google.com.
   

1. Write these down - you'll enter the base domain patterns (e.g. mail.protection.outlook.com or *.google.com, per the MTA-STS mx matching rules) into the DMARC Engine MTA-STS builder.

Warning If your MX hosts change (you migrate mailbox providers, add a secondary MX, or a partner starts routing mail through a new relay) and your MTA-STS policy isn't updated to match, senders that enforce MTA-STS will refuse to deliver mail to the new host. This is the single most common way organisations break their own inbound mail with MTA-STS. On the hosted plan, update your MX list in the app first - we regenerate the policy automatically. On manual, you must edit and republish the policy file yourself before changing MX records.

Step 2: Decide your starting policy mode

MTA-STS has three modes, and you should almost always start at the least strict:

Every domain should launch in testing. There is no reason to start in enforce - you get all the reporting visibility in testing with none of the delivery risk.

Setting up hosted MTA-STS

This is the recommended path. You'll add your domain, list your MX hosts, publish three CNAMEs, and let DMARC Engine run the policy host and TLS-RPT collection.

Step 1: Add (or open) your domain

1. Go to Domains.
2. If the domain isn't listed yet, click Add domain and enter it. This also generates your per-domain hosting slug, which every hosted CNAME target below uses.
3. Click into the domain, then open the MTA-STS tab, or go directly to app.dmarcengine.com/mta-sts and select the domain from the picker.

Step 2: Enter your MX hosts in the builder

1. In the MTA-STS builder, add each MX hostname (or wildcard pattern) you gathered in the "Before you start" section above.
2. Save. DMARC Engine uses this list to generate the mx lines of the policy document it will serve - you never hand-write the policy file yourself.
3. Set the starting mode to testing.

Note You can add or remove MX hosts at any time from this screen. Whenever you save a change here, we regenerate the served policy file and bump its version ID automatically - there's nothing further for you to publish.

Step 3: Publish the three CNAME records

The builder screen shows the exact CNAME targets for your domain's slug. They follow this pattern (replace <slug> with the value shown in the app and <domain> with your actual domain):

1. The policy-hosting CNAME - points your policy hostname at our HTTPS server:

mta-sts.yourdomain.com.    CNAME    mta-sts.dmarcengine.com.

2. The policy-ID TXT, delegated via CNAME - announces the current policy version so senders know when to re-fetch:

_mta-sts.yourdomain.com.    CNAME    <slug>._mta-sts.dmarcengine.com.

3. The TLS-RPT CNAME - tells senders where to email TLS failure reports:

_smtp._tls.yourdomain.com.    CNAME    <slug>._smtp._tls.dmarcengine.com.

1. Log in to your DNS provider (registrar or DNS host - Cloudflare, GoDaddy, Route 53, etc.).
2. Create each of the three CNAME records exactly as shown above, substituting your own domain and the slug from the app.
3. Save the changes in your DNS provider's control panel.
4. DNS propagation is typically fast (minutes) but can take up to 24-48 hours depending on your provider's TTL settings and caching resolvers along the path.

Tip Some DNS control panels won't let you create a CNAME at a name that already has other record types, or require you to omit the trailing dot, or automatically append your zone's apex to whatever you type. If a record won't save, check your provider's own CNAME documentation - the concept is identical everywhere but the data-entry conventions differ slightly.

Step 4: Wait for certificate activation

Because mta-sts.yourdomain.com must be served over valid HTTPS (this is a hard requirement of the MTA-STS spec - an insecure or self-signed cert on the policy host makes the whole record moot), DMARC Engine has to provision a TLS certificate for your specific hostname behind the scenes before the policy is actually fetchable by senders.

1. After you save the CNAME, the MTA-STS panel in the app shows a status of Activating… while we validate domain control and issue the certificate.
2. This normally completes within a few minutes of the CNAME resolving correctly.
3. Once it flips to Active, your policy is live and being served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.

Warning If Activating… persists for more than about 15-20 minutes, the most common cause is that the mta-sts.<domain> CNAME hasn't propagated yet, or was entered slightly wrong (extra character, wrong target, pointed at the wrong record type). Re-check the record with the DNS Lookup tool before contacting support. See the Common problems and fixes section below for the full troubleshooting path.

Step 5: Confirm status in the app

1. Return to app.dmarcengine.com/mta-sts.
2. Confirm all three records show as verified/resolving correctly, and the policy status is Active.
3. Confirm the mode shown matches what you intended (testing to start).

At this point you're live in testing mode: compliant senders are fetching your policy, checking TLS against your listed MX hosts, and - critically - not rejecting mail even if something doesn't match. You're purely gathering visibility for now.

Setting up TLS-RPT reporting

TLS-RPT is included automatically as part of the hosted MTA-STS setup above (it's the third CNAME), but it's worth understanding what it gives you and where to see the results, since it's the entire reason testing mode is worth running before enforce.

What TLS-RPT reports contain

Participating senders (Google, Microsoft, and others) send a daily JSON report describing, in aggregate, every attempt they made to deliver mail to your domain over the previous 24 hours: how many connections succeeded, how many failed, and - for failures - a categorised reason (certificate expired, certificate name mismatch, STARTTLS not offered, DNSSEC validation failure on the MX record, and so on).

Step 1: Confirm the TLS-RPT CNAME is in place

You already published this in Step 3 above:

_smtp._tls.yourdomain.com.    CNAME    <slug>._smtp._tls.dmarcengine.com.

Nothing further to do here - DMARC Engine receives these reports on our infrastructure and parses them for you automatically. There's no mailbox to create, no inbound routing to configure, and no JSON to unzip.

Step 2: Review incoming reports in the app

1. Go to Reports and filter to TLS-RPT for the domain in question.
2. Or check Analytics for a trend view of TLS negotiation success/failure over time, broken down by reporting sender.
3. Look specifically for:
4. - Sending MTAs / reporters you don't recognise - could indicate reports arriving late from a provider you didn't expect, which is normal and not a problem on its own.
5. - Failure counts greater than zero against your own MX hosts - this is the signal you're watching for during testing.
6. - Failure reason codes - a certificate-expired result is very different from a starttls-not-supported result, and each points to a different fix.

Step 3: Set an alert (optional but recommended)

1. Go to Alerts and add an alert rule for TLS-RPT failures on this domain.
2. This means you'll be notified proactively rather than needing to remember to check the dashboard during your testing window.

Tip TLS-RPT reports are aggregated daily and typically come from only a handful of large mailbox providers (Google and Microsoft account for the overwhelming majority of report volume for most domains). Don't be alarmed if you don't see a report from every sender you exchange mail with - TLS-RPT adoption on the sending side is still growing, so absence of a report from a smaller provider just means they don't support TLS-RPT yet, not that anything is wrong.

The safe testing-to-enforce path

This is the part of MTA-STS that actually matters for risk management: how do you get from "policy exists" to "policy is actively rejecting bad connections" without breaking your own inbound mail flow.

Step 1: Run in testing mode for at least one full reporting cycle

1. Leave the mode set to testing in the MTA-STS builder.
2. Wait a minimum of 5-7 days. Because TLS-RPT reports are daily aggregates and different senders report on slightly different schedules, one week gives you a representative sample across your regular mail volume, including any weekly-cadence senders (payroll systems, weekly digests, etc.) that might only connect occasionally.

Step 2: Review every failure in that window

1. Open Reports (or Analytics) and list every TLS-RPT failure recorded during the testing window.
2. For each failure, confirm:
3. - Is the failing MX hostname actually one of your current mail servers, or a decommissioned/typo'd host that shouldn't be in your policy at all?
4. - Is the failure reason something you control (an expiring certificate on your own mail platform) or something environmental (a sender's misconfigured resolver)?
5. If you see failures against a legitimate MX host, fix the underlying issue (renew the certificate, correct the STARTTLS configuration on that mail platform, etc.) with your mailbox provider before proceeding.
6. If you see failures against a host that shouldn't be in the policy, go back to the MTA-STS builder, remove it from your MX list, save, and restart the testing clock.

Step 3: Confirm zero unexplained failures

You want to reach a state where, across a full reporting window, TLS-RPT shows either zero failures or only failures you fully understand and have separately mitigated (e.g. a known transient issue on a specific date that's already been resolved). Don't rush this step - moving to enforce with unresolved failures against a real MX host means legitimate mail starts bouncing.

Step 4: Switch mode to enforce

1. Go to app.dmarcengine.com/mta-sts.
2. Change the mode from testing to enforce.
3. Save. DMARC Engine regenerates the served policy immediately, and it takes effect as caching senders next re-fetch (see caching note below).

Warning Once you're in enforce, any MX host you haven't listed, or any certificate problem on a listed host, causes participating senders to refuse delivery rather than fall back to plaintext. Keep monitoring TLS-RPT after the switch - don't treat enforce as "set and forget."

Step 5: Keep watching after the switch

1. Continue reviewing Reports for at least another full cycle after enforcing.
2. Set (or re-check) your Alerts rule so any new failure surfaces immediately rather than at your next scheduled check-in.

Note MTA-STS policies are cached by the fetching sender for the duration specified in the policy (commonly a number of days). This means a change you make - including switching from testing to enforce, or updating your MX list - does not take effect instantly everywhere. Senders that already cached your testing policy will keep respecting that cached copy until their cache expires and they re-fetch. Build this lag into your rollout timeline; don't assume a mode change is universally live the moment you save it.

Enforce-readiness checklist

Before flipping to enforce, work through this list:

1. MX list is current and complete. Every hostname your mail platform actually uses to receive mail is present in the MTA-STS builder - including any secondary/backup MX you run.
2. No unexplained TLS-RPT failures in the most recent full reporting window (see the testing-to-enforce path above).
3. Certificate health confirmed on every listed MX host with your mail provider - not just the DMARC Engine-hosted policy certificate, but the certificates presented by your actual mail servers when a remote MTA connects to deliver mail.
4. DMARC is separately in a healthy state. MTA-STS and DMARC solve different problems, but if you haven't yet reviewed your DMARC posture, do that alongside this rollout - see Hosted DMARC and check current alignment in Analytics.
5. Stakeholders informed. If your organisation has a change window or a mail administrator who isn't you, let them know enforce mode is going live and roughly when, in case anything needs a fast rollback.
6. Rollback plan understood. You can switch back to testing (or none) from the MTA-STS builder at any time - but remember the caching note above: a rollback also takes time to propagate to senders holding a cached enforce policy.

The manual (self-managed) alternative

If your organisation has a specific reason not to delegate via CNAME - a policy against third-party DNS delegation, or a requirement to run your own HTTPS infrastructure - you can publish MTA-STS manually instead. This is materially more work to run correctly, because you take on both the certificate lifecycle for mta-sts.<domain> and the TLS-RPT report parsing yourself.

Step 1: Publish the TXT record for the policy ID directly

Instead of the CNAME, publish the TXT record with your own chosen policy ID (commonly a timestamp or incrementing version string - you must change this value every time you edit the policy file, or caching senders won't know to re-fetch it):

_mta-sts.yourdomain.com.    TXT    "v=STSv1; id=20260703120000Z"

Step 2: Host the policy file yourself

1. Stand up an HTTPS server (or static hosting bucket with a custom domain and valid certificate) reachable at mta-sts.yourdomain.com.
2. Serve the following content at exactly the path /.well-known/mta-sts.txt:

   version: STSv1
   mode: testing
   mx: mail.protection.outlook.com
   mx: mail2.yourdomain.com
   max_age: 604800
   

1. Ensure the certificate presented at mta-sts.yourdomain.com is valid and trusted - a self-signed or expired certificate here makes MTA-STS ineffective, because senders will refuse to trust the policy fetch itself.
2. Every time you change your MX hosts or your mode, you must update both the policy file content and bump the id= value in the _mta-sts TXT record, in that order - file first, then TXT, so no sender fetches a new ID before the corresponding file update is live.

Step 3: Publish the TLS-RPT TXT record directly

_smtp._tls.yourdomain.com.    TXT    "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

1. Set up a mailbox (or ingestion pipeline) at the address in rua= capable of receiving and unzipping the compressed JSON attachments senders will mail you daily.
2. Build or license a parser to turn that JSON into something a human can review - the raw format is not meant to be read directly.

Warning The manual path means you are solely responsible for: renewing the mta-sts.<domain> certificate before it expires (an expired cert here silently breaks MTA-STS delivery-fetching for every sender), keeping the policy file's MX list in sync with reality, correctly incrementing the policy ID on every change, and parsing TLS-RPT JSON reports yourself. Most of the operational incidents involving MTA-STS in the wild trace back to exactly these manual-maintenance failure modes - which is precisely what the hosted model in this guide exists to remove.

Verify it worked

Run through this checklist any time you set up MTA-STS for the first time, change your MX list, or switch modes.

1. Check the CNAMEs resolve correctly. Use the DNS Lookup tool or run:

   dig CNAME mta-sts.yourdomain.com +short
   dig CNAME _mta-sts.yourdomain.com +short
   dig CNAME _smtp._tls.yourdomain.com +short
   

Each should return the CNAME target shown in your MTA-STS builder for your domain's slug.
2. Fetch the served policy directly.

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

You should get back a 200 OK response with version: STSv1, your current mode, one mx: line per listed MX host, and a max_age value - served over a valid HTTPS connection (no certificate warnings).
3. Confirm the policy ID TXT is visible.

   dig TXT _mta-sts.yourdomain.com +short
   

Should resolve (via the CNAME) to a v=STSv1; id=... value.
4. Confirm the TLS-RPT TXT is visible.

   dig TXT _smtp._tls.yourdomain.com +short
   

Should resolve (via the CNAME) to a v=TLSRPTv1; rua=mailto:... value.
5. Check status inside the app. app.dmarcengine.com/mta-sts should show all three records verified and policy status Active.
6. Wait for the first TLS-RPT report. Reports typically start arriving within 24 hours of the TLS-RPT record propagating. Check Reports the following day to confirm data is flowing.
7. Cross-check against your DMARC posture. Since both systems protect the same domain from different angles, it's worth reviewing Analytics for your overall authentication health at the same time.

Common problems and fixes

Certificate stuck on "Activating…"
Almost always means the mta-sts.<domain> CNAME hasn't resolved yet, or was entered with a typo (wrong target, extra whitespace, missing dot conventions your DNS panel expects). Re-check with dig CNAME mta-sts.yourdomain.com +short or the DNS Lookup tool. If the CNAME is correct and resolving but the status hasn't moved after 20-30 minutes, contact Support.

Policy fetch returns a certificate warning or error
This should not happen on the hosted path once status shows Active - if it does, it typically means a caching resolver somewhere between you and us is still serving a stale answer for the CNAME. Try the fetch from a different network, or wait for TTL expiry, before escalating.

TLS-RPT reports show failures against a host you don't recognise
Compare the reported hostname against your actual, current MX records (Step 1 of "Before you start"). If it's not one of your real mail servers, remove it (or confirm it was never added) in the MTA-STS builder - a stale or mistaken MX entry left in the policy will otherwise sit there indefinitely.

No TLS-RPT reports arriving at all
Confirm the _smtp._tls CNAME is correctly published and resolving (Step 3 above). Also allow at least 24-48 hours for the first report - these are daily aggregates, not real-time, and not every sender you exchange mail with necessarily supports TLS-RPT yet.

Mail starts bouncing after switching to enforce
Switch back to testing immediately from the MTA-STS builder, then use TLS-RPT reports from the enforce window to identify exactly which MX host and which failure reason caused the rejection, fix it, and re-run the full testing-to-enforce path before trying again. Remember cached policies on the sender side mean a rollback also takes time to take effect everywhere.

Recently migrated mail providers and now seeing failures
This is the classic MX-list-out-of-sync scenario. Update your MX hosts in the MTA-STS builder the moment you know a migration is happening - ideally before the MX records themselves change, so the policy is never stricter than reality even for a short window.

DNS provider won't let you create the _mta-sts or _smtp._tls record
Some registrar control panels are picky about creating CNAMEs at names starting with an underscore, or at names that look like subdomains of subdomains. This is a data-entry quirk of the specific provider's UI, not a DNS rule - check that provider's own documentation for entering "advanced" or "service" record names; the underlying DNS is standard and every major provider supports it once you find the right form field.

Policy shows correctly but a specific sender still fails to deliver over TLS
Confirm that sender actually supports MTA-STS at all - adoption, while strong among the largest mailbox providers, is not universal. A sender with no MTA-STS support simply won't fetch or respect your policy either way; this isn't a fault in your configuration.

Frequently asked questions

Does MTA-STS protect outbound mail I send?
No. MTA-STS only governs mail arriving at your domain (inbound). It has no effect on the SPF/DKIM/DMARC checks receivers apply to mail you send. For outbound authentication, see Hosted DMARC, Hosted SPF and Hosted DKIM.

Do I need MTA-STS if I already have DMARC set up?
They solve different problems and are both worth having. DMARC authenticates who can send as your domain; MTA-STS protects the transport channel mail travels over to reach your mailboxes. Neither substitutes for the other.

How long should I stay in testing mode?
A minimum of one full reporting cycle (5-7 days) with zero unexplained TLS-RPT failures. If you change your MX list or mail provider during that window, restart the clock.

What happens if I never switch to enforce?
Your domain still benefits from encrypted transport where senders support opportunistic TLS anyway - testing mode doesn't cause any downgrade - but you get the reporting visibility of MTA-STS without the anti-downgrade guarantee that enforce provides. There's no urgency to enforce, but leaving testing running indefinitely without ever reviewing the reports defeats the purpose.

Can I run MTA-STS on a subdomain rather than the whole organisation's apex domain?
Yes - MTA-STS is configured per mail domain, so if a subdomain has its own MX records and receives mail independently, it needs its own MTA-STS setup, added as its own entry under Domains.

Does the hosted certificate need renewing by me?
No - the certificate for mta-sts.<domain> on the hosted path is provisioned and renewed automatically by DMARC Engine's SSL-for-SaaS infrastructure. This is one of the main reasons to prefer hosted over manual.

What's the difference between the policy-ID TXT record and the policy file itself?
The TXT record at _mta-sts.<domain> only carries a version identifier (id=...) - it's a cheap, fast-to-check signal that tells a sender "has anything changed since I last fetched?" The actual rules (mode, MX list, cache duration) live in the policy document served over HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt. On the hosted path we manage both and keep them in sync automatically whenever you save a change in the MTA-STS builder.

Will switching to enforce cause any legitimate mail to bounce?
Only if your policy is missing a real MX host, or if a listed MX host has a certificate/TLS problem - which is exactly what the testing-to-enforce path in this guide is designed to catch beforehand. Enforce mode itself is safe once your testing window shows clean reports.

Can I see MTA-STS alongside my other DNS records in one place?
Yes - Domains gives you a per-domain overview across DMARC, SPF, DKIM, MTA-STS and BIMI, and the DNS Lookup tool lets you check any record live at any time.

Where do I go if something isn't resolving as expected?
Start with the Common problems and fixes section above, use the DNS Lookup tool to confirm exactly what's published, and if you're still stuck, reach Support with the domain name and what you've already checked.

Related guides

• Hosted DMARC - the outbound sender-authentication policy that pairs with MTA-STS's inbound transport protection.
• Hosted SPF - auto-flattened SPF records kept under the 10-lookup limit.
• Hosted DKIM - cryptographic signing for outbound mail, delegated the same way as MTA-STS.
• Hosted BIMI - brand logos in the inbox, which requires an enforced DMARC policy as a prerequisite.