ApiVectPRACTICAL GUIDE
MTA-STS: check the policy before enforcing mail delivery
By ApiVect ·
Review DNS, the HTTPS policy and TLS reports together. Understand testing mode and the boundary between configuration checks and real mail delivery.
A published mail-security policy is useful evidence, but it does not tell you whether a particular message reached its destination securely. Before changing an MTA-STS policy to enforcement, review the configuration and ask your mail operator for delivery evidence. This guide connects those two tasks without treating a configuration report as a live SMTP test.
Read DNS and HTTPS together
MTA-STS lets a receiving domain publish expectations for encrypted SMTP delivery. Its discovery TXT record lives at _mta-sts; the policy is served over HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt. The TXT record alone is not the full policy. Review the policy's permitted MX hosts, mode and cache lifetime together, using the RFC 8461 discovery rules.
Make a review worksheet for your own domain: current MX hosts, the person responsible for mail routing, the policy host, the last change and the evidence still missing. Include backup mail routes. An entry marked “needs confirmation” is more useful than a green report that hides an unanswered operational question.
Use a synthetic example to practise the review
The following fictional setup illustrates the relationship between records. It is not a live domain check, an ApiVect response or a production configuration to copy. Assume that example.com uses only the mail host shown:
_mta-sts.example.com. TXT "v=STSv1; id=Guide20261009A;"
# HTTPS policy body, served at the fixed policy path:
version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400
_smtp._tls.example.com. TXT
"v=TLSRPTv1; rua=https://reports.example.com/tls"The comment identifying the HTTPS body is explanatory and is not part of the policy file. The illustrative max_age is in seconds; it is not a universal recommended lifetime. Before using a real setup, replace every example hostname and prepare a reporting destination that your organisation controls and can process.
Testing mode gives you a review stage
In testing mode, supporting senders may deliver despite an MTA-STS validation failure. In enforce mode, senders honouring the policy must refuse delivery to hosts that fail its MX, certificate or STARTTLS requirements. Testing therefore does not mean that enforcement is already active. See RFC 8461 policy application.
Before deciding to enforce, ask your mail operator to confirm every published MX route, its SMTP TLS behaviour and certificate handling. Agree who will investigate a failure and how a planned mail-provider change will be reviewed. Record the actual answers alongside the worksheet; do not substitute a website certificate check for the mail server's test results.
Use TLS-RPT as a separate evidence source
TLS-RPT requests aggregate transport reports from participating senders through a TXT record at _smtp._tls. Reports can describe successful sessions and failures such as certificate problems or unavailable STARTTLS. They are delivery observations from reporting systems, rather than another copy of your DNS configuration. The format and reporting mechanism are defined in RFC 8460.
Choose who owns the reporting destination and who reads the results. Preserve the report's time range when discussing a change. A quiet reporting destination is not proof that every sender succeeded: you also need to establish whether reports are arriving and which systems contributed. Keep operational reports private; a public guide or support screenshot does not need their addresses or connection details.
Know what ApiVect checks
ApiVect's Domain & Email Security API reviews published MTA-STS and TLS-RPT records and the HTTPS policy. Its separate certificate check concerns public HTTPS on port 443. It does not test SMTP/STARTTLS, send messages, process your TLS reports or guarantee delivery. Missing optional MTA-STS or TLS-RPT records are reported as not_configured; that status is different from a confirmed configuration failure.
Use the individual check, status and recommendation to decide what to investigate next. Save your configuration review separately from the mail operator's observations. For policy changes, RFC 8461 advises updating the HTTPS body before the TXT identifier; account for cached policies and DNS TTLs instead of assuming every sender sees a change immediately.
Review your configuration with ApiVect
ApiVect provides the commercial domain tools behind this guide. Start with the documented coverage, run a configuration check when appropriate, and bring unresolved delivery questions to your mail operator.
Sources and further reading
Sources and product coverage checked on 9 October 2026. RFC 8461 and RFC 8460 were published in September 2018; this is a practical guide, not a new standards announcement.