Telnet Port (Port 23): What It Is and How to Use Telnet to Test Ports

If you have ever tried to figure out why a website will not load or an email server refuses to send, someone probably told you to “just telnet to the port.” That advice is sound — but it comes with a large asterisk. The Telnet port is 23/TCP, and Telnet itself is one of the oldest protocols on the internet. It was built to let you log in to a remote machine and type commands as if you were sitting at its keyboard. In 2026, almost nobody should use Telnet for that original purpose, yet the `telnet` command remains one of the fastest ways to answer a single, crucial question: *is this port reachable or not?*

Table of Contents

This article explains what Telnet is, why port 23 has been effectively retired for remote access, and how to put the surviving `telnet` command to work as a connectivity tester for web, mail, and SSH services.

Key Takeaways
• The default Telnet port is 23/TCP, the port the Telnet protocol listens on for remote terminal sessions.
• Telnet is obsolete for remote login because it transmits everything — usernames, passwords, commands — in cleartext. SSH replaced it.
• The `telnet` command is still genuinely useful for one job: testing whether a TCP port is open and reachable, using `telnet host port`.
• A successful connection means the port is open; a refusal or timeout means it is closed, blocked, or filtered.
• Modern equivalents — `nc` (netcat), `nmap`, and PowerShell’s `Test-NetConnection` — do the same diagnostic job more flexibly.

What is Telnet and what is the Telnet port?

Telnet (Telecommunication Network) is a protocol and command-line tool for remote terminal access over a TCP/IP network. It dates back to 1969 and was standardized in RFC 854. The idea was simple and, for its era, revolutionary: you run a Telnet client on your machine, connect to a Telnet server running on a remote host, and from then on your keystrokes are sent across the network and the remote machine’s output is sent back. You get an interactive shell on a computer that might be in another building or another country.

The default Telnet port is 23/TCP. When you start a Telnet session without specifying a port, the client assumes you mean port 23, because that is the well-known port the Internet Assigned Numbers Authority (IANA) reserves for the Telnet protocol. A Telnet *server* (the daemon, often `telnetd`) listens on port 23 and waits for clients to connect.

For decades, this was how administrators managed servers, routers, switches, and mainframes. If you needed to reconfigure a device, you opened a Telnet session to port 23 and started typing.

Why is Telnet obsolete and unsafe for remote login?

Here is the problem that ended Telnet’s career as a login tool: Telnet sends everything in cleartext. There is no encryption anywhere in the protocol. Every character you type — including your username and password — travels across the network as plain, readable text.

That means anyone positioned between you and the server can capture your credentials with a basic packet sniffer. On a shared network, a compromised router, or any untrusted hop along the path, your login is exposed. In modern security terms, this is an unacceptable hole. Passwords in cleartext are roughly the worst-case scenario for authentication.

This is exactly why SSH (Secure Shell) replaced Telnet for remote login. SSH does the same fundamental job — remote terminal access — but encrypts the entire session, authenticates the server, and supports key-based logins. SSH runs on port 22 instead of port 23. If you are managing a server today, you connect over SSH, full stop. For more on the secure replacement, see how SSH handles encrypted remote access.

The takeaway is blunt: never use Telnet to log in to a real server. If you find a device still offering Telnet on port 23 for management, treat it as a misconfiguration to fix, not a convenience to use.

What is the one thing Telnet is still useful for?

Despite being retired as a login protocol, the `telnet` command earns its keep doing something its designers never emphasized: testing whether a TCP port is open and reachable.

When you run `telnet host port`, the client tries to open a raw TCP connection to that host on that port. It does not matter whether the service behind the port actually speaks Telnet. All you are asking is a connectivity question: *can a TCP connection be established to this port, or not?*

The basic syntax is:

“` telnet host port “`

For example, to test whether a web server is accepting connections on the standard HTTP port:

“` telnet example.com 80 “`

To test whether a mail server is reachable on the SMTP port:

