The Top 10 Common Ports Used By Network Protocols

When a website will not load, email stops syncing, or an RDP session refuses to connect, the problem is often not the application itself. It is a port, a protocol, or a firewall rule sitting between the client and the service. Understanding Network Ports, Protocols, Port List, TCP, UDP, Port Management is basic networking literacy, and it pays off fast in troubleshooting, security, and day-to-day administration.

Typical Port Range	0-65535, with well-known ports 0-1023 as of May 2026
HTTP	Port 80 as of May 2026
HTTPS	Port 443 as of May 2026
DNS	Port 53 as of May 2026
SSH	Port 22 as of May 2026
RDP	Port 3389 as of May 2026
FTP	Ports 20 and 21 as of May 2026
POP3 and IMAP	Ports 110 and 143 as of May 2026

What Network Ports Are And How They Work

Network ports are logical identifiers, not physical sockets on a switch or router. They help TCP and UDP deliver data to the right service on the right host, which is why a server can run a web server, mail server, and SSH daemon at the same time on one IP address.

An IP address identifies the host. A transport protocol such as TCP or UDP handles delivery behavior. The port number identifies the application endpoint. Put together, they form the address the network uses to reach a service.

Port Ranges And Assignment

The IANA classifies ports into well-known, registered, and dynamic ranges. Well-known ports are typically 0-1023 and are reserved for standard services like HTTP, DNS, and SSH. Registered ports are often used by vendor applications, while dynamic or ephemeral ports are usually assigned temporarily to client connections.

That distinction matters in diagnostics. If a client opens a browser, the browser usually uses a high-numbered ephemeral source port and connects to destination port 443 on the remote server. That means one side is the client endpoint, and the other is the service endpoint.

Source Ports And Destination Ports

A source port is the temporary port chosen by the client. A destination port is the port the server listens on. For example, when your laptop opens a secure website, the laptop might use source port 51632 and destination port 443.

This is the reason packet captures are useful. In Wireshark, you can see the source and destination ports immediately, which helps you determine whether the failure is happening on the client side, the server side, or somewhere in between.

“Most port problems are not mysterious. They are mismatches between the application you expect, the protocol it actually uses, and the firewall path in the middle.”

For background on Network fundamentals and Diagnostics, ITU Online IT Training ties this topic directly to the troubleshooting skills used in the CompTIA N10-009 Network+ Training Course. Official protocol definitions also remain useful references, including the Internet Engineering Task Force’s RFCs at RFC Editor and IANA service name assignments at IANA Service Name and Transport Protocol Port Number Registry.

Why Common Ports Matter In Everyday Networking

Common ports are the shortcuts that let everyday services work without custom configuration. When a user types a URL, the browser expects HTTP on port 80 or HTTPS on port 443 unless told otherwise. When a mail client checks a mailbox, it expects POP3 on 110 or IMAP on 143 unless a secure variant is in use.

That predictability is useful for administrators. If Outlook cannot reach the mail server, checking whether port 143, 993, 110, or 995 is open immediately narrows the problem. If SSH fails, port 22 is the first place to look. Port knowledge turns vague complaints into specific tests.

Ports In Security And Segmentation

Ports are also central to Firewall policy, Access Control, and Network Segmentation. A network segment for users may allow outbound 80 and 443 but block inbound 3389. A server segment may allow 22 from a jump host but deny it from the rest of the enterprise.

That is also why attackers care about common ports. Internet-wide scans often look for exposed SSH, RDP, FTP, and SMTP services because those ports are easy to identify and commonly misconfigured. The defense is simple in principle and hard in practice: expose less, authenticate better, and monitor more closely.

For a wider workforce view, the U.S. Bureau of Labor Statistics Occupational Outlook Handbook continues to show steady demand for network and systems roles, and the NIST Cybersecurity Framework remains a strong baseline for asset visibility and risk management. Common ports are part of both.

HTTP Port 80 And What It Is Used For

HTTP is the Hypertext Transfer Protocol, and port 80 is its default port for unencrypted web traffic. If a browser connects to a website without a port number and the URL starts with http://, it usually talks to port 80.

Port 80 still appears in modern environments even when HTTPS is the real target. Many sites listen on port 80 only to issue a redirect to port 443. That lets users typing an old bookmark or an unencrypted URL land on the secure version automatically.

Where Port 80 Still Shows Up

