The problem it solves
SMTP negotiates TLS with a command called STARTTLS, and if that negotiation fails the sending server usually delivers in plaintext instead. An attacker positioned between two mail servers can simply strip the STARTTLS offer and read everything that follows. This is a downgrade attack, and it works because the fallback is silent by design.
How it works
MTA-STS publishes a policy at a fixed HTTPS URL on your domain — https://mta-sts.yourdomain.com/.well-known/mta-sts.txt — listing your MX hostnames and a mode. A DNS TXT record at _mta-sts.yourdomain.com tells senders the policy exists and carries a version ID so they know when it changes.
In enforce mode, a sending server that cannot establish valid TLS to your MX will refuse to deliver rather than fall back. testing mode reports failures without blocking, which is where you start.
TLS-RPT
The companion record is TLS reporting, at _smtp._tls.yourdomain.com. It asks senders to send you daily reports on TLS negotiation successes and failures. Without it you have no visibility into whether enforce mode is quietly rejecting legitimate mail, so publish it before you enforce.
Check yours
These run free in your browser. Nothing you type reaches a server.
Common questions
Does MTA-STS affect outbound mail?
No. It protects mail coming to you. It tells other servers how they must connect to your MX. It has no effect on how your own outbound mail is sent.
Is this needed for cold email?
Not for the sending domains, no. It matters on the domain where you actually receive mail, particularly if you handle anything sensitive.
What is the difference between MTA-STS and DANE?
Both prevent downgrade attacks. DANE uses DNSSEC to publish certificate constraints in DNS; MTA-STS uses HTTPS and requires no DNSSEC, which is why it is far more widely deployed.
Related concepts
If this is the thing going wrong
The pages explain it. If you would rather it was simply fixed, that is the work I do.