01 · Definition
What is tcp port checker?
A TCP port checker tests whether a specific port is open and accepting connections on a domain or IP address. It attempts a raw TCP handshake without exchanging application-layer data, making it a protocol-agnostic way to confirm whether any service is reachable from the outside world.
The tool above sends a TCP connection attempt to the host and port you specify. It returns a single verdict: success (the port is open and the handshake completed) or fail (the connection was refused, timed out, or blocked). Read the in-depth TCP port checker guide for when to use TCP checks versus higher-level tests, and how to interpret common failure patterns.
02 · Process
How it works
- 1Enter the host and port.Type the domain name or IP address and port number in
host:portformat — for examplesmtp.example.com:587or203.0.113.1:443. - 2DNS resolution.If you provided a domain name, it is resolved to an IP address. If resolution fails, the TCP check cannot proceed.
- 3TCP handshake attempt.The tool tries to open a TCP connection to the resolved IP on the specified port. This is equivalent to running
telnet host portornc -zv host portfrom a terminal. - 4Return the verdict.If the three-way handshake completes, the port is open. If the connection is refused, dropped, or times out, the port is closed or unreachable.
03 · Risk
Why it matters
Most connectivity tests bundle TCP with higher-level protocol negotiation. When they fail, it is not always clear whether the port itself is blocked or whether the service on that port has a configuration error. A raw TCP check isolates the transport layer and answers the simplest question first: can traffic even reach this port?
For email senders, blocked outbound SMTP ports are among the most common delivery problems. Port 25 is blocked by most residential and cloud ISPs to prevent spam. Port 587 (submission with STARTTLS) and port 465 (implicit TLS) are the standard alternatives. Checking which ports are actually open is the first step in diagnosing any "couldn't connect to mail server" error.
04 · Use cases
Common ways to use this tool
- SMTP port availability. Before configuring an email client or ESP integration, confirm port 25, 587, or 465 is reachable from your sending network to the mail server.
- Firewall rule verification. After adding a rule to open a port, use a TCP check to confirm the change took effect without needing to deploy or restart a service.
- Service reachability. Verify a database port (3306, 5432), API port (8080, 443), or any other service is accessible from an external vantage point before assuming the application is at fault.
- Network block diagnosis. Determine whether a port is blocked at the network perimeter rather than at the application level, by testing from an external IP.
05 · Interpretation
What to check in the result
- Fail on port 25. Port 25 is blocked by most residential and cloud providers to prevent spam relaying. Use port 587 (STARTTLS) or 465 (implicit TLS) for authenticated SMTP submission.
- Fail on a port that should be open. Check host firewall rules, cloud security group settings, and load-balancer listener configuration. A TCP fail occurs before the application layer, so the problem is at the network or OS level.
- Slow timeout versus quick refused. A timeout means traffic is being silently dropped by a stateful firewall with no explicit deny rule. A quick connection refused means the port is actively rejecting connections.
- Private or reserved IP ranges. Addresses in RFC 1918 ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x) are not routable from the public internet. A TCP check against these will always fail from an external vantage point.