Skip to content
Website under migration: We are moving to a new design. Some pages may look different or load slowly for a few days. Thank you for your patience.
SwitchFirewall
IPv4 Detecting…
IPv6 Detecting…

How to Send a Test Email Using Telnet and EHLO

Last updated:

Introduction

When something goes wrong with email delivery — messages bounce, get delayed, or never arrive — you often need to test whether your mail server can actually send emails. One of the most reliable and low-level ways to do this is by manually speaking the SMTP language using Telnet.

The EHLO command (Extended Hello) is the modern way email clients/servers introduce themselves. It tells the receiving server what features (like authentication, size limits, or TLS) the sender supports. This guide walks you through sending a complete test email using only Telnet — no extra tools needed.

This method is perfect for quick troubleshooting, learning SMTP, verifying firewall rules, testing new mail servers, or proving delivery problems to hosting providers.

Why Use Telnet + EHLO for Testing?

Telnet sends everything in plain text — never use it with real passwords over untrusted networks. For production testing, prefer tools like OpenSSL or swaks.

Prerequisites

On Windows 10/11, enable Telnet Client: Settings → Apps → Optional features → Add a feature → Telnet Client.

Full Step-by-Step: Sending a Test Email via Telnet + EHLO

We will connect to a public test SMTP server (or your own) and send a simple message.

Step 1: Open Command Prompt

Press Windows + R → type cmd → Enter

Step 2: Connect to the SMTP Server

telnet smtp.gmail.com 587

Common ports: 25 (relay), 587 (submission with STARTTLS), 465 (SSL). Use 587 for most modern servers.

Step 3: Greet the Server with EHLO

EHLO test.yourdomain.com

You should see a list of supported features like:

250-smtp.gmail.com at your service, [your IP]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

Step 4: Start Encrypted Session (if server supports STARTTLS)

STARTTLS

Server replies: 220 2.0.0 Ready to start TLS

After STARTTLS, Telnet becomes encrypted — you won't see what you type anymore. This method stops here for plain Telnet. For encrypted testing, use OpenSSL instead (covered later).

Step 5: For Plain/Text Testing (Port 25, no encryption)

Use port 25 on servers that still allow plain text (many internal/corporate servers do):

telnet mail.yourcompany.local 25
EHLO workstation.yourcompany.local

Step 6: Tell Who Is Sending

MAIL FROM:<user@yourdomain.com>

Server should reply: 250 2.1.0 OK

Step 7: Tell Who Is Receiving

RCPT TO:<test@yourdomain.com>

Reply: 250 2.1.5 OK (or 550 if rejected)

Step 8: Start Composing the Message

DATA

Server replies: 354 Go ahead

Step 9: Type the Email Headers & Body

From: Test User <user@yourdomain.com>
To: Recipient <test@yourdomain.com>
Subject: Manual SMTP Test Email

Hello,

This is a test message sent manually using Telnet and EHLO.
Testing delivery from my workstation.

Best regards,
Your Name
.

Important: End with a single period . on its own line and press Enter.

Step 10: Finish the Session

QUIT

Server replies: 221 2.0.0 Bye

Common SMTP Reply Codes You Will See

250 OK – Everything good

354 Go ahead – Ready for message

550 Mailbox unavailable – Wrong recipient

554 5.7.1 Relay access denied – Server won't relay for you

Usually means you need authentication or the server doesn't allow relaying from your IP.

Troubleshooting Common Problems

Many public providers (Gmail, Office 365) require authentication and STARTTLS on port 587 — plain port 25 is usually blocked or restricted.

Conclusion

Using Telnet with the EHLO command gives you complete visibility into how SMTP really works. While modern tools like swaks, Thunderbird’s test feature, or PowerShell’s Send-MailMessage are more convenient for daily use, understanding the raw SMTP conversation helps you diagnose delivery problems faster and deeper.

Practice this method on your own internal mail server or a test relay first. Once comfortable, you'll be able to quickly verify whether the issue is with your server config, DNS (MX/SPF/DKIM), firewall, or the recipient's side.

Master this skill — it remains one of the most powerful low-level troubleshooting techniques in email administration.