Free TLS Checker

Q: What is TLS-RPT?

SMTP TLS Reporting (RFC 8460) is a TXT record at _smtp._tls.yourdomain starting with v=TLSRPTv1 and a rua= address. Sending servers use it to send daily reports on how many connections to your domain succeeded, and how many failed and why, such as certificate problems or a policy they could not fetch. Without it, a broken MTA-STS policy or an expired certificate silently causes mail to bounce or be delayed. Read how VerifyDMARC turns those reports into alerts.

Q: Should I use testing or enforce mode?

Start in mode: testing with TLS-RPT configured. Senders behave as if the policy were enforced but still deliver the mail, and their reports show whether any of your MX hosts would fail. Once the reports are clean, switch to mode: enforce and update the policy id in the DNS record. Leaving a policy in testing mode indefinitely gives you reports but no protection.

Check how well any domain protects its inbound email in transit. The checker validates the TLS reporting record, the MTA-STS record and policy file, DNSSEC and DANE TLSA records, then reports the effective transport security level with actionable recommendations in plain language.

Need DMARC, SPF and TLS together? Run the free domain security check, or check DMARC or SPF on their own.

What the TLS checker tests

Mail delivery. The domain has MX records and accepts email. A null MX record or no MX at all is reported instead of a TLS result.
TLS reporting record. A single TXT record at _smtp._tls. your domain starting with v=TLSRPTv1 with a rua= address. Missing, malformed and duplicate records are flagged, and multiple addresses are noted because TLS reporting falls back between them rather than sending to all.
MTA-STS record. The TXT record at _mta-sts. your domain, including records reached through a CNAME, and the policy id it carries.
MTA-STS policy file. The policy is fetched over HTTPS and its version, mode, max_age and MX list are shown. The checker errors when a published MX host is missing from the policy, when max_age is over the one year RFC 8461 maximum or under the one day Google accepts, and warns when it is under the one week Google recommends.
DNSSEC. Whether the zone is signed, which DANE depends on.
DANE. Whether TLSA records exist for the MX hosts, evaluated only when DNSSEC is enabled.
Effective policy. The transport security senders actually get: Opportunistic TLS, MTA-STS, DANE, or MTA-STS + DANE.

How to read the security level

The result opens with an overall status and the messages behind it, then a table of security features. Effective Policy is the one to read first. Opportunistic TLS means senders encrypt the connection if they can but fall back to plain text if they cannot, so an attacker on the path can strip encryption and read the mail. MTA-STS or DANE means senders that support the mechanism will refuse to deliver without a trusted encrypted connection. MTA-STS + DANE covers both groups of senders.

Below the table, the MTA-STS Details section shows the DNS record and the policy file settings as fetched. Check that the mode is enforce, the MX hosts match your live MX records, and max_age is long enough that a brief outage of the policy host does not drop protection.

The Reporting Record (TLS-RPT) section shows whether senders have somewhere to report delivery failures. Enforcement without reporting means you will not find out when a certificate expires until mail starts bouncing.

Common TLS problems and how to fix them

Opportunistic TLS only. Publish an MTA-STS policy, or TLSA records if your zone is DNSSEC signed. Either one stops downgrade attacks on inbound mail; opportunistic encryption alone does not.
No TLS reporting record. Add a TXT record at _smtp._tls.yourdomain with v=TLSRPTv1; rua=mailto: and an address that is actually read, or a reporting service that turns the JSON reports into alerts. See how TLS failure alerts work.
MX host missing from the policy. Every host in your MX records must be covered by an mx: line in the policy file, otherwise senders will not deliver to it. Wildcards such as mx: *.mail.protection.outlook.com are allowed.
Stuck in testing mode. Testing mode reports problems but enforces nothing. Once TLS reports are clean, change the policy to mode: enforce and update the id in the DNS record so senders refetch it.
max_age too short. Senders drop the policy when it expires and they cannot refetch it. Use at least the week Google recommends; the checker reports anything under a day, which Gmail ignores, or over a year as an error.
Policy id not updated. Senders cache the policy until max_age expires unless the id in the DNS record changes. Bump the id every time you edit the policy file.
DANE without DNSSEC. TLSA records in an unsigned zone are ignored. Sign the zone first, or use MTA-STS. Read how Exchange Online handles DANE and MTA-STS on outbound connectors.

Know the moment TLS delivery breaks

A one-off check tells you where you stand today. The VerifyDMARC dashboard collects your TLS reports, alerts you when senders start failing to deliver over TLS, checks every domain's MTA-STS and DANE setup hourly, and sends regression alerts if the status downgrades. It sits alongside DMARC and SPF monitoring for every domain you manage.

Start Free Trial

See all features

TLS checker FAQ

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets a domain declare that mail servers delivering to it must use TLS with a valid certificate. Sending servers fetch the policy over HTTPS from https://mta-sts.yourdomain/.well-known/mta-sts.txt, cache it for max_age seconds, and refuse to deliver over an unencrypted or untrusted connection while the policy is in enforce mode.

A TXT record at _mta-sts.yourdomain tells senders a policy exists and carries an id that changes whenever the policy does.

What is TLS-RPT?

SMTP TLS Reporting (RFC 8460) is a TXT record at _smtp._tls.yourdomain starting with v=TLSRPTv1 and a rua= address. Sending servers use it to send daily reports on how many connections to your domain succeeded, and how many failed and why, such as certificate problems or a policy they could not fetch.

Without it, a broken MTA-STS policy or an expired certificate silently causes mail to bounce or be delayed. Read how VerifyDMARC turns those reports into alerts.

What is the difference between MTA-STS and DANE?

Both stop attackers downgrading inbound mail to an unencrypted connection. MTA-STS publishes the policy over HTTPS and relies on the web certificate system. DANE publishes TLSA records in DNS and relies on DNSSEC to protect them, so it needs a DNSSEC-signed zone.

They can run side by side. Microsoft 365 and Google both support MTA-STS as senders; Microsoft 365 also supports DANE. See whether DANE is right for your domain.

Should I use testing or enforce mode?

Start in mode: testing with TLS-RPT configured. Senders behave as if the policy were enforced but still deliver the mail, and their reports show whether any of your MX hosts would fail. Once the reports are clean, switch to mode: enforce and update the policy id in the DNS record.

Leaving a policy in testing mode indefinitely gives you reports but no protection.

Why does the checker say DANE requires DNSSEC?

DANE TLSA records only protect a connection if the sender can verify them with DNSSEC. If your zone is not signed, TLSA records offer no assurance and most senders ignore them, so the checker reports DNSSEC first and only evaluates DANE when it is enabled.

If your DNS provider cannot sign the zone, use MTA-STS instead. It gives comparable protection against downgrade attacks without DNSSEC.