What does the SMTP diagnostics tool test?

This tool runs a nine-part SMTP health check for any domain. It starts by resolving MX records as defined in RFC 5321 Section 5 to discover all mail servers, then attempts TCP connections to each one on port 25 with detailed failure diagnostics. For every reachable server, it negotiates STARTTLS (RFC 3207) and inspects the TLS version, cipher suite, and certificate validity. It also probes for open relay vulnerabilities (RFC 5321 Section 7.1), verifies PTR records for forward-confirmed reverse DNS (RFC 5321 Section 4.1.4), and checks for MTA-STS policy (RFC 8461), TLSRPT reporting records (RFC 8460), and DANE/TLSA certificate pinning (RFC 7671). Results stream in real time as each test completes. Everything rolls up into a letter grade from A+ to F that summarizes the security posture of the entire mail infrastructure at a glance.

What is STARTTLS and why does it matter?

STARTTLS is a protocol extension defined in RFC 3207 that upgrades a plaintext SMTP connection on port 25 to encrypted TLS without needing a dedicated secure port. Without it, email between mail servers travels in cleartext. Anyone on the network path, whether an ISP, a network admin, or an attacker, can intercept, read, or modify the messages. When STARTTLS works correctly, this tool reports the negotiated TLS version (ideally TLS 1.2 or 1.3, since RFC 8996 deprecates older versions), the cipher suite, and certificate details including the issuing CA and expiration date. The catch is that standard STARTTLS is opportunistic. If negotiation fails, most servers silently fall back to plaintext delivery. An attacker can exploit this by stripping the STARTTLS advertisement. To prevent these downgrade attacks, deploy MTA-STS (RFC 8461) or DANE (RFC 7671) alongside STARTTLS.

What is an open relay and why is it dangerous?

An open relay is an SMTP server that accepts and forwards email from any sender to any recipient without authentication. RFC 5321 Section 7.1 warns strongly against this because it lets anyone on the internet route email through your server. Spammers and phishing operators love open relays. They use them to push bulk malicious email through third-party infrastructure, hiding the true origin of messages and making abuse much harder to trace. Once a server is identified as an open relay, it gets added to DNS-based blacklists (DNSBLs) like Spamhaus ZEN, Barracuda, and SpamCop very quickly. At that point, all legitimate outbound email from your server starts getting rejected by receiving mail systems too. This tool sends a controlled test relay attempt using a non-deliverable address and checks whether your server correctly rejects the unauthorized request with a 5xx error code.

What is MTA-STS and how does it prevent downgrade attacks?

MTA-STS, defined in RFC 8461, lets a domain declare that its mail servers support TLS and that sending servers should refuse delivery if a secure connection cannot be established. This solves a real problem with standard STARTTLS: if TLS negotiation fails, most sending servers silently fall back to plaintext. A man-in-the-middle attacker can exploit this by stripping the STARTTLS advertisement from the server response, forcing all email to travel unencrypted. MTA-STS prevents this downgrade attack through two components. First, an HTTPS-hosted policy file at https://mta-sts.yourdomain/.well-known/mta-sts.txt lists the authorized MX hostnames and enforcement mode. Second, a DNS TXT record at _mta-sts.yourdomain activates the policy with a unique identifier. Sending servers cache this policy and refuse plaintext delivery when the mode is set to "enforce." The combination of HTTPS and DNS makes it much harder for attackers to forge or suppress the policy.

What is DANE/TLSA and how does it differ from MTA-STS?

DANE (DNS-Based Authentication of Named Entities), specified in RFC 7671 for SMTP, uses DNSSEC-signed TLSA records to cryptographically pin the exact TLS certificate a mail server should present during the STARTTLS handshake. Where MTA-STS relies on HTTPS and the public CA trust chain, DANE lets the domain owner assert directly in DNS which certificate or public key is valid. This completely removes the need to trust certificate authorities. A TLSA record is published at _25._tcp.mx-hostname and contains the certificate usage, selector, matching type, and certificate data hash. The key requirement is that the domain must have a fully signed DNSSEC chain from the root zone all the way down to the TLSA record. MTA-STS takes a different approach, requiring a valid HTTPS certificate on the mta-sts subdomain instead. Both prevent TLS downgrade attacks, but they use fundamentally different trust anchors. DANE provides stronger cryptographic assurance, though it requires DNSSEC deployment, which fewer than 10% of domains currently support.

What does the grade mean?

