Blog · Dmarc
How to Set Up MTA-STS and DMARC Reporting for Your MSP Clients (Without Breaking Email)
The call comes in like this: "We need our email to be more secure. Our customers are asking about it. Can you take a look?" What they mean, more often than not, is either MTA-STS or DMARC - and often both. MTA-STS and DMARC solve different problems, but they fit together, and getting the rollout sequence right matters.
This guide is for the MSP that has done SPF and DKIM for clients and is now fielding questions about what comes next. It covers the practical sequence: check MTA-STS status first, set up DMARC reporting before you change anything, generate and deploy the MTA-STS record, monitor during testing, then enforce. It also covers what to do when something breaks, because something always breaks the first time.
MTA-STS stands for Mail Transfer Agent Strict Transport Security. In plain terms: it lets your domain tell receiving mail servers "only connect to me over TLS - if you can't, don't deliver the message." Without MTA-STS, a downgrade attack is possible: someone intercepts the SMTP handshake and forces an unencrypted connection.
The HTTPS analogy is apt but not perfect. HSTS tells browsers "always load this domain over HTTPS." MTA-STS tells mail servers "only accept TLS connections for this domain." Both are opt-in by the domain owner. Both have a cache duration (max_age). Neither is a magic switch - both require correct configuration or they can cause outages.
What MTA-STS does not do: authenticate the sending domain. It only ensures the transport layer is encrypted. DMARC handles the authentication part. These are complementary, not interchangeable.
MTA-STS has three policy modes. Getting these confused is where most broken rollouts start.
mode=testing is the starting point. A receiving server will attempt TLS, but if TLS fails, it falls back to delivering the message anyway - and then sends a report to your TLS-RPT address. Think of testing mode as a supervised rehearsal. You get visibility into what would break without actually breaking it. Use testing mode for at least two weeks, or until your TLS-RPT reports show zero failures for a consecutive period.
mode=enforce is the target state. Receiving servers must successfully negotiate TLS or they must refuse to deliver the message. No fallback, no delivery. This is what most security-conscious organizations want. It is also what can take down a client's email if their infrastructure has legacy SMTP relays, poorly configured third-party fax gateways, or older mailing list software that only does plaintext SMTP.
Decision guidance: start in testing. Switch to enforce when TLS-RPT shows clean delivery for at least 14 days across all known sending sources. Never skip the testing phase because enforce "sounds more secure" - testing mode is where you find the fax machine that only does TLS 1.0.
Before you generate a single DNS record, find out what is already there. This matters because:
Use the [DMARCFlow MTA-STS Checker](https://dmarcflow.com/mta-sts-checker) to look up the current policy for the client's primary domain and any subdomains used for mail. The checker will tell you whether MTA-STS is active, what mode is set, which MX servers are listed, and when the policy expires. Running this before you touch anything means you are working from a known state, not a guess.
Also check for TLS-RPT configuration. TLS-RPT (RFC 8460) is a companion to MTA-STS - it sends reports about TLS connection failures to a configured address. If the client already has TLS-RPT pointing somewhere they monitor, that reporting address is valuable to know about before you start.
Common findings at this stage:
This is the step most MSPs skip. Do not skip it.
Before you change the MTA-STS policy, you need to know what legitimate mail delivery looks like for this domain. If you turn on enforce mode and something breaks, the first question you need to answer is "was this sender legitimate?" DMARC aggregate reports (sent via RUA) are how you answer that question.
DMARC aggregate reports arrive as XML. Without a tool, they look like this:
...
With DMARCFlow, those same reports become a structured view: which senders are passing, which are failing, which third-party services are sending on behalf of the domain, and whether any policy failures are legitimate or indicate a problem.
For MSPs managing multiple clients, the multi-tenant DMARCFlow view is practical: one dashboard shows all client domains, each with their own DMARC status, third-party sender inventory, and policy change alerts. When a client's DMARC policy drops unexpectedly from reject to none - which happens more often than clients admit - DMARCFlow sends an alert. Parsing XML manually for one domain is tedious. Parsing XML manually for 30 domains is a full-time job.
Set up RUA to receive aggregate reports at a monitored address before you change anything MTA-STS-related. RUF (forensic reports) is optional - it sends individual failure samples and can be high-volume. Most MSPs skip RUF unless specifically needed.
MTA-STS is published as a DNS TXT record at `_mta-sts.[domain]`. The record format is:
v=STSv1; mode=testing; mx=*.mail.example.com; max_age=604800
The [DMARCFlow MTA-STS Generator](https://dmarcflow.com/mta-sts-generator) handles the formatting and reduces the risk of typos in the record syntax. Key fields:
mode - testing or enforce. Set to testing for initial deployment.
mx - the mail servers that are authorized to receive mail for this domain. Wildcards are allowed (`*.mail.example.com`). If the client uses a third-party email provider (Microsoft 365, Google Workspace, Rackspace), list their MX servers here, not the client's own MX. Getting the MX pattern wrong is the most common reason MTA-STS breaks legitimate mail delivery.
max_age - how long receiving servers should cache this policy before checking DNS again. Shorter values mean faster updates but more DNS queries. Longer values mean less overhead but slower propagation when you change the policy. 604800 seconds (one week) is a sensible default for testing. When you switch to enforce mode and want faster rollback capability, reduce this to 86400 (one day). Increase it back once the switch is stable and confirmed working.
One mistake to avoid: conflating max_age with DNS TTL. MTA-STS max_age controls receiving server caching, not your DNS record's TTL. Set your DNS TTL to match or exceed your max_age value to avoid inconsistent caching behavior.
After publishing the record, verify it resolves correctly with the MTA-STS Checker before declaring deployment done.
TLS-RPT reports arrive at the address specified in your TLS-RPT DNS record. These reports tell you which sending servers attempted to deliver mail to your domain and whether their TLS connection succeeded or failed.
TLS-RPT report format is JSON, which is far more readable than DMARC XML. A TLS-RPT failure typically looks like:
{
"date-range": { "start": 1717200000, "end": 1717290000 },
"failure-details": [
{
"result": "starttls-not-supported",
"sending-mta": "mail.badvendor.example.com",
"reachable": true,
"TLS": null
}
]
}
"starttls-not-supported" means the sending server tried to deliver over a plaintext connection - it does not support STARTTLS upgrade. This is the failure you see when a legacy system tries to send mail to your domain while MTA-STS enforce is active.
Keep TLS-RPT reports monitored throughout testing and after switching to enforce. Any new failure type appearing after enforce is switched on is a candidate for investigation before it becomes a support ticket.
The criteria for switching from testing to enforce should be explicit and documented before you start. Ambiguous criteria lead to enforce mode staying in testing forever.
Prerequisites for switching:
The rollback procedure: change mode from enforce back to testing. Receiving servers that have cached the enforce policy will continue to enforce for up to max_age seconds, but after that window, they will check your DNS again and apply testing mode. Document this delay with the client - "if we need to roll back, there is a window where enforce may still apply."
The max_age consideration: when you first published testing mode with max_age=604800, some servers cached that policy for a week. If you switch to enforce and some servers do not check for 6 days, those servers will still accept plaintext deliveries because they are still applying the cached testing policy. Plan for this lag when communicating timelines.
It will happen. The question is whether you find out before the client does.
[DMARCFlow's multi-tenant monitoring](https://dmarcflow.com) catches regressions early: if a client's DMARC policy unexpectedly reverts or a known sender starts failing, you get an alert rather than a support ticket. This is particularly useful for MSPs who manage dozens of domains - a single policy change on one domain can be easy to miss in a busy week.
Symptoms: a sender reports their emails to the client are bouncing or not arriving. TLS-RPT will show a failure type. DMARC RUA may show SPF or DKIM failures if the sending server's TLS failure caused it to retry over a different IP that is not in the SPF include.
Diagnosis steps:
Common causes of MTA-STS breakage:
The mitigation: maintain an inventory of all sending systems before you enforce. DMARC aggregate reports help here - every source appearing in RUA should be known. If you do not know who is sending mail from your client's domain, MTA-STS enforce will find out for you, possibly by blocking them.
MTA-STS and DMARC are standards, not products. The standards tell you what to do; they do not give you a dashboard.
DMARCFlow provides the operational layer that makes MTA-STS and DMARC manageable at MSP scale:
This is not about replacing what MSPs already do. It is about making the ongoing monitoring part scalable.
Does MTA-STS replace DMARC?
No. MTA-STS enforces TLS at the transport layer. DMARC authenticates the sending domain via SPF and DKIM alignment. Both are needed for a complete email security posture. Think of MTA-STS as the lock on the door and DMARC as the ID check at the door.
Does MTA-STS affect outbound or inbound email?
Inbound only. MTA-STS is evaluated by the receiving mail server, not the sending one. Your outbound mail is affected only if the receiving server has MTA-STS set to enforce - which means your sending infrastructure must support TLS or your messages will be rejected.
How long should I stay in testing mode?
At minimum two weeks, or until TLS-RPT shows no failures for a consecutive period. If the client has seasonal senders (quarterly newsletters, billing systems that only send monthly), extend testing until you have captured at least one full cycle of all legitimate senders.
What happens to emails during the max_age window if the policy server is down?
Nothing unusual. MTA-STS is a hint, not a guarantee. If the policy server is unreachable when a receiving server checks, it falls back to accepting the message. The max_age expiry only means "check again for an updated policy" - it does not mean mail stops flowing if the policy server is offline.
Can I use DMARCFlow for multiple independent client domains?
Yes. DMARCFlow's multi-tenant view is specifically designed for MSPs managing email authentication across client portfolios. Each domain is isolated; you see all of them in one dashboard without cross-client data leakage.
Can MTA-STS and STARTTLS coexist?
Yes, and they work together. STARTTLS is the SMTP upgrade mechanism that negotiates TLS on connection. MTA-STS says "this domain requires TLS" and is checked before STARTTLS negotiation. MTA-STS without STARTTLS is not possible - you cannot have MTA-STS enforce mode on a domain that does not advertise STARTTLS.
What does "MTA-STS policy mode: testing" actually enforce?
Testing mode logs failures and reports them via TLS-RPT. It does not reject any mail. The receiving server attempts TLS, and if TLS fails, it delivers anyway. Think of it as supervised validation: you see what would break if you enforced, without the breakage actually happening.
What is the difference between DMARC RUA and RUF reports?
RUA (Reporting URI for Aggregate) sends summary statistics - how many messages passed, failed, or were quarantined, aggregated by sending source. RUF (Reporting URI for Forensic) sends individual failure samples - one message at a time, with details about what failed and why. RUF is optional and can generate high volume; most MSPs configure RUA only.
MTA-STS and DMARC reporting are complementary tools that address different parts of the email security problem. MTA-STS enforces encrypted transport. DMARC reporting gives you visibility into who is sending mail on your domain's behalf. Used together, in the right sequence, they close off entire classes of email attack.
The practical sequence for MSPs: audit first, set up DMARC reporting, publish MTA-STS in testing mode, monitor TLS-RPT and DMARC RUA during a testing window long enough to capture all legitimate senders, then switch to enforce mode when the reports are clean. Document the rollback procedure before you start, because something will break the first time - and when it does, you want to know before the client calls you.
For MSPs managing this across multiple client domains, the operational overhead is real. DMARCFlow provides the monitoring layer that makes it manageable: MTA-STS checking and generation for deployment, multi-tenant DMARC monitoring for ongoing visibility, and alerting for when policies change unexpectedly.
The right time to start was six months ago. The second right time is before your client gets a phishing email that used to be preventable.