📧 SMTP Tester

Look up a domain's mail servers, then get ready-to-run connection test commands for ports 25, 587 and 465 — the exact commands you need since browsers can't open a live SMTP connection themselves.

✍️ Author: ToolsNovaHub Editorial Team • ✅ Reviewed by: ToolsNovaHub Security & Network Team • 📅 Last Updated: 16 August 2026
Enter a domain to look up its MX mail servers, or a specific mail server hostname to generate commands directly.

Why This Tool Doesn't (and Can't) Show a Live Connection Result

It's worth being upfront about this rather than pretending otherwise: every modern web browser maintains a list of "restricted ports" that JavaScript running on any web page — including this one — is simply not allowed to connect to, and every standard mail port is on that list. Ports 25, 465, 587, 110, 143, 993 and 995 are all blocked at the browser level specifically because unrestricted access to mail ports from arbitrary web pages would make browsers a convenient tool for spam relay and mail server probing. This isn't a limitation specific to this tool or this site — no browser-based tool, from any vendor, can open a genuine SMTP connection from client-side JavaScript, full stop.

What this tool does instead is the next most useful thing: it looks up your domain's actual MX records via DNS (a query type browsers are allowed to make), and generates the precise, correct command for the operating system and tool you actually have available, so you can run a real, live connection test yourself in a matter of seconds. This is also simply a more honest approach than tools that quietly fake a "connection successful" result using an unrelated technique that doesn't actually test SMTP at all, and it's an approach consistent with how the rest of this site handles diagnostics that genuinely can't be performed safely from inside a browser sandbox.

⭐
ToolsNovaHub Pro Tip
Test from the same network your mail server actually sends from, not from your laptop on a different connection. Outbound port 25 blocking is applied per-network, so a successful test from home tells you nothing about whether your production mail server can actually connect.
⚠️
Common Beginner Mistake
Assuming a domain has no mail server just because a browser-based check 'failed.' A browser can't test SMTP ports at all — a real failure only means something once you've run one of the generated commands yourself from an actual terminal.

Understanding the Three Main SMTP Ports

PortNameEncryption ModelTypical Use
25SMTPPlain text, optionally upgraded via STARTTLSServer-to-server mail relay; frequently blocked outbound by ISPs and cloud providers
587SubmissionPlain connection, upgraded via STARTTLSAuthenticated client sending mail through a provider
465SMTPSImplicit TLS from the first byteAuthenticated client sending mail, older standard now back in common use

A server can legitimately listen on all three, some, or just one — there's no universal rule, and a domain that only accepts port 587 for client submission while blocking direct port 25 access from arbitrary hosts (a common, deliberate anti-abuse configuration) is behaving correctly, not incorrectly.

How MX Lookup Fits Into SMTP Testing

Before testing any connection, you need to know which host to actually test against, and that's exactly what an MX (Mail Exchange) DNS record tells you — it maps a domain to the hostname(s) responsible for accepting mail on its behalf, each with a priority number where lower numbers are tried first. This tool queries MX records automatically when you enter a domain, sorts them by priority, and lets you generate test commands against whichever mail server you want to check, without you needing to separately run a DNS lookup first. If a domain has no MX record at all, some mail systems fall back to the domain's own A record as an implicit mail server, though this is increasingly rare and generally considered a misconfiguration for anything beyond very small, informal setups.

Reading the Generated Commands

ToolPlatformBest For
telnetmacOS, Linux (may need separate install)Quick plain-text SMTP conversation testing on port 25 or STARTTLS-capable port 587
openssl s_clientmacOS, Linux, Windows (with OpenSSL installed)Testing TLS-wrapped connections directly, including port 465 and STARTTLS on 587/25
Test-NetConnectionWindows PowerShellQuick reachability check without needing to interpret SMTP protocol responses
swaksmacOS, Linux (separate install)Full authenticated send tests including STARTTLS negotiation and login, closest to a real mail client

Interpreting Common Results