“` telnet mail.example.com 25 “`

In both cases you are not logging in. You are probing a door to see if it opens. This single behavior is why `telnet` survives on troubleshooting cheat sheets long after the protocol itself fell out of favor.

Telnet has undergone a complete identity change that confuses people. It was *born* as a remote-login protocol — the way you controlled a server before SSH existed — but it is now effectively *dead* for that purpose, because it transmits passwords and data in plain text. Yet the command survives and stays genuinely useful for a totally different job: as a quick, universal port-connectivity tester. When you run `telnet host 25`, you are not logging in — you are asking, “can I even open a TCP connection to that port?” A successful connect proves the port is open and reachable through firewalls; a refusal or timeout pinpoints where the path is blocked. So in 2026, “telnet” should mean “test if a port is reachable,” never “remotely log in.” For login you use SSH, and for the rare times Telnet still earns its keep, it is as a diagnostic, not a doorway. (Even better, learn `nc`/netcat or `Test-NetConnection` as the modern equivalents.)

How do you read the result of a telnet port test?

The value of `telnet host port` is in interpreting what happens after you press Enter. There are three common outcomes, and each tells you something specific about the network path.

Connection succeeds. If you see something like `Connected to example.com` followed by `Escape character is ‘^]’`, the TCP handshake completed. The port is open and reachable — the service is listening, and nothing along the path (firewall, security group, ISP) is blocking it. A blank screen with a flashing cursor is also a successful connect; the service is simply waiting for you to speak its protocol.

Connection refused. A message like `Connection refused` means the host is reachable, but nothing is listening on that port — or a firewall is actively rejecting the connection. The packet got to the destination and was turned away. This usually means the service is down, not started, or bound to a different port.

Connection times out. If the command hangs and eventually reports a timeout, the connection attempt never got a response at all. The port is filtered or blocked — typically by a firewall that silently drops packets, or the host is unreachable. A timeout points to something between you and the destination eating the traffic.

Here is how those signals map out:

Telnet result	What it means	Likely cause
`Connected to…` / blank cursor	Port is open and reachable	Service is up and listening
`Connection refused`	Host reachable, port closed	Service down or firewall rejecting
Connection hangs, then times out	Port filtered / blocked	Firewall dropping packets, host unreachable
`Could not resolve hostname`	DNS problem, not a port problem	Bad hostname or DNS misconfiguration

That last row matters: if Telnet cannot even resolve the hostname, your problem is name resolution, not connectivity. Understanding how those layers fit together is the heart of networking and DNS for hosting, which covers the full path from a visitor’s browser to your server.

How do you use Telnet to test web, mail, and SSH ports?

In day-to-day troubleshooting, a handful of ports come up constantly. Telnet gives you a fast way to confirm each one is reachable before you dig deeper.

Testing a web server (port 80 / 443). To confirm a site is accepting HTTP connections:

“` telnet example.com 80 “`

If it connects, you can even type a raw request — `GET / HTTP/1.0` followed by two Enters — and watch the server respond. Note that plain Telnet cannot test HTTPS on port 443 meaningfully, because port 443 expects an encrypted TLS handshake that Telnet cannot perform; it can only tell you the port is open.

Testing a mail server (port 25 / 587). Mail problems are a classic Telnet use case:

“` telnet mail.example.com 25 “`

A reachable SMTP server typically greets you with a `220` banner. Testing the submission port works the same way:

“` telnet mail.example.com 587 “`

If port 25 times out, your provider or ISP may be blocking outbound SMTP — a very common cause of mail-sending failures.

Testing SSH (port 22). You can confirm an SSH service is listening without actually logging in:

“` telnet example.com 22 “`

A reachable SSH server responds with a version banner like `SSH-2.0-OpenSSH_9.x`. This proves the port is open — but remember, you test SSH reachability with Telnet, then you *connect* with the SSH client, never with Telnet. For a broader view of which services live on which ports, see the guide to common network ports.

