MTA-STS & TLS-RPT Checker

Check that sending servers are told to deliver your mail only over verified TLS, and that you receive TLS failure reports.

Result

Looks good

Checked

  • OK

    MTA-STS is enforced

    Senders that support MTA-STS will only deliver over authenticated TLS to the listed mail servers.

  • OK

    All MX hosts match the policy

    alt3.gmail-smtp-in.l.google.com, gmail-smtp-in.l.google.com, alt2.gmail-smtp-in.l.google.com, alt1.gmail-smtp-in.l.google.com, alt4.gmail-smtp-in.l.google.com

  • OK

    TLS reporting is enabled

    Reports go to mailto:sts-reports@google.com.

MTA-STS record _mta-sts.gmail.com

v=STSv1; id=20190429T010101;

Policy file https://mta-sts.gmail.com/.well-known/mta-sts.txt

Modeenforce
Allowed MXsmtp.google.com
gmail-smtp-in.l.google.com
*.gmail-smtp-in.l.google.com
max_age86400 (24 h)
Raw policy
version: STSv1
mode: enforce
mx: smtp.google.com
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

Your MX hosts

alt3.gmail-smtp-in.l.google.com
gmail-smtp-in.l.google.com
alt2.gmail-smtp-in.l.google.com
alt1.gmail-smtp-in.l.google.com
alt4.gmail-smtp-in.l.google.com

TLS-RPT record _smtp._tls.gmail.com

v=TLSRPTv1;rua=mailto:sts-reports@google.com

About this tool

SMTP encryption between mail servers is opportunistic: an attacker who can interfere with the connection can strip TLS and read mail. MTA-STS (RFC 8461) lets a domain publish a policy saying "only deliver to these MX hosts, over TLS with a valid certificate". TLS-RPT (RFC 8460) asks senders to report delivery problems.

The checker reads the _mta-sts TXT record, downloads the policy from https://mta-sts.<domain>/.well-known/mta-sts.txt (without following redirects, as the standard requires), compares the policy with your real MX records and validates the _smtp._tls reporting record.

How to read the results

  • mode: enforce — supporting senders refuse to deliver if TLS or the certificate fails. testing — they deliver anyway and report. none — policy withdrawn.
  • mx lines — must match every MX host; *.example.com covers one extra label.
  • max_age — how long senders cache the policy (up to 31557600 seconds).
  • id in the DNS record — change it whenever you change the policy file so senders refetch it.

Limitations

  • The tool checks the published policy and certificate trust of the policy host. It does not connect to your MX servers on port 25 to test STARTTLS, because hosting networks usually block that port.
  • Senders that do not support MTA-STS ignore the policy.

Frequently asked questions

Do I need MTA-STS if I already have SPF, DKIM and DMARC?

Those protect against spoofing. MTA-STS protects confidentiality in transit — a different problem. It is recommended for domains handling sensitive mail.

Should I start in enforce mode?

No. Start with mode: testing plus TLS-RPT, review the reports for a couple of weeks, then switch to enforce.

Why must the policy host have a valid certificate?

Senders fetch the policy over HTTPS and only trust it if the mta-sts subdomain has a publicly trusted certificate.

What do I put in the TLS-RPT record?

For example: v=TLSRPTv1; rua=mailto:tls-reports@example.com. Reports arrive daily as JSON.

What does MTA-STS stand for?

Mail Transfer Agent Strict Transport Security.

Where is the MTA-STS policy file?

At https://mta-sts.yourdomain/.well-known/mta-sts.txt.