In this article we show you how to connect to a remote server using a Telnet console.
Why Telnet to a mail server?
A Telnet console session can reveal a wide range of useful information about a remote mail server including:
- Mail server software
- Special usage messages (e.g. IP restrictions)
- Diagnostic information about why your emails are not being received (e.g. blacklisting, grey listsing etc)
Where to get a Telnet console application
Telnet consoles are included with most operating systems.
In Windows (Vista & 7), you need to enable (as it is not enabled by default) the Telnet colsole from Control Panel > Programs And Features.
How to Telnet to a SMTP server
As an example (replace “anydomain.com” with a domain of your choice):
- Remote mail server name: mail.anydomain.com
- Remote mail server port: 25 (default SMTP port)
- Remote mail box name: any.user@anydomain.com
- Local machine name: localhost
- Local email address: its.me@localhost
Using Windows, click start, type cmd+enter into the search box. A console window opens.
Type the following sequence of commands (+ return / enter after each line):
telnet mail.anydomain.com 25
helo: localhost
mail from: its.me@localhost.com
rcpt to: any.user@anydomain.com
DATA
Subject:-type subject here-
Now hit return / enter twice
–type the body of your message here–
When you are done with your message, type a . on a line on it’s own.
If everything worked, you should see a message similar to “250 2.0.0 ???????? Message accepted for delivery“.
Tips for doing this effectively
Remote mail servers these days are configured with sophisticated anti-spam services. Therefore, you need to setup your Telnet console from a computer that “looks like” a valid email server. These tips might help:
- Run from a static IP
- If you can, add DNS,PTR and SPF records for your static IP
- Use a “real” host name in the helo: phase that corresponds to the computer that you are running the Telnet session from
- Use a “real” email address in the mail from: phase
The more of these steps you can do, the more likely that your Telnet session will not be seen as possible “spam” by the remote SMTP server.
You can see any problems in the Telnet session with messages like “relaying not permitted” or “Your IP is blocked”. These messages indicate that the remote SMTP server doesn’t “trust” your connection and therefore won’t accept emails or connections from your IP.
Dynamic IP’s are particularly problematic. Many remote servers block direct connections from dynamic IPs as, historically, spammers used home dynamic IP connections for bulk spam mailings.
Debugging the results
As you go through each step, and hit enter/return, the remote SMTP server will give you feedback codes and readable messages. In reading the messages, it’s easy to spot any issues with the remote mail server.
Conclusion
Telnet sessions are a great way to get to the bottom of a wide range of problems with sending emails to remote SMTP servers.
You can use this approach to also debug rare instances where email addresses are not validating correctly. Our email checker service basically is looking for a valid (i.e. code 250) or invalid (i.e. code 55x) in the RCPT TO: phase of a SMTP session.