Here is a quick reference of where Telnet still helps versus where it does not:

Telnet use	Status
Remote login to a server (port 23)	Obsolete — use SSH instead
Testing if web port 80 is open	Useful — quick connectivity check
Testing if SMTP port 25/587 is reachable	Useful — diagnose mail issues
Confirming SSH port 22 is listening	Useful — check reachability only
Testing HTTPS (443) content	Limited — port-open check only, no TLS
Sending real passwords/data	Never — cleartext, fully exposed

What are the modern alternatives to Telnet for port testing?

Telnet is convenient because it is universally recognized, but it is no longer the best tool for port testing. Several modern utilities do the same job with more precision and better defaults.

netcat (`nc`). The Swiss Army knife of networking. To test a port: `nc -vz example.com 80`. The `-z` flag does a scan without sending data, and `-v` makes it verbose. It is scriptable and far more flexible than Telnet.

nmap. A full port scanner. `nmap -p 25,80,443 example.com` checks multiple ports at once and reports their state (open, closed, filtered) explicitly — exactly the distinctions you have to infer manually with Telnet.

PowerShell `Test-NetConnection`. On Windows, this is the native, recommended tool:

“` Test-NetConnection example.com -Port 80 “`

It returns a clear `TcpTestSucceeded : True` or `False`, along with latency and route details. There is also a community `Test-Port` function for batch testing. These tools make the open/closed/filtered determination explicit, removing the guesswork of reading Telnet’s behavior. To go deeper on systematic port auditing, see how to check open ports on a server.

How do you enable the Telnet client?

One practical wrinkle: the Telnet client is often not installed by default anymore, precisely because the protocol is considered insecure. You may need to enable it.

Windows: Run `dism /online /Enable-Feature /FeatureName:TelnetClient` in an elevated prompt, or enable “Telnet Client” under *Turn Windows features on or off*.
macOS: Telnet was removed from recent versions; install it via Homebrew with `brew install telnet`, or simply use `nc` instead, which ships by default.
Linux: Install via your package manager, e.g. `apt install telnet` or `dnf install telnet`.

If installing Telnet feels like a chore, take it as a signal: the modern tools above are usually already present and are the better long-term habit.

DarazHost gives you the networking visibility to keep services reachable. On VPS and dedicated plans with full root access, you get complete control over which ports are open and the right tools — `ss`, `nc`, `nmap` — to test connectivity properly. You also get secure SSH access instead of insecure Telnet, reliable networking, and 24/7 support to help you diagnose any port or connection issue, from a refused SMTP handshake to a filtered firewall rule. Whether you are launching a single site or running production services, DarazHost makes sure the path from your visitors to your server stays open and observable.

Frequently asked questions

What port does Telnet use by default? Telnet uses port 23/TCP by default. When you run `telnet host` without specifying a port, the client connects to port 23, the well-known port IANA reserves for the Telnet protocol. You can override this by adding a port number: `telnet host 80`.

Is Telnet still safe to use? Telnet is not safe for transmitting any sensitive data or for remote login, because it sends everything — including passwords — in cleartext. It is safe to use only as a read-only connectivity test (`telnet host port`) where you are not sending credentials. For remote login, always use SSH.

Why use SSH instead of Telnet? SSH encrypts the entire session, authenticates the server, and supports key-based logins, while Telnet sends data in plain text. SSH runs on port 22 and provides the same remote terminal access Telnet offered, but securely. There is no reason to use Telnet for login when SSH is available.

How do I know if a port is open with Telnet? Run `telnet host port`. If you see `Connected to…` or a blank cursor, the port is open and reachable. `Connection refused` means the port is closed, and a timeout means it is filtered or blocked by a firewall.

What can I use instead of Telnet to test ports? Use `nc -vz host port` (netcat), `nmap -p port host`, or on Windows `Test-NetConnection host -Port number`. These tools report a port’s state (open, closed, filtered) explicitly, which is clearer than interpreting Telnet’s connection behavior.