New tricks for your old email.

MTA-STS Validator

This tool can verify the MTA-STS and TLSRPT configuration of a given domain name, providing useful diagnostics, feedback and recommendations. Performed checks include references to the relevant standards they are derived from.

As defined by RFC-8461:

SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

In addition to MTA-STS, TLSRPT RFC-8460 is used by SMTP systems to report failures in establishing the expected TLS sessions to protect email traffic.

Various large email providers have pledged support to MTA-STS and TLSRPT. If your business deals with sensitive or private user information, these are security controls you should consider implementing to improve your overall email security.

Overall results

These results were produced on . (Showing cached results)

MX hosts
MX hosts
MTA-STS DNS Policy
MTA-STS DNS Policy
MTA-STS Policy Statement
MTA-STS Policy Statement

Checks performed

Valid MX record found for tested domain
Ensure that tested domain publishes MX records

A standard MX lookup for the tested domain is attempted using a public resolver as per RFC-5321. Having a set of hosts that can receive email directed to the tested domain is an obvious prerequisite for functioning MTA-STS.

DNSSEC is used for the lookup. If no DNSSEC validation is found, this will be reported as a warning. Although DNSSEC is not a requirement for MTA-STS implementation, its use has been a long-time best practice.

Mainly for historic reasons, MX records are not strictly required. Indeed, RFC-5321 § 5.1 explains that when no MX records are present, the domain name itself must be treated as an MX record with preference 0.

In our experience, a lack of MX records is more often than not an unintended misconfiguration, which is the main reason why this check fails when no MX records are returned.

MX hosts use a valid TLS certificate
MX hosts must present a valid, matching TLS certificate

A TLS connection is performed to each MX host using the RFC-3207STARTTLS extension, mimicking what a compliant MTA would attempt to do. Server Name Indication — as described in RFC-6066 — is used to signal multi-tenant MX hosts which certificate to use, as required by RFC-8461.

When no explicit MX records are present, this check considers the domain name itself as a preference 0 MX host, as described in RFC-5321 § 5.1. This follows historic, customary behavior by most MTAs.

Connections to the MX hosts are tried in parallel to reduce the wait for the check results.

This check requires a successful TLS connection in which the MX host presents a non-expired TLS certificate signed by a trusted CA and matching its DNS name.

Valid MTA-STS TXT record policy
DNS MTA-STS policy record must pass basic validation

The DNS label _mta-sts on the tested domain was resolved via a public DNS resolver. This check looks for a well-formed TXT record indicating presence and ID of a MTA-STS policy. The record's contents are parsed and the result validated according to the rules from RFC-8461. A strictly well-formed TXT record is required.

DNSSEC is used for the lookup. If a result is returned with no DNSSEC validation, a warning is provided. Note that as per RFC-8461, DNSSEC is not a strict requirement. That said, you should consider implementing DNSSEC for your domains.

Valid TLSRPT TXT record
DNS TLSRPT policy record must pass basic validation

TLSRPT is commonly implemented by organizations where TLS is employed to secure communications. It is defined in RFC-8460 and allows users to specify a mechanism where TLS failures can be reported automatically by affected sites.

The DNS TXT record _smtp._tls on the tested domain was resolved via a public DNS resolver. This check looks for a well-formed TXT record indicating presence of a well formed TLSRPT reporting policy suitable for MTA-STS. The record's contents are parsed and the result validated according to the rules from RFC-8460.

DNSSEC is used for the lookup. If a result is returned with no DNSSEC validation, a warning is provided. Note that as per RFC-8460, DNSSEC is not a strict requirement.

Since TLSRPT is not strictly mandatory in conjunction with MTA-STS, failures of this check are reported merely as warnings.

MTA-STS policy statement fetched through HTTPS
Policy document must be present and accessible

The MTA-STS policy statement is to be fetched via HTTPS as described in RFC-8461.

Fetching of the MTA-STS statement is attempted as required. The TLS certificate of the session is verified to ensure it matches the tested domain's required download location.

The download must be completed within a reasonable timeframe — 1 minute. Only an HTTP result code of 200 is accepted.

RFC-8461 § 3.3 mandate that HTTP 3xx redirects not be followed. However, this check will follow these redirects while noting the fact as an error in the Additional Information section below. This is done so as to provide more comprehensive diagnostics on the contents of the policy statement.

MTA-STS policy statement has valid syntax
Policy document musy be syntactically correct

When an MTA-STS policy statement document can be dowloaded, it is analyzed to ensure it's valid. Any syntax error causes this check to fail.

Conditions such as redundant headers are flagged with less severity, as this scenario is explicitly considered in RFC-8461 § 3.2.

Validation strictly follows the grammar depicted in RFC-8461, including line termination.

MTA-STS policy statement is valid
Policy document must be valid

Given a syntactically correct MTA-STS policy statement and a set of MX hosts for the tested domain, the names of all returned MX hosts are compared with the MTA-STS policy statement to ensure they are allowed.

If no MX records were found, validation is attempted using the plain domain name as RFC-5321 § 5.1 assumes an MX record with priority 0 pointing to the original domain name.

When all known MX hosts are allowed by the MTA-STS policy statement, this check passes.

Additional information

A note about caching

Keep in mind that DNS resolvers used by this test will cache responses for your _mta-sts and _smtp._tls records according to the TTL configured in your DNS zone. When initially deploying MTA-STS, it’s advisable to start with short TTLS — say, 10 seconds — and increase once the correct results are observed.

This validator will also reach out via HTTPS to download the MTA-STS policy statement from the mta-sts host at the domain being tested. Depending on the test settings, it will also connect to the domain’s MX hosts and perform a STARTTLS command to gain access to the X.509 TLS certificates being used. All of this generates traffic to the tested domains.

In order to minimize the resource footprint of this testing, results are cached for a few minutes. This means that policy fetching and MX probing will only happen once every few minutes.

Test results include the UTC time at which they were compiled. You can use this to ensure you’re acting on fresh results.