• Redirect listeners that forward requests to HTTPS.
• Internal web services used on isolated lab networks.
• Legacy applications that never adopted TLS.

Security is the big limitation. Plain HTTP does not encrypt content, credentials, or cookies. Anyone who can observe traffic on the path can read it. For that reason, port 80 is acceptable for redirects and low-risk internal testing, but it is a poor choice for sensitive data.

To verify port 80 traffic, browser developer tools can show the request and response headers, and a packet capture tool such as Wireshark can confirm that the session is cleartext. The OWASP guidance on transport protection is a practical reference for why unencrypted web traffic should be phased out wherever possible.

HTTPS Port 443 And Secure Web Traffic

HTTPS is HTTP carried over Transport Layer Security, and port 443 is the standard port for that encrypted traffic. A browser connecting to port 443 negotiates TLS first, then sends web requests inside the encrypted session.

That encryption protects data in transit. It helps preserve confidentiality and integrity, which is why modern websites, SaaS tools, and APIs prefer 443 over 80. It also means that packet captures reveal metadata such as the destination address and handshake behavior, but not the actual web content.

Common HTTPS Troubleshooting Scenarios

1. Certificate errors caused by expiration, hostname mismatch, or an incomplete trust chain.
2. Blocked outbound access when a firewall or proxy prevents clients from reaching port 443.
3. Middlebox inspection issues where SSL/TLS interception breaks application behavior.

Many applications beyond browsers use 443 because it is often allowed through firewalls and proxies. Microsoft 365 clients, cloud management consoles, and REST APIs frequently standardize on HTTPS for that reason. If it is secure web traffic, port 443 is usually the first port to test.

Microsoft’s own documentation at Microsoft Learn is a good example of how vendors describe TLS-enabled services, and the CIS Benchmarks are widely used to harden web-facing systems that expose 443. Secure exposure still needs hardening.

DNS Port 53 And Name Resolution

Domain Name System (DNS) uses port 53 to translate names like example.com into IP addresses. Most clients send standard queries over UDP 53 because it is lightweight and fast, while TCP 53 is used for larger responses, zone transfers, and some retry conditions.

DNS sits near the front of almost every connection. Before a browser can reach a web server, the client often needs a name lookup. Before email delivery succeeds, the sending server often checks MX records. Before cloud apps load, they often rely on DNS resolution first.

UDP Versus TCP On Port 53

• UDP 53 is common for short queries and fast responses.
• TCP 53 is used when responses are too large for UDP or when reliability is required.
• Blocking port 53 can make internet access appear broken even when basic connectivity is fine.

A common failure pattern is simple: ping works, but websites do not load. That often points to a DNS issue instead of a routing issue. If port 53 is blocked by a firewall, misrouted by a resolver, or broken by a client setting, the user may have network connectivity but no usable name resolution.

Modern secure DNS options such as DNS over HTTPS and DNS over TLS still depend on the core DNS service model. The transport changes, but the job remains the same: resolve names reliably. The authoritative source for DNS behavior remains IANA, and broader operational guidance is available through CISA.

How Secure Remote Administration Uses SSH Port 22

Secure Shell (SSH) is a secure remote administration protocol that normally listens on port 22. It gives administrators an encrypted terminal session, remote command execution, and secure file transfer through tools such as SCP and SFTP.

SSH is the standard tool for managing Linux and Unix-like systems, but it also appears in network appliances, firewalls, and Windows-based environments that include an SSH server. Because the traffic is encrypted, credentials and commands are protected in transit.

Best Practices For SSH Port Management

• Use key-based authentication instead of passwords where possible.
• Disable direct password logins on exposed systems.
• Restrict source IPs with firewall rules or security groups.
• Consider a custom port only as an exposure-reduction measure, not as the primary defense.

Changing SSH from 22 to another port can reduce noisy scans, but it does not make the service secure by itself. A hardened host with key-based authentication and strict allowlists is stronger than a hidden port with weak credentials.

For official protocol and hardening guidance, the OpenSSH project and the vendor documentation for the operating system in use are the best references. If you are learning this as part of the CompTIA N10-009 Network+ Training Course, SSH is one of the first services worth testing during remote administration labs.

How FTP Ports 20 And 21 Work

File Transfer Protocol (FTP) commonly uses port 21 for control traffic and port 20 for data in active mode. Port 21 handles login, commands, and session control. Port 20 may be used for the actual data connection when the client is in active FTP mode.

