Free email security gateway checker. Find which gateway protects a domain, and grade MTA-STS, TLS-RPT, DANE and DNSSEC. Passive DNS only, no probing.
Enter a domain and this tool reads its public DNS to answer two questions: where does mail for this domain actually go, and is that path protected in transit.
It identifies the mail security product in front of the domain by fingerprinting MX hostnames against a signature list covering Proofpoint, Mimecast, Barracuda, Cisco Secure Email, Forcepoint, Trend Micro, Sophos, Symantec Email Security.cloud, Trellix, Hornetsecurity, SpamTitan and others, plus the major cloud mailbox providers (Microsoft 365, Google Workspace, Zoho, Proton, Fastmail).
It then grades the transport layer: MTA-STS policy and mode, TLS-RPT reporting, DANE/TLSA records on the MX hosts, DNSSEC signing, and BIMI.
Every check is either a public DNS query or a fetch of the domain's own MTA-STS policy file, which RFC 8461 requires to be published at a well-known HTTPS URL for exactly this purpose. The tool never opens an SMTP connection, never scans ports, and never sends test mail. That makes it safe and lawful to run against a domain you do not own — a vendor, a supplier, or an acquisition target.
A secure email gateway (SEG) is a service that sits in front of your mailboxes and inspects inbound mail before it is delivered — filtering spam, malware, and phishing, and often rewriting URLs and sandboxing attachments. You can tell a domain uses one because its MX records point at the gateway vendor rather than at the mailbox provider. A domain whose MX points straight at mail.protection.outlook.com is relying on Microsoft's built-in Exchange Online Protection with no third-party inspection layer in front of it.
SMTP was designed without mandatory encryption. STARTTLS is opportunistic, which means an attacker who can intercept traffic between two mail servers can strip the TLS offer and read the mail in plaintext — a downgrade attack. MTA-STS fixes this by publishing a policy that tells sending servers they must use validated TLS to reach you, and to refuse delivery rather than fall back to cleartext.
An MTA-STS policy in testing mode reports failures but still delivers over insecure connections. Only enforce mode actually blocks the downgrade. This tool distinguishes between the two, and specifically flags the common misconfiguration where the _mta-sts TXT record exists but the policy file is unreachable — in which case senders ignore the policy entirely and you have no protection despite appearing to be configured.
TLS-RPT (_smtp._tls TXT record) asks sending servers to report TLS negotiation failures to you, so a broken certificate or a stripped connection surfaces as a report rather than as silent, invisible plaintext delivery.
DANE publishes TLSA records that pin the certificate of each MX host through DNSSEC, removing the reliance on public certificate authorities. It is widely deployed in Europe and increasingly required in government mail.
DNSSEC underpins the rest. Without it, an attacker who can tamper with DNS responses can forge your MX, MTA-STS and DMARC records, and every policy above becomes advisory rather than enforceable.
Those are sender-authentication records and are covered in depth by the Email Authentication Validator, which parses SPF, discovers DKIM selectors and grades your DMARC policy. Use both: authentication proves who sent the mail, transport security protects it on the wire.
The score reflects transport posture only, out of 100. MX presence and redundancy contribute up to 30 points, a recognised gateway up to 15, MTA-STS up to 25 (enforce mode scores the full amount, testing mode roughly half), TLS-RPT 10, DNSSEC 10, DANE 5 and BIMI 5. A domain in the A band has MTA-STS enforcing, reporting enabled and signed DNS. Most domains land in the D or F band because MTA-STS is still uncommon outside large enterprises and government.