SMTP Server Diagnostics

SMTP (Simple Mail Transfer Protocol) is the standard protocol used to transfer email between mail servers. When someone sends an email to your domain, their mail server looks up your MX records, opens a TCP connection to your SMTP server on port 25, and delivers the message. The quality of that connection — whether it is encrypted, authenticated, and correctly configured — determines whether your email infrastructure is secure and trustworthy.

SMTP itself is a plaintext protocol dating to 1982. Modern email security relies on layered extensions: STARTTLS for opportunistic encryption, MTA-STS for enforced TLS, DANE for certificate pinning via DNSSEC, and SPF/DKIM/DMARC for sender authentication. This tool focuses on the transport layer — the connection between mail servers — rather than the authentication records.

STARTTLS upgrades a plaintext SMTP connection to TLS without changing the port. The sending server issues a STARTTLS command, and both sides negotiate a TLS session before any message data is transmitted. This protects email content from passive eavesdropping between servers.

However, standard STARTTLS is opportunistic — if TLS negotiation fails, most servers fall back to plaintext delivery. An attacker performing a man-in-the-middle attack could strip the STARTTLS capability advertisement, causing email to be delivered without encryption. MTA-STS and DANE both address this downgrade vulnerability by requiring TLS.

An open relay accepts mail from any sender and forwards it to any recipient, with no authentication required. In the early days of the internet this was the default configuration, but open relays have been exploited by spammers for decades and are now considered a serious misconfiguration.

This tool tests for open relay by connecting to each MX server and issuing MAIL FROM and RCPT TO commands using external addresses. A correctly configured server will reject the relay attempt with a 5xx error. If the server accepts the command, it is flagged as an open relay and the domain receives an F grade regardless of other results.

MTA-STS (RFC 8461) lets a domain publish a policy declaring that it supports TLS and that senders must use it. The policy is served via HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt and activated by a DNS TXT record at _mta-sts.example.com.

Sending mail servers that support MTA-STS cache the policy and refuse to deliver email if TLS cannot be established or the certificate does not match the policy's MX pattern list. There are three policy modes: enforce (block delivery on TLS failure), testing (report failures but still deliver), and none (disable the policy). A domain with MTA-STS in enforce mode receives a significant security grade bonus.

DANE (DNS-Based Authentication of Named Entities, RFC 7671) pins a mail server's TLS certificate directly in DNS using TLSA records signed with DNSSEC. This eliminates reliance on certificate authorities — an attacker who compromises a CA cannot issue a fraudulent certificate that will be trusted for SMTP delivery.

TLSA records are published at _25._tcp.<mx-hostname>. The record specifies a certificate usage type, a selector (full certificate or public key), and a matching type (SHA-256 or SHA-512 hash). DANE requires the zone to be signed with DNSSEC — without DNSSEC, TLSA records cannot be trusted.

The overall grade reflects the security posture of the mail infrastructure. The grade is computed from weighted checks across connectivity, encryption, relay policy, and advanced security mechanisms:

SMTP connectivity is one layer of email security. For a complete picture, also check your sender authentication records:

• •MX Lookup — Find mail servers for any domain, detect email providers, and verify reverse DNS
• •SPF Checker — Validate which servers are authorized to send email for your domain
• •DKIM Checker — Verify your email signing keys and BIMI brand indicators
• •DMARC Checker — Analyze your email policy and reporting configuration