The SMTP Test That Finds a Domain's Mail Server.

An SMTP test checks whether a domain’s mail server is reachable and willing to receive email. It resolves the domain to the server that handles its mail, opens an SMTP connection, and reads how the server replies to the opening handshake. Type a domain into the tool above and Verifox runs a live lookup of its mail servers, names the host that receives the domain’s email, and shows whether mail has somewhere to land.

It is the fastest way to answer one question that bounces and silent drops hinge on: if I send mail to this domain, is there a live server on the other end ready to accept it? That is the exact SMTP step our verification engine runs after it resolves the MX records.

When one mail server delivers to another, they hold a short conversation in the Simple Mail Transfer Protocol. The sender connects, the receiver answers with a 220 greeting, the sender says EHLO, and they negotiate encryption and the envelope (MAIL FROM and RCPT TO) before any message body is sent.

An SMTP test exercises the front of that exchange. A healthy server answers the connection and greeting promptly; one that times out, refuses, or returns an error never gets to accept your mail. That handshake is also where mailbox-level verification begins, which is why the test doubles as a deliverability check.

The simplest way is to paste the domain into the SMTP test above and read the result. No account, no install. Verifox runs a live lookup of the mail server behind the domain and shows the host that would answer the SMTP connection.

You can also test from a terminal with openssl s_client -connect mail.example.com:25 -starttls smtp or an old-school telnet mail.example.com 25, but those make you read raw protocol replies yourself. The Verifox test names the mail provider in plain English and flows straight into a real mailbox verification when you need to go past the handshake.

Three things. First, whether mail is accepted at all, a live server that answers the handshake can receive email; a dead one means every message bounces. Second, which server and provider handle the mail, whether the domain runs on Google Workspace, Microsoft 365, or a self-hosted server; the mail domain lookup goes deeper on ownership. Third, a baseline deliverability signal.

What it cannot prove by itself is that one specific address exists, because many servers accept every recipient at the handshake and reject unknown mailboxes only later. To confirm a single address is reachable, the mailbox itself has to be checked, the step the test alone cannot finish.

Server-to-server mail delivery uses port 25, which is the port an SMTP test for inbound mail cares about, it is where another mail server connects to hand off a message. Submission from a mail client uses port 587 (with STARTTLS) or the older port 465 (implicit TLS).

The test above cares about the delivery path, the same path real mail takes to the domain’s receiving server. If you are configuring a mail client and need the submission host and port, the mail client server settings lookup pulls the documented IMAP, POP, and SMTP settings, and the MX lookup identifies the provider behind the domain.

A failed SMTP test usually means one of a few things: the domain publishes no mail server (no MX record), so nothing is listening; the server is down or refusing connections; a firewall is blocking port 25; or the domain does not resolve (a typo, expired registration, or DNS misconfiguration). In every case, mail to that domain bounces or stalls.

If you are chasing bounces, an SMTP test is the first place to look. Then a mail exchanger lookup confirms the routing, checking SPF, DKIM, and DMARC covers the authentication side that decides inbox versus spam, and a full email deliverability test rolls every signal into one report.

Yes. The single test above is free with no account. For a list of domains, the REST API resolves the mail server and reports the SMTP response for each one, so you can run a bulk SMTP test across a whole list programmatically and feed the results into your CRM or onboarding flow.

Bulk checks run on the same pay-as-you-go credits as the rest of the platform, localized to your region, and those credits never expire. One credit covers a single domain check.

No, and the difference matters. An SMTP test on the server checks the domain’s mail server, is it alive and accepting connections. Verifying an email checks the specific mailbox, does [email protected] actually exist and accept mail.

A domain can have a perfectly healthy SMTP server while a given address on it is dead, and some servers accept every recipient at the handshake and bounce unknown ones only afterward. That is why an SMTP test is step one of deliverability and the free email checker is step two. Verifox runs both on the same engine.

No. The domain you enter is resolved in memory and discarded the moment the test completes. Nothing logged, nothing retained, nothing sold. A mail server’s response is public, queryable data, but your tests are still yours.

Verifox is SOC 2 Type II compliant and GDPR ready. The full breakdown of what we touch and what we do not is in the privacy policy.

Yes. The REST API reference documents an endpoint that resolves a domain’s mail server and returns its SMTP response, so you can wire mail-server checks into your CRM, your signup flow, or any tool that speaks REST.

Verifox also ships native MCP server support, so AI agents (Claude, Cursor, custom LLM apps) can test a domain’s SMTP server and verify addresses without glue code. Live uptime and incident history are at status.verifox.ai.