What You SeeWhat It Means
A 220 greeting line appears immediately after connectingThe server is reachable and SMTP service is running correctly — this is the expected healthy response
Connection hangs with no output at allLikely a firewall silently dropping packets (a timeout scenario), rather than the server actively refusing
"Connection refused" appears immediatelyNothing is listening on that port at that host, or a firewall is actively rejecting rather than silently dropping
Connects but disconnects after a few seconds with no dataPossible greeting delay/tarpit anti-spam technique, or an IP reputation-based rejection happening before the banner is sent
TLS handshake fails specifically on port 465Server may not support implicit TLS on that port, or an outdated TLS version is being negotiated — check server-side TLS configuration

Step-by-Step: Diagnosing a Failed SMTP Connection

Start by confirming the MX record itself resolves to the host you expect — a surprising number of "the mail server won't connect" reports turn out to be an MX record pointing at a stale or incorrect hostname, catchable in seconds with the lookup this tool performs automatically. Next, generate and run the test-connection command for the specific port you're troubleshooting rather than assuming a general internet connectivity problem, since port-specific blocking is extremely common and a working port 587 alongside a blocked port 25 is normal, not broken. If the connection times out rather than being actively refused, suspect a firewall along the path silently dropping the traffic — check both the destination server's own firewall and any network-level blocking upstream (your ISP, cloud provider, or corporate network). If the connection succeeds but the server closes it unexpectedly, check the mail server's own logs directly, since the reason (rate limiting, IP reputation, missing authentication) is almost always visible there even when invisible from the client side.

Common Real-World Scenarios

ScenarioLikely Explanation
Port 25 blocked, port 587 works fineExpected — most consumer ISPs and many cloud platforms block outbound 25 by default while leaving 587 open for legitimate submission
Works from office network, fails from homeDifferent networks apply different outbound port policies; this is a network-level difference, not a server problem
Worked yesterday, fails today with no changes madeCheck for IP reputation/blacklist changes, a recent firewall rule update, or the mail provider's own service status
Connects on 465 but authentication fails afterwardConnection-level success confirms network reachability; authentication failure is a separate, application-layer issue unrelated to the port test itself

Pros and Cons of Command-Line SMTP Testing

✅ Pros
  • Genuine, real-time result — not a simulation or heuristic guess
  • Reveals the actual protocol conversation, not just a pass/fail
  • Works identically regardless of which website generated the command
  • No dependency on any third-party service continuing to work
❌ Cons
  • Requires terminal access and comfort with command-line tools
  • Results depend entirely on the network you're testing from
  • Some tools (swaks, openssl) may need separate installation
  • Doesn't test message delivery, only connection-level reachability

Security Considerations

Running an SMTP connection test against a mail server you don't operate should be limited to standard, non-intrusive diagnostic queries — checking connectivity and reading the greeting banner is generally considered acceptable diagnostic behavior, the same as a basic ping or traceroute, but repeated automated probing, authentication brute-forcing, or attempting to relay mail through a server you don't have permission to use crosses into behavior that can trigger abuse detection or worse. Treat any mail server you're testing that isn't your own the same way you'd treat any other system you don't administer — read-only, minimal, and respectful of what a reasonable network operator would consider a legitimate diagnostic check.

Reading an Actual SMTP Conversation

Once you run one of the generated commands and get a live response, it helps to know roughly what a healthy conversation looks like so you can tell a working server apart from one that's merely reachable but broken. A successful plain connection on port 25 typically starts with a line like 220 mail.example.com ESMTP ready the instant the TCP connection completes — that 220 code is the server announcing itself and inviting a conversation. From there, issuing EHLO yourhost should return a list of supported extensions (STARTTLS, AUTH mechanisms, size limits) prefixed with 250. If STARTTLS is offered and you issue it, a properly negotiating server upgrades the connection to TLS silently from that point forward. Seeing the 220 banner alone, even without going further, already confirms the most important fact: the server process is running and listening, which is often the entire question a connectivity test is trying to answer.

Why the Generated Commands Differ by Platform

macOS and most Linux distributions ship with core networking utilities that make ad hoc protocol testing straightforward, though telnet specifically has been removed from newer macOS versions by default and may need a quick install via a package manager. Windows doesn't traditionally include telnet enabled by default either, which is why the PowerShell-based Test-NetConnection command is offered as the more broadly available option there — it doesn't show you the actual SMTP conversation, but it reliably confirms whether the TCP port itself is open and reachable, which is frequently the exact question being asked. For anyone wanting the fullest picture regardless of platform, installing openssl (widely available as a standalone binary or through common package managers on all three major operating systems) gives the most consistent, capable testing experience across the board.

