MTA-STS Record Checker

Free online tool · DNS-over-HTTPS live lookup · runs in your browser, no data upload

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) enforces TLS-encrypted transport between mail servers via a DNS record plus an HTTPS policy file, preventing SMTP downgrade attacks (STRIPTLS) and man-in-the-middle eavesdropping. Its discovery record _mta-sts.<domain> declares the policy version and the HTTPS location of the policy file, which specifies the allowed MX hosts and encryption mode. MTA-STS is a modern baseline for mail transport security (used alongside DANE/TLSA).

Enter a domain; the tool queries the _mta-sts. TXT record (MTA-STS policy discovery record) and tries to fetch the policy file at https://mta-sts./.well-known/mta-sts.txt.

Features

  • Discovery record: queries the _mta-sts.<domain> TXT record, checks v=STSv1 and id= version
  • Policy file fetch: tries https://mta-sts.<domain>/.well-known/mta-sts.txt and parses mx/enforce directives
  • Dual-missing detection: reports “missing discovery record” and “missing policy file” separately to locate the break
  • DANE note: explains how MTA-STS complements DANE/TLSA (RFC 7672)

How to Use

MTA-STS has two parts: (1) the _mta-sts. TXT discovery record (v=STSv1; id=), and (2) the policy file at https://mta-sts./.well-known/mta-sts.txt. The tool queries the discovery record first, then fetches and parses the policy file if present. Both are required — with only one of the two, MTA-STS cannot take effect. The policy file must be served over HTTPS with a valid certificate, otherwise senders ignore it per RFC 8461.

Why Check Regularly

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) solves the enforceability of encrypted mail transport. STARTTLS is standard, but traditional implementations can be downgraded — an attacker intercepts the handshake and tricks both sides into plaintext.

MTA-STS enforces encryption with two components: the _mta-sts discovery record (TXT) in DNS, and an HTTPS-hosted policy file. Only when both are in effect does the receiving MTA apply “mandatory TLS + certificate validation”.

When checking MTA-STS: the discovery record and policy file must both exist and match (policy-id); the policy file’s HTTPS certificate must be valid (RFC 8461 §3.3 requires chain validation); and the mx list must match actual MX records — otherwise legitimate mail gets rejected.

Interpreting Results

CheckPass CriteriaRisk
Discovery record_mta-sts.<domain> TXT record exists with v=STSv1High (policy inert if missing)
Policy filehttps://mta-sts.<domain>/.well-known/mta-sts.txt reachableHigh
policy-idid fields of the discovery record and policy file matchMedium
mx listPolicy file mx field matches actual MX recordsHigh
HTTPS certificatemta-sts subdomain certificate valid and trustedHigh

Common Misconfigurations & Fixes

  • Missing discovery record: Add a TXT record: v=STSv1; id=20260101 (use a date for easy rotation)
  • Policy file unreachable: Deploy HTTPS on the mta-sts subdomain serving /well-known/mta-sts.txt with version: STSv1 and the mx list
  • policy-id mismatch: make the id fields identical in both; otherwise the policy is ignored
  • mx list mismatch: list all actual MX hosts in the policy mx field; omissions cause rejection
  • Certificate issues：Get a valid certificate for the mta-sts subdomain (wildcard or single-name) and complete the chain

Technical Standards

This tool follows the IETF standards below; lookup and parsing logic match the RFC definitions:

  • DNS lookup: RFC 8484 (DNS Queries over HTTPS), RFC 1035 (DNS protocol)
  • Record parsing: MTA-STS: RFC 8461 §3.1 (discovery record), §3.2 (policy file)