The letter grade rolls up the entire mail security assessment into a single rating. A+ requires STARTTLS with TLS 1.3, a valid trusted certificate, no open relay, correct PTR (forward-confirmed reverse DNS), and either MTA-STS in enforce mode or DANE with valid DNSSEC. A requires STARTTLS with TLS 1.2 or higher, a valid certificate, no open relay, and correct PTR records. B means STARTTLS is present but there are minor issues like certificate hostname mismatches or missing PTR records. C flags weak TLS versions (1.0 or 1.1, deprecated per RFC 8996) or self-signed certificates. D means STARTTLS is absent or some MX servers have connection failures. F indicates critical problems: either an open relay was detected, or no TLS encryption is available on any reachable server. The grade gives you a quick read on where things stand, while the detailed results below it explain exactly what needs fixing.

Why do connections time out on port 25?

Port 25 timeouts usually mean a firewall or network filter is silently dropping inbound TCP SYN packets without sending a RST (reset) back to the client. Several things can cause this. The mail server's host firewall (iptables, nftables, or Windows Firewall) might block port 25 from certain IP ranges or geographic regions. Cloud providers like AWS, Google Cloud, Azure, and Hetzner often restrict outbound port 25 by default to prevent spam, which can affect the scanning server's ability to connect. The MX hostname might resolve to an IP that does not run an SMTP service at all, like a parking page or decommissioned server. ISPs and upstream transit providers sometimes filter port 25 traffic as part of anti-spam measures too. One useful distinction: a timeout is different from a connection refusal. A refusal (RST packet) means the port is actively closed but the host is reachable. A timeout means packets are being silently dropped or the host is completely unreachable.

Which ports does this tool test?

This tool connects exclusively on port 25, the standard SMTP relay port for server-to-server email delivery as defined in RFC 5321. Port 25 is what other mail servers use to deliver inbound email to your domain, so it is the right port for testing whether your mail infrastructure is reachable and properly secured. Ports 587 and 465 serve a different purpose entirely. Port 587 (message submission, RFC 6409) and port 465 (implicit TLS submission, RFC 8314) are used by mail clients like Outlook, Thunderbird, and mobile apps to submit outgoing messages to their provider. They require SMTP AUTH authentication. These submission ports are not tested here because they are not part of the server-to-server delivery path. External mail servers never connect to your port 587 or 465 to deliver email to your domain. Testing those ports would require a different diagnostic tool focused on client-to-server authentication workflows.

What is TLSRPT and why should I configure it?

TLSRPT (SMTP TLS Reporting) is defined in RFC 8460. You publish a DNS TXT record at _smtp._tls.yourdomain that tells sending mail servers where to submit daily aggregate JSON reports about TLS connection failures when delivering email to your domain. These reports surface problems that would otherwise go completely unnoticed: MTA-STS or DANE policy violations, certificate expiry causing TLS handshake failures, STARTTLS stripping attacks where someone removes TLS capability advertisements, DNS resolution failures for MX hostnames, and certificate chain validation errors. TLSRPT becomes especially important once you deploy MTA-STS in enforce mode. Without it, you have no visibility into whether your policy is working correctly or accidentally causing legitimate email to bounce. To set it up, add a TXT record at _smtp._tls.yourdomain with the value v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain. That tells senders where to deliver the reports.

What is PTR (reverse DNS) and why does it matter for email?

A PTR (pointer) record maps an IP address back to a hostname, the reverse of what an A record does. RFC 5321 Section 4.1.4 recommends that SMTP servers have forward-confirmed reverse DNS (FCrDNS). This means the PTR record for your server's IP should resolve to a hostname that in turn resolves back to that same IP via an A record. Gmail, Outlook, Yahoo Mail, and most other receiving servers check for valid FCrDNS as a basic anti-spam signal during the SMTP connection. Servers with missing PTR records, mismatched PTR hostnames, or generic ISP-assigned entries like 123-45-67-89.example.isp.net are significantly more likely to have their email flagged as spam, deferred, or rejected outright. One thing that catches people off guard: you cannot configure PTR records in your domain's DNS zone. PTR records are managed by whoever controls the IP block, so you need to contact your hosting provider or IP assignee to set them up.

SMTP Server Diagnostics

Test mail server connectivity per RFC 5321, TLS encryption, open relay status, MTA-STS, DANE, and PTR records. Get a graded security report for any domain in real time.

“SMTP is the protocol that actually delivers your email. If the handshake fails, nothing else matters.”

Written by Ishan Karunaratne · Last reviewed: March 11, 2026

What Is SMTP?

SMTP (Simple Mail Transfer Protocol), defined in RFC 5321, is the standard protocol for transferring email between mail servers. When someone sends an email to your domain, their mail server resolves your MX records (use the DNS Inspector to check your MX configuration), opens a TCP connection to your SMTP server on port 25, and delivers the message through a series of commands (EHLO, MAIL FROM, RCPT TO, DATA).

SMTP itself is a plaintext protocol dating to RFC 821 (1982). Modern email security relies on layered extensions: STARTTLS (RFC 3207) for opportunistic encryption, MTA-STS (RFC 8461) for enforced TLS, DANE (RFC 7671) for certificate pinning via DNSSEC, and SPF/DKIM/DMARC for sender authentication. After updating any of these DNS records, check DNS propagation to confirm changes have reached all resolvers.

How Does SMTP Delivery Work?

MX Lookup

The sending server queries DNS for MX records to discover which servers accept mail for the recipient's domain (RFC 5321 Section 5).

TCP Connect

Opens a TCP connection to port 25 on the highest-priority MX server. If unreachable, tries lower-priority servers.

STARTTLS

If the server advertises STARTTLS, the connection is upgraded to TLS before any message data is sent (RFC 3207).

Message Transfer

MAIL FROM, RCPT TO, and DATA commands transfer the message. The receiver responds with status codes (2xx success, 5xx permanent failure).

What Is STARTTLS and How Does Transport Encryption Work?

STARTTLS (RFC 3207) upgrades a plaintext SMTP connection to TLS without changing the port. However, standard STARTTLS is opportunistic — if TLS negotiation fails, most servers fall back to plaintext delivery. An active attacker can strip the STARTTLS capability advertisement, forcing email to be delivered unencrypted.

TLS 1.3

Preferred — forward secrecy by default, faster handshake

RFC 8446

TLS 1.2

Acceptable with strong cipher suites (AEAD ciphers)

RFC 5246

TLS 1.0 / 1.1

Deprecated per RFC 8996 — should be disabled

RFC 8996

What Are the Key RFCs for SMTP Security?

RFC 5321(2008)

Simple Mail Transfer Protocol (SMTP)

The core SMTP specification. Defines the protocol commands, MX record handling, delivery rules, and security considerations for email transport.

RFC 3207(2002)

SMTP Service Extension for Secure SMTP over TLS

Defines the STARTTLS extension for upgrading plaintext SMTP connections to TLS. Basis for all opportunistic email encryption.

RFC 8461(2018)

SMTP MTA Strict Transport Security (MTA-STS)

Prevents TLS downgrade attacks by allowing domains to publish a policy requiring TLS for inbound email delivery.

RFC 7671(2015)

DANE for SMTP (TLSA Records)

Uses DNSSEC-signed TLSA records to pin TLS certificates for mail servers, eliminating reliance on certificate authorities.

RFC 8460(2018)

SMTP TLS Reporting (TLSRPT)

Defines a reporting mechanism for sending servers to report TLS delivery failures, complementing MTA-STS and DANE.

RFC 8996(2021)

Deprecating TLS 1.0 and TLS 1.1

Formally deprecates TLS 1.0 and 1.1 due to known cryptographic weaknesses. Servers should support TLS 1.2 minimum.

How Is the Security Grade Calculated?

A+

STARTTLS with TLS 1.3, valid certificate, no open relay, correct PTR, MTA-STS enforce or DANE with DNSSEC

STARTTLS with TLS 1.2+, valid certificate, no open relay, correct PTR

STARTTLS present, minor certificate or PTR issues, no open relay

STARTTLS present but weak TLS version (1.0/1.1) or self-signed certificate

STARTTLS absent or connection failures on some servers

Open relay detected, or no TLS on any reachable server

What Other Email Tools Help With SMTP Security?

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

•MX Lookup — Find mail servers, detect providers, verify reverse DNS per RFC 5321
•SPF Checker — Validate authorized sending servers per RFC 7208
•DKIM Checker — Verify email signing keys per RFC 6376 and key strength per RFC 8301
•DMARC Checker — Analyze email policy and reporting per RFC 7489
•Blacklist Checker — Check if your mail server IP is listed on any DNSBL

Built and maintained alongside this tool. Free, no signup required.

MX record lookupWhere SMTP traffic for this domain should land.Send a test emailFull deliverability check including spam-folder placement.Email header analyzerDecode a real message's path and authentication results.Email blacklist checkIs your sending IP listed on a major DNSBL?