// how to fix
Protect your incoming mail with MTA-STS and TLS-RPT
MTA-STS forces other servers to use encryption when they deliver email to your domain. TLS-RPT sends you reports when that fails. Both are optional but recommended.
What it means
When a server delivers an email to your domain, it can encrypt the connection with TLS. By default this is optional: if someone in the middle blocks encryption, the email is sent in clear text and can be read or redirected.
- MTA-STS (Mail Transfer Agent Strict Transport Security) lets you say: "only deliver to my mail servers with valid encryption, otherwise do not deliver".
- TLS-RPT (TLS Reporting) asks other servers to send you a daily report when they had trouble connecting securely.
Both protect the email you receive. They do not change how your sent emails are scored.
Why it matters
They block interception of incoming email, such as invoices, password resets and contracts. Gmail, Microsoft and other large providers respect MTA-STS. They are recommended for businesses, but optional for small senders.
How to check
Use the Domain scanner at /domain-scanner. It looks for the MTA-STS record, downloads the policy file and checks the TLS-RPT record.
How to fix it
MTA-STS needs three pieces: a policy file on a website, a DNS record, and mail servers with valid certificates.
- Check your MX servers. They must offer TLS with a valid certificate matching their name. Google Workspace and Microsoft 365 already do.
- Create the policy file, a plain text file served at exactly
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Start in testing mode:version: STSv1 mode: testing mx: *.mail.protection.outlook.com max_age: 86400
List each of your MX hosts on its ownmx:line. For Google Workspace, usemx: *.google.comandmx: *.googlemail.com, or the exact names your MX records show. - Publish the website
mta-sts.yourdomain.comwith a validhttpscertificate. Any simple static hosting works. - Add the MTA-STS TXT record. Change the
ideach time you edit the policy file:_mta-sts.yourdomain.com TXT "v=STSv1; id=20261030"
- Add the TLS-RPT TXT record to receive reports:
_smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"
- Read the reports for a few weeks. When there are no failures, change
mode: testingtomode: enforce, raisemax_age(for example604800, one week), and change theidin DNS.
Be careful
In enforce mode, if your certificate expires or your MX changes without updating the policy, other servers will stop delivering to you. Update the policy file whenever you change email provider.
Check that it is fixed
DNS changes are not instant. Most are visible within a few minutes, but some providers take up to 24 to 48 hours.
Run the Domain scanner again: MTA-STS and TLS-RPT should both be found and valid.
The standards: RFC 8461 (MTA-STS) and RFC 8460 (TLS-RPT).
Check that it is fixed
DNS changes can take from a few minutes to a few hours. Then send a new test email or scan your domain again.
Related guides
- No SPF record on your domainYour domain does not say which servers may send email for it. Add one TXT record and receivers can tell your real emails from fakes.
- SPF error: too many DNS lookups (permerror)SPF allows at most 10 DNS lookups. Above that, the whole record breaks and receivers treat it as invalid. Here is how to slim it down.
- Several SPF records on one domainA domain must have only one SPF record. With two or more, SPF breaks for every email. Merge them into a single line.
- SPF fails: the sending server is not authorizedYour domain has an SPF record, but the server that sent your email is not in it. Find which service sent the email and add it.
- No DKIM signature on your emailsDKIM adds a digital signature that proves an email really comes from your domain. Turn it on in your email provider and publish its key in DNS.