FTP is older, and its design shows it. Traditional FTP does not encrypt credentials or file contents, so it should not be used for sensitive transfers over untrusted networks. That is why many organizations have moved to SFTP or FTPS.

Active Versus Passive FTP

1. Active FTP uses the server to initiate the data channel back to the client.
2. Passive FTP lets the client open both control and data channels, which is friendlier to firewalls and NAT.
3. Passive mode is now more common because it works better across routed networks.

FTP still appears in legacy systems, manufacturing environments, and internal file exchange workflows. If a vendor appliance only supports FTP, document the exposure, limit it to trusted networks, and replace it when the platform allows.

The secure alternatives are straightforward. SFTP runs over SSH, while FTPS adds TLS to FTP. The FTP specification remains the baseline reference for FTP behavior, but operationally the industry has moved toward encrypted transfer methods.

How SMTP Port 25 Delivers Email

Simple Mail Transfer Protocol (SMTP) uses port 25 for server-to-server email transfer. In modern environments, port 25 is usually associated with relaying mail between mail servers rather than direct client submission.

That distinction matters. Email clients often use port 587 for submission and port 465 for implicit TLS, while port 25 is reserved for mail transport between systems. Many ISPs block outbound 25 because open relays and infected hosts have historically abused it for spam.

Practical SMTP Problems

• Outbound blocks prevent a mail server from handing off mail to the next hop.
• Misconfigured MX records send mail to the wrong destination.
• Relay restrictions reject mail from unauthorized senders.

A blocked port 25 can make outbound email queue up indefinitely on a server even though internal mail works fine. When this happens, checking the SMTP logs and testing connectivity with tools such as telnet mail.example.com 25 or nc -vz mail.example.com 25 quickly shows whether the path is open.

For authoritative guidance, the SMTP specification is still the primary technical reference, and the anti-abuse perspective from CISA is useful when you are hardening mail infrastructure.

How POP3 Port 110 Retrieves Email

Post Office Protocol version 3 (POP3) uses port 110 by default to retrieve email from a server to a client. The classic POP3 model is simple: download messages, often remove them from the server, and read them locally.

That simplicity is why POP3 still exists. It works well for single-device users and minimal mailbox setups. It is not ideal for people who need synchronized state across a phone, laptop, and webmail portal.

POP3 Versus Secure POP3

• Port 110 is unencrypted POP3.
• Port 995 is POP3 over TLS, often called POP3S.
• POP3 is usually less flexible than IMAP for multi-device use.

Secure retrieval matters because email credentials are valuable to attackers. If a client is still using port 110, that traffic should be evaluated carefully and replaced with a secure alternative where possible. The protocol behavior is described in the relevant RFCs at RFC Editor.

POP3 can still make sense for archive pull jobs, older mail clients, and isolated mailbox environments. For everyone else, the need to sync folders and read state across devices usually pushes the design toward IMAP.

How IMAP Port 143 Syncs Mailboxes

Internet Message Access Protocol (IMAP) uses port 143 by default and keeps messages on the server while synchronizing folder state across devices. That makes it the preferred model for modern email use, especially when a user checks mail from multiple endpoints.

IMAP is better than POP3 for shared inboxes, executive mailboxes, and enterprise environments where the server must preserve message state. Deleted, flagged, read, and moved status can all sync across clients, which prevents the “I read it on my phone but it still shows unread on my laptop” problem.

IMAP And Secure Access

• Port 143 is standard IMAP without encryption.
• Port 993 is IMAP over TLS, often called IMAPS.
• IMAP is usually preferred for users with multiple devices.

Enterprise mail systems rely heavily on IMAP behavior because it supports centralized storage and stateful access. That is why secure IMAP on 993 is more common than plain 143 in real deployments. The protocol’s role is documented in the relevant RFCs, and secure deployment guidance aligns well with ISO/IEC 27001 principles for access control and confidentiality.

For readers studying email troubleshooting in the CompTIA N10-009 Network+ Training Course, IMAP is one of the easiest places to spot a port-related failure. If 993 is blocked, mobile apps may stop syncing even though webmail still works.

How RDP Port 3389 Supports Remote Desktop Access

Remote Desktop Protocol (RDP) uses port 3389 for remote desktop access and administration in Windows environments. It lets an administrator view and control a remote desktop session as if they were sitting in front of the machine.

RDP is convenient, and that convenience is exactly why it is targeted so often. Exposed RDP services are a common brute-force target, especially when they are reachable from the public internet. Secure deployment matters more here than with many other internal services.

RDP Hardening Practices

• Place RDP behind a VPN rather than exposing it directly.
• Require MFA whenever the environment supports it.
• Enable network-level authentication to reduce unauthorized session setup.
• Use firewall allowlists for administrator source addresses.

Troubleshooting often starts with the basics: is port 3389 blocked, is the service running, are credentials correct, and is the target host even listening? A misconfigured gateway, a stopped Remote Desktop service, or a local firewall rule can all produce the same symptom from the user’s point of view.

Microsoft documents RDP behavior in Microsoft Learn, and security guidance for exposed remote access fits well with NIST risk-management principles and Center for Internet Security hardening practices.

What Are The Best Common Port Security And Firewall Practices?

The best port security practice is simple: open only what the business truly needs. Every open port is an invitation to scan, test, and possibly exploit, so Port Management should be documented, reviewed, and tied to a real service owner.

That means each open port should have a reason, a business owner, and a planned review date. If you cannot explain why a port is open, you probably have inherited technical debt or an unnecessary exposure.

Practical Testing And Verification

1. Check the listening state with tools like netstat, ss, or PowerShell Get-NetTCPConnection.
2. Test reachability with telnet, nc, or Test-NetConnection.
3. Scan exposure with nmap from an approved admin host.
4. Review logs for unexpected connection attempts and repeated failures.

Opening a port in a firewall is not enough. The service must listen, the route must exist, the client must be allowed, and the protocol must match the application. Many “port blocked” tickets are really service failures, authentication failures, or DNS failures.

A strong security posture also favors encrypted alternatives. HTTPS instead of HTTP, SSH instead of Telnet, SFTP instead of FTP, and IMAPS or POP3S instead of cleartext email retrieval are all examples of reducing exposure without changing the business outcome.

The most useful references here are the CIS Benchmarks, the NIST Cybersecurity Framework, and vendor documentation for the platform you are administering. Those sources help turn common ports from a memorization list into a real control set.

When Should You Use Common Ports, And When Should You Avoid Them?

Use common ports when you need interoperability, predictable client behavior, and standard service discovery. A web service on 443, DNS on 53, and SSH on 22 are easy to support because tools, firewalls, and clients already understand them.

Avoid common ports when the service is legacy, unencrypted, or unnecessarily exposed to untrusted networks. Plain FTP, cleartext POP3, and internet-facing RDP are poor choices unless they are protected by additional controls and a very good reason to exist.

Good Use Cases Versus Poor Fit

• Good fit: HTTPS for customer portals and APIs.
• Good fit: IMAPS for multi-device mail access.
• Poor fit: FTP for sensitive file exchange over public networks.
• Poor fit: RDP exposed directly to the internet.

Use the common ports when they reduce complexity. Avoid them when they increase risk without delivering a real benefit. That balance is the essence of practical Port Management.

The IETF defines the protocols, while the security community, including CISA and the NIST framework, gives administrators the operational guardrails. Both perspectives matter.

Common ports are not just a memorization exercise. They are the daily checkpoints of networking work, from browser troubleshooting to server hardening. If you are building skills for the CompTIA N10-009 Network+ Training Course, this is one of the most practical topic areas you can master early.

Conclusion

The most important common ports are straightforward once you connect them to the services they support. Port 80 carries HTTP, 443 carries HTTPS, 53 handles DNS, 22 supports SSH, 25 handles SMTP transport, 110 and 143 support email retrieval, 20 and 21 support FTP, and 3389 powers RDP.

Understanding these ports makes troubleshooting faster and security decisions clearer. It tells you where to look when a service fails, which firewall rule to review, and when a protocol should be replaced with a secure alternative. That is why port knowledge belongs in every network administrator’s core skill set.

If you want the practical next step, review the ports used in your own environment, document the business reason for each one, and verify that only the required services are exposed. That single habit improves both reliability and security.

CompTIA® and Network+™ are trademarks of CompTIA, Inc. Microsoft® is a trademark of Microsoft Corporation. Cisco® is a trademark of Cisco Systems, Inc. AWS® is a trademark of Amazon Web Services, Inc.