Believe it or not, Telnet, while old-school, is still a fast, reliable tool for fixing email issues.

Newer tools may be easier to use, but Telnet gives you direct access to what’s really happening on the server. It’s built into most operating systems, requires no extra setup, and can be a lifesaver when troubleshooting. On older Windows Server versions like 2008 or 2012, you’ll just need to install the Telnet client manually.

Why Is This Useful?

The Telnet command is a practical way to test and troubleshoot email server connectivity and functionality.

It lets you to interact directly with an email server (e.g., SMTP, IMAP, or POP3) by establishing a raw TCP connection, typically on ports 25 (SMTP), 110 (POP3), or 143 (IMAP).

Whether you’re dealing with message delivery issues, email authentication failures, or preparing for an MX record cutover, Telnet provides a real-time view of the process. It’s especially helpful when working with systems like Microsoft 365, or Proofpoint Essentials.

What You Can Do with Telnet:

• Test Server Connectivity: You can verify if an email server is reachable and responding on the expected port, helping diagnose network or firewall issues.
• Verify Server Functionality: By issuing protocol-specific commands (e.g., HELO, EHLO, or MAIL FROM for SMTP), you can check if the server is processing requests correctly.
• Debug Delivery and Email Authentication Issues: Telnet lets you simulate email client interactions to identify problems like authentication failures, misconfigured servers, or rejected messages without needing an email client.
• Understand Email Protocols: It provides a hands-on way to understand how SMTP, IMAP, or POP3 protocols work by manually sending commands and observing server responses.
• Confirm Mail Flow Before Go-Live – For example, with Proofpoint Essentials, a new domain or user may take up to an hour before accepting mail. Telnet lets you confirm readiness before cutting over the MX record.
• Simulate Impersonation Attempts – Check if your email protection filters are catching unauthorized sender spoofing.

Example: SMTP Transaction Using Telnet

Here’s a step-by-step example of how to send an email using Telnet.

Step 1 – Open a Telnet Session

From a Linux terminal (or any system with Telnet enabled), run:

Step 2 – Start the SMTP Handshake

You begin the session by identifying yourself with:

 EHLO <yourdomain.com> command (In this case Vircom.com)

What You’ll See:

• The mail server responded with 250 OK and other server capabilities.
• The server responded with capabilities it supports such as allowing messages up to 512KB,

encrypted connections (STARTTLS), and authenticated SMTP logins.

These responses help you confirm that the server supports email authentication and secure connections.

Step 3 – Define the Email Envelope and Content

Next, you can enter the “mail-from” and the “rcpt-to” commands – these are often referred to as the “envelope” of the email. 

The server will return 250 OK if the recipient exists.

If the recipient address (e.g., yves@cheznousse.com) doesn’t exist, the server would typically return an error like ‘550 no such user here’ instead of 250 OK.

Next, type the DATA command to start composing the actual email content.

• The DATA command signals the start of the email’s header and body. First, the Subject, From, and To headers are entered.
• This is followed by a blank line to separate the headers from the body.
• The rest of the message is the email body, which ends with a single period (.) on its own line.

What You’ll See:

• The server responds with a 250 OK, confirming that the message was received successfully.
• It also assigns a message ID, showing the message has been accepted for delivery.

Test for Impersonation or Spoofing using Telnet:

In this example, the From header was set to yves@cheznousse.com instead of the actual sender yves@vircom.com, simulating an impersonation attempt.

If the server has protections like Proofpoint Essentials in place, it may block impersonation attempts and flag the message as phishing or spoofing.

Here’s what Proofpoint would’ve said on the receiving end if I connected to Proofpoint instead of directly to the mail server:

First the Telnet session:

… and Proofpoint’s diagnostic:

You can see Proofpoint clearly reporting and blocking the message due to spoofing behavior.

Telnet remains a powerful tool for troubleshooting mail flow, testing defenses, and understanding core components of your email infrastructure.  It’s especially valuable when investigating email authentication, spoofing, or email delivery issues in environments using Office 365, Proofpoint Essentials, or OnDMARC.