Expert Tips for More Reliable Testing

💡
Test From Multiple Locations
A single successful or failed test from one network tells you about that network's specific path, not a universal truth about the mail server. Test from at least two genuinely different networks before drawing firm conclusions.
💡
Always Test the Actual Sending Server
If you're troubleshooting a production mail issue, test connectivity from the actual server or service that will be sending mail, not just your personal laptop, since outbound rules commonly differ significantly between the two.
💡
Note the Exact Error Text, Not Just 'It Failed'
"Connection refused" and "Connection timed out" point to different root causes entirely. Copy the exact wording from your terminal before searching for a fix or asking for help.
💡
Re-Check MX Records After Any DNS Change
A DNS provider migration or a typo during a routine update can silently point MX records at the wrong host — re-run the lookup after any DNS change, not just when something visibly breaks.

SMTP Testing in a Broader Email Deliverability Workflow

Connection-level testing is genuinely just the first, most basic layer of a much larger deliverability picture, and it's worth being clear about where it fits so expectations stay realistic. A passing connection test confirms the network path and the mail service itself are working — nothing more. It says nothing about whether SPF, DKIM and DMARC are correctly configured for the sending domain, nothing about the sending IP's reputation with major mailbox providers, and nothing about whether content-based spam filtering will flag a specific message. Teams troubleshooting "my email isn't arriving" issues should treat a successful SMTP connection test as ruling out one specific class of problem (network/server reachability) while still needing to separately verify authentication records with tools like SPF Lookup, DKIM Lookup and DMARC Lookup, since a perfectly reachable server can still fail to deliver mail for entirely separate reasons that a connection test was never designed to catch in the first place.

Real-World Use Cases

🛠️
New Server Setup Verification
Confirming a freshly configured mail server actually accepts connections on the expected ports before pointing production DNS at it, catching misconfigurations before they affect real mail flow.
🚫
Diagnosing Blocked Outbound Mail
Confirming whether a cloud server's outbound port 25 is blocked by the hosting provider — a frequent, easily misdiagnosed cause of "my application can't send email" reports.
🔐
Firewall Change Validation
After a firewall rule update, quickly confirming the intended mail ports are still reachable from the expected sources without waiting for a real message to fail first.
📋
Migration Pre-Flight Checks
Before cutting DNS over to a new mail provider or server during a migration, confirming the new destination actually answers correctly on every port the old one did.

When the MX Lookup Itself Returns Nothing

Occasionally the lookup step itself comes back empty, which is a distinct problem from a connection test failing and deserves its own quick diagnosis. No MX records at all typically means either the domain genuinely has no mail configured (common for domains used purely for web hosting with no associated email), or a very recent DNS change hasn't propagated yet. Before assuming a connectivity problem downstream, confirm the domain actually has MX records published at all using this tool's lookup step, since testing connection commands against a host that was never actually configured as a mail server will understandably fail regardless of network conditions, and the fix there is publishing correct MX records rather than chasing a network issue that doesn't exist.

Related Reading

For a deep dive on the authentication step that happens after a successful connection, see SMTP Authentication. For a full breakdown of every port and when to use which, read SMTP Ports Explained. For the TLS/SSL distinction referenced throughout this page, see SMTP TLS vs SSL. For relay-specific configuration and errors, read SMTP Relay. If your connection is failing and you need a broader systematic troubleshooting process, see SMTP Troubleshooting and SMTP Connection Errors.

🔗 Related Tools

📧
MX Lookup
Check mail exchange records, priority & TTL
🔒
DKIM Lookup
Check DKIM selector & public key
🛡️
DMARC Lookup
Check any domain's live DMARC record & policy
🔔
Open Port Checker
Test if a forwarded port is reachable

Frequently Asked Questions

Web browsers explicitly block JavaScript from opening connections to standard mail ports — 25, 465, 587, 110, 143, 993 and 995 are all on the browser's restricted port list specifically to prevent websites from being used to send spam or probe mail servers silently. This tool instead looks up your mail servers via DNS and generates the exact command to run yourself, which gives a real, live result a browser fundamentally cannot.
Port 25 is for server-to-server mail relay and is the one most residential and cloud ISPs block outbound. Port 587 (submission) is the modern standard for an authenticated client sending mail through STARTTLS. Port 465 is the older implicit-TLS submission port, once deprecated and now back in common use alongside 587.
Outbound port 25 is one of the most heavily abused ports for sending spam from compromised machines, so most residential ISPs and cloud platforms (AWS, Google Cloud, Azure, DigitalOcean and others) block it by default on new accounts specifically to reduce abuse, requiring an explicit request or a different port to send mail.
It means the target host actively rejected the TCP connection attempt at that port — either nothing is listening there, a firewall is explicitly rejecting it, or the service was recently stopped. This is different from a timeout, which usually means the packet was silently dropped rather than rejected.
The connection attempt never received any response at all within the wait period — most commonly caused by a firewall silently dropping the packets rather than rejecting them, or the host being genuinely unreachable at the network level.
Look up your domain's MX records first (this tool does that automatically), confirm they point to a hostname that resolves to a real, reachable mail server, and confirm that server actually answers on port 25 for incoming mail — a common misconfiguration is an MX record pointing to a host with no mail service running at all.
STARTTLS is a command that upgrades an initially plain-text SMTP connection to an encrypted one mid-session, used by ports 25 and 587. Port 465 instead starts encrypted immediately (implicit TLS). Testing needs to account for which mode a given port expects, or the test will fail even though the server is working correctly.
Yes for read-only diagnostic purposes like MX lookup and generating standard connectivity test commands, since MX records are public DNS information by design — the same courtesy and legal considerations that apply to any network diagnostic tool apply here regarding what you do with the generated commands.
Telnet is a plain-text protocol and cannot perform the TLS handshake port 465 expects immediately upon connection, so it will either fail outright or connect but show garbled output. Use openssl s_client with the -connect flag for port 465 instead, since it can handle the TLS handshake.
Yes, significantly — outbound port blocking, firewall rules and NAT configurations are often different for a residential or office connection versus a data center server, so a successful test from your laptop doesn't guarantee your actual mail server (often hosted elsewhere) will succeed, and vice versa.
Most command-line tools default to a reasonable value (often 10-30 seconds), which is generally sufficient — if a legitimate SMTP server is going to respond, it typically does so within a few seconds; anything approaching the full timeout usually indicates a network-level problem rather than a genuinely slow server.
No. MX lookups run as live DNS queries directly from your browser to a public resolver, and command generation happens entirely client-side — we don't log or store what you check.
Yes, this is common and often deliberate — many networks block port 25 specifically (to prevent spam relay from internal hosts) while leaving port 587 open (for legitimate authenticated client submission), which is exactly why testing multiple ports individually matters rather than assuming one result applies to all.
This usually indicates the server accepted the TCP connection but then applied its own policy check — a greeting delay tarpit, an IP reputation block, a rate limit, or a requirement for authentication or TLS before proceeding — none of which are visible from the TCP connection alone.
telnet and openssl s_client for direct protocol-level testing on macOS and Linux, PowerShell's Test-NetConnection for Windows, and a swaks command for a fuller authenticated send test where the software is available.
No — a successful connection test only confirms network reachability and that something is listening and responding on that port. Whether a specific message is actually accepted, relayed and delivered depends on authentication, relay permissions, spam filtering, and the recipient server's own policies, none of which a connection test alone reveals, which is why a passing connectivity check should never be treated as proof that mail is actually flowing end to end.
Intermittent results usually point to either a flaky or overloaded network path, a mail server under load or applying rate limiting, or a firewall rule with connection-count limits rather than a hard block — worth retesting a few times and at different intervals before concluding the cause.
Confirm the MX record actually points to the correct host first using this tool's lookup, then confirm the mail service is actually running and listening on the expected port on that host, then work outward through firewall and network-level checks only after those two basics are confirmed — most connection reports trace back to one of these first two steps rather than a deeper network issue.