H
HTTPSense

MTA-STS & TLS-RPT Inspector

Check and validate MTA-STS and TLS-RPT records — fetch the policy file, verify the mode and mx coverage, and validate reporting.

What is an MTA-STS Inspector?

An MTA-STS inspector is a tool that checks a domain's SMTP MTA Strict Transport Security configuration — the _mta-sts TXT record published at _mta-sts.<domain> and the policy file served over HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt. Defined in RFC 8461, MTA-STS is a domain-level control that tells sending mail servers to require TLS for inbound SMTP, preventing attackers from stripping encryption and reading or tampering with mail in transit.

HTTPSense's MTA-STS Inspector resolves the advertisement record, fetches the policy file over strict TLS, and parses the version, mode, mx patterns, and max_age. It cross-checks the policy's mx list against your live MX records, validates the companion TLS-RPT (_smtp._tls) record and its reporting addresses, and surfaces problems like a missing policy, an invalid certificate, mode: testing or none, and uncovered MX hosts — then assigns a letter grade. It's free and requires no signup.

How to Use the MTA-STS Inspector

  1. Enter a domain name or URL in the search bar and click Inspect MTA-STS.
  2. Review the Summary tab for the record, the policy status, TLS validity, and the overall grade.
  3. Open the Policy tab to see the parsed policy and how each MX host maps to a policy pattern.
  4. Use the TLS-RPT tab to check the reporting record and each rua destination.
  5. Check the Findings tab for severity-ranked issues and concrete remediation steps.
  6. Use the Raw tab to copy or download the full JSON response.

How the MTA-STS Inspector Works

When you submit a domain or URL, we strip the scheme, port, and path to extract the bare hostname and query _mta-sts.<domain> for its TXT record through Cloudflare's public resolver (1.1.1.1). The record is checked for a valid v=STSv1 version and an id value, and we flag duplicate records that would make the advertisement invalid.

We then fetch the policy file from https://mta-sts.<domain>/.well-known/mta-sts.txt over a strict TLS connection — no redirects are followed and the certificate must validate — and parse the version, mode, every mx line, and max_age. In parallel we resolve the domain's MX records and match each host against the policy's mx patterns, including single-label wildcards, and resolve the _smtp._tls TLS-RPT record to validate its rua reporting URIs.

Finally we evaluate a findings catalog — missing record, missing or untrusted policy file, mode: testing or none, MX hosts not covered by any pattern, a missing TLS-RPT record, and a max_age that is too low — and translate the results into a 0–100 score and an A–F grade. We never send email or probe SMTP; the analysis combines DNS lookups with a single read-only HTTPS fetch of the public policy file.

Key Features

  • Record & policy validation — Confirms the _mta-sts advertisement and fetches the policy file over strict TLS.
  • Strict certificate check — Verifies the policy host serves a valid, publicly-trusted certificate with no redirects.
  • MX cross-check — Matches your live MX records against the policy mx patterns, including wildcards.
  • Mode grading — Distinguishes enforcing enforce from monitoring testing and disabled none.
  • TLS-RPT validation — Parses the _smtp._tls record and validates each reporting destination.
  • Findings & remediation — Severity-ranked issues, each with a concrete fix.
  • Scored grade & raw JSON — A 0–100 score mapped to an A–F grade, plus the full response for scripting.

Common Use Cases

  • Email administrators — Confirm the policy is enforcing and the certificate is valid before declaring MTA-STS done.
  • DevOps engineers — Verify the mx patterns still cover every MX host after a mail-platform change.
  • Security engineers — Catch testing or none modes and missing policies that leave SMTP downgradable.
  • Deliverability specialists — Ensure TLS-RPT reporting is wired up to diagnose TLS failures.

Frequently Asked Questions

What is MTA-STS and why does it matter?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a domain tell sending mail servers that inbound SMTP must use TLS and that the server certificate must be valid. Without it, SMTP encryption is opportunistic and can be silently stripped by an on-path attacker, downgrading mail to plaintext. MTA-STS closes that gap by publishing a signed-intent DNS record plus an HTTPS policy file that senders fetch, cache, and enforce.

Why does MTA-STS need both a DNS record and a policy file?

The _mta-sts DNS TXT record is only an advertisement: it carries a version and an id that changes whenever the policy changes, signalling senders to refresh. The actual rules — the mode, the list of authorized mx hosts, and the cache lifetime — live in a policy file served over HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt. The Inspector checks both: it confirms the record exists and then fetches the policy file over strict TLS to validate its contents.

What does the policy mode (enforce, testing, none) control?

The mode decides what a sending server does when an MX host is not covered by the policy or fails TLS. enforce means the sender refuses to deliver over an untrusted connection — full protection. testing means failures are reported via TLS-RPT but mail is still delivered, useful while rolling out. none effectively disables the policy. The Inspector grades enforce highest and flags testing and none so you know the domain is not yet fully protected.

What is TLS-RPT and how is it related?

TLS-RPT (RFC 8460) is the reporting companion to MTA-STS. A _smtp._tls TXT record publishes one or more rua addresses where receiving servers send daily reports about SMTP TLS connection successes and failures. Those reports are how you discover that mail to your domain is being downgraded or that a misconfigured MX is breaking enforcement. The Inspector validates the TLS-RPT record and each reporting URI alongside the MTA-STS policy.

Why does the Inspector compare the policy mx list to my MX records?

An MTA-STS policy only protects mail to the mx hosts it lists. If your domain adds or changes an MX host but the policy mx patterns are not updated, mail to the uncovered host falls outside enforcement — or, in enforce mode, can fail entirely. The Inspector resolves your live MX records and matches each against the policy patterns (including single-label wildcards), flagging any host that no pattern covers.