# MTA-STS and TLS-RPT After SPF, DKIM, and DMARC

Canonical: https://vulnify.app/blog/mta-sts-and-tls-rpt-for-site-owners

MTA-STS and TLS-RPT protect the SMTP connection. They do not prove who sent the mail. Publish them after SPF, DKIM, and DMARC, and look the records up at your DNS host.

MTA-STS and TLS-RPT tell other mail servers how to deliver mail to your domain over encrypted SMTP, and where to send a report if that delivery fails. They do not say who is allowed to send as you. SPF, DKIM, and DMARC do that job. Mixing the two families is how a domain owner “turns on TLS policy” and still gets spoofed, or locks down DMARC and still accepts a downgraded connection on the way in. Read SPF, DKIM, and DMARC mistakes before you add another policy. If you cannot name your legitimate senders, you are not ready for a stricter DMARC tag, and you are also not ready to debug a new TLS report. Record drafting for SPF and DMARC stays in the drafting guide . What each control actually answers SPF lists hosts allowed to use your domain in the envelope. DKIM signs the message with a key you publish. DMARC says what to do when those checks do not align with the From domain, and where to send aggregate reports. None of those records force the receiving server, or a server delivering mail to you, to use a validated TLS session. MTA-STS is inbound delivery policy for your MX hosts. A sender that supports it will fetch a policy file over HTTPS and refuse to deliver if your mail host does not present a matching certificate. TLS-RPT is the reporting address for TLS failures, published at a different DNS name. STARTTLS without a policy can be stripped by an attacker on the path. The policy is what makes “encryption failed” a failed delivery instead of a silent downgrade. It still says nothing about whether the message that did arrive was authorized to use your name. The names to publish You need two DNS TXT records and one HTTPS file. The TXT record at _mta-sts.example.com carries an id that you change whenever the policy file changes. The policy file itself is at https://mta-sts.example.com/.well-known/mta-sts.txt and names your MX hosts and a mode. Start in testing mode until reports look calm, then move to enforce. The TXT record at _smtp._tls.example.com carries the TLS-RPT address, which can be a mailbox. The policy host, mta-sts.example.com , must have a valid public certificate. A certificate warning on that host means senders cannot fetch the policy. CAA and the certificate on your website are related hygiene, not substitutes. CAA records limit who may issue. They do not publish an SMTP policy. What Vulnify will and will not look up The DNS record lookup reads address records, mail exchange, name servers, SPF from the apex TXT, CAA, and, in comprehensive mode, www and _dmarc . It does not query _mta-sts or _smtp._tls . The email security checker grades SPF, DKIM, and DMARC. It does not grade MTA-STS. Do not paste the domain into those tools and treat a pass as an SMTP policy pass. Check the two underscored names in the DNS host’s own panel, or with a DNS query you run yourself against those exact names. Then fetch the policy URL in a browser and confirm it lists the MX hosts you still use. After a mail-host migration, update the policy file and change the id in the TXT record. A stale policy that names the old MX is how you strand mail after a cutover that SPF and DMARC both survived. Read TLS reports the way you read DMARC reports TLS-RPT messages describe delivery attempts that failed certificate or policy checks. They are not DMARC aggregate XML, and they do not list spoofed From addresses. A sudden burst after you change certificates is a rollout problem. A single unknown reporter is not an incident by itself. Keep the same habit as DMARC: know which hosts should succeed, and treat surprises as questions for the mail team. Daily monitoring of authentication records still matters. Mail Watch for SPF, DKIM, DMARC, and blacklists will tell you when those records change. It will not tell you that the MTA-STS id changed. Put the policy id in the same change log as the MX cutover so the next person sees it. A sane order Publish SPF and DKIM for every real sender. Publish DMARC at p=none with a report address you read. When the reports are boring, tighten DMARC. Then add MTA-STS in testing mode and TLS-RPT. Move MTA-STS to enforce when the TLS reports show your real MX hosts succeeding. Skipping ahead feels efficient until a sender refuses delivery because the policy file named a host you retired. Outbound mail you send to other domains is their MTA-STS problem when you deliver to them. Your record protects mail they send to you. Both directions matter to a company that receives invoices and also sends them. Do not expect one TXT record on the apex to cover this. The apex is where SPF lives. These names are separate. Change the id when the policy changes Senders cache your MTA-STS policy for the max-age you published. If you change MX hosts and forget to change the id in _mta-sts , those senders keep using the old file until the cache ends. Mail to the new host can fail, or mail can keep aiming at the host you retired. Update the file, then the id, then fetch the URL from outside your office network so you are not looking at a cached copy on your own laptop. TLS-RPT will get noisier during that change. Expect failure rows while the cache and the new certificate overlap. A failure row that continues after the cache window, against an MX host you still use, is the one to fix. A failure row against a host you no longer operate is a sign the old name is still in the policy file. Do this on a domain that actually receives mail A marketing domain with no MX record does not need MTA-STS. Publishing a policy for a domain that should not receive mail can create delivery attempts you did not want. If the domain is send-only, DMARC and SPF still matter for mail that leaves it, and MTA-STS does not. Confirm MX exists, and that those MX hosts are yours, before you write the policy file. The DNS record lookup will show MX. It still will not show the MTA-STS name. Use it for the MX check only. Write the policy mode, the id, and the MX names into the same change log as SPF and DMARC. The next person should not have to fetch the policy URL to learn whether you are still in testing. If testing has lasted more than a month and the TLS reports are quiet, move to enforce. A testing policy that never changes is a project you stopped, not a control you finished. Frequently asked questions Does MTA-STS stop spoofing? No. Spoofing of your From domain is a DMARC question. MTA-STS stops a downgrade of encryption when other servers deliver mail to your MX. Can I check the records in Vulnify’s DNS lookup? Not those names. The lookup includes _dmarc on a comprehensive run. Query _mta-sts and _smtp._tls at your DNS host, and open the policy URL yourself. Should testing mode stay forever? No. Testing mode is how you collect failures without blocking mail. Enforce is the point, after the reports show the MX hosts you intend.