How to Test an Email Address with Telnet or OpenSSL (And Why It Does Not Scale)

You can ask a mail server whether it would accept an address, without sending anything, by typing four SMTP commands: EHLO, MAIL FROM, RCPT TO and QUIT. The commands come from RFC 5321, the SMTP standard, which we read for this post on 9 November 2026. Section 3.3 says a mail transaction has three steps: MAIL, one or more RCPT, then DATA. This test does the first two and then quits, so DATA is never sent and no message goes out.

The free SMTP test command generator writes the exact lines for your server, sender and addresses, in either openssl or nc form. Below is the process by hand, what each reply means, and where the method stops being trustworthy.

Generate the test commands →

Step 1: find the receiving server

The address hello@example.net is handled by whatever the MX record for example.net names. Look it up with a DNS tool, such as the bulk MX lookup, and take the host with the lowest preference number, for example mx.example.net. That is the host you connect to. (The names here are examples.) If you are looking for the settings to send through a mailbox rather than the receiving server, that is a different question, answered in finding the SMTP settings for an email address.

Step 2: connect

For a server that upgrades to TLS with STARTTLS, use OpenSSL:

openssl s_client -connect mx.example.net:25 -starttls smtp -crlf

-starttls smtp makes OpenSSL speak the SMTP greeting and the TLS upgrade for you, and -crlf sends proper line endings when you press enter. For a plain, unencrypted connection:

nc mx.example.net 25

If the connection just sits there until it times out, your network or provider is probably blocking outbound port 25. That is common and it is not an error in your commands.

Step 3: type the conversation

After the server's greeting (a line starting 220), type these, one at a time, reading the reply after each:

EHLO sender.example.org
MAIL FROM:<test@sender.example.org>
RCPT TO:<hello@example.net>
RCPT TO:<sales@example.net>
QUIT

• EHLO introduces you. Section 4.1.1.1 says the argument is the fully qualified domain name of the SMTP client, so use a domain you control.
• MAIL FROM names the sender and starts a transaction. The argument is a reverse-path in angle brackets.
• RCPT TO names the recipient. This is the line that matters; you can repeat it for a few addresses.
• QUIT ends the connection. Section 3.8 says a connection is terminated when the client sends QUIT.

Do not type DATA. That is the step that begins the message itself.

Step 4: read the replies

Reply	Meaning
250	The server accepted the command. For RCPT, it accepted the recipient.
550	The recipient is not deliverable. Failures normally produce 550 or 553.
4xx	A temporary failure. Try again later; this is not a verdict on the mailbox.

The words after the number carry the reason, and they vary by server. If you get a message you do not recognise, paste it into the bounce message analyzer. Deferral versus bounce explains why a 4xx is not a rejection.

Where the manual test misleads

A 250 at RCPT TO is a promise about the conversation, not about the person. Four things get in the way:

1. Catch-all domains. Some servers accept every recipient and sort it out later. Every address gets a 250, real or invented. Catch-all scoring describes how a verifier handles these.
2. Delayed bounces. The server says 250 now and the message bounces later from a downstream system.
3. Temporary answers. A 4xx at RCPT is common when a server delays unknown senders, and one attempt cannot resolve it.
4. Defensive servers. Some servers answer everyone the same way to stop probing, or throttle you after a few tries. The reasons a single SMTP answer can be wrong are laid out in why SMTP email verification gets it wrong.

None of these is a flaw in your commands. They are why the test is useful for a handful of addresses and unreliable as a method for a list.

Why it does not scale

Typing RCPT TO is fine for checking whether one prospect's address bounces. For hundreds or thousands it falls apart: you need a clean sending IP, a way to handle temporary failures and retries, a read on catch-all behaviour, and a way not to get blocked for probing. The generator limits you to ten addresses on purpose, with the note that a whole list is what the verifier is for.

A verifier runs the same kind of conversation from its own servers, handles the cases above, and returns valid, risky or invalid with a reason instead of raw codes. Valid rows get sent. Invalid rows get suppressed. Risky rows go out slowly, after the first two groups. Syntax check versus SMTP verification explains where each layer fits.

The routine

1. Use the generator for one or two awkward addresses you want to see answered live.
2. For the list, upload it at /verify.
3. Suppress invalid rows permanently; keep a record so an import cannot add them back. Cold email suppression lists shows a simple way.
4. Send valid rows first, risky rows slowly after.
5. Re-verify old lists before reusing them.

Try it on your own list

Upload a sample at /verify. The first 100 checks are free with a Google sign-in, no card.

Pro, $39 a month: Unlimited email verification.* Never metered, never cut off. See pricing.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.