SMTP uses TCP, not UDP. Every email you send travels over a TCP connection because email requires guaranteed, in-order delivery of data. Losing even a small piece of a message would corrupt the entire email, so the reliability that TCP provides isn’t optional for this protocol.
Why SMTP Requires TCP
TCP is a connection-oriented protocol, meaning your email client and the mail server establish a dedicated connection before any data moves. This connection uses a three-step process: your device sends a synchronization request, the server acknowledges it and sends its own synchronization signal back, and your device confirms. Only after this handshake completes does the actual email transfer begin.
Once connected, every piece of data sent over TCP gets an acknowledgment from the receiving end. If a packet goes missing, TCP automatically retransmits it. If packets arrive out of order, TCP reassembles them in the correct sequence. These features are essential for email because an incomplete or scrambled message is useless.
UDP, by contrast, is connectionless. It fires off data without establishing a connection first and without checking whether anything arrived. That makes UDP great for applications like video streaming or online gaming, where speed matters more than perfection and a dropped frame is barely noticeable. For email, though, “good enough” delivery isn’t acceptable. Every byte of the message, every attachment, and every header field needs to arrive intact.
How SMTP Uses the TCP Connection
SMTP operates as a back-and-forth conversation between your mail client and the server, and each step relies on TCP’s reliability. Your client sends a command (like identifying itself or specifying the recipient), and the server responds with a status code over the same TCP connection. This call-and-response pattern continues through the entire process: greeting, authentication, specifying sender and recipient, transmitting the message body, and closing the connection.
If any command or response were lost in transit, the email transaction would break. TCP’s built-in error correction handles this transparently, retransmitting anything that doesn’t get acknowledged. The application layer (SMTP itself) doesn’t need to build its own reliability mechanisms because TCP already provides them.
SMTP Port Numbers
SMTP communicates over several well-known TCP ports, each serving a different purpose:
- Port 25 is the original SMTP port, still used for server-to-server mail relaying. Many internet service providers block this port for regular users to reduce spam.
- Port 587 is designated for email submission from a mail client to a server. It uses STARTTLS, which upgrades a plain connection to an encrypted one after the initial handshake.
- Port 465 is the current recommended port for encrypted email transmission. It uses implicit TLS, meaning encryption starts immediately rather than being negotiated mid-connection. RFC 8314, published in 2018, endorsed this as the default for secure SMTP.
- Port 2525 is an unofficial fallback some email providers offer when firewalls or network policies block the standard ports.
All of these are TCP ports. There is no standard UDP port for SMTP.
Could SMTP Ever Use UDP?
Some modern protocols have moved to UDP-based transport. HTTP/3, for example, runs on QUIC, a protocol built on top of UDP that adds its own reliability and encryption layer while reducing connection setup time. In theory, a similar approach could be applied to email.
In practice, no current standard or widely adopted proposal moves SMTP to UDP or QUIC. Email doesn’t have the same latency sensitivity as web browsing or video calls, so the performance gains from a UDP-based transport would be minimal. The existing TCP-based infrastructure for email is deeply established across millions of mail servers worldwide, and the reliability guarantees of TCP remain a natural fit for a protocol where complete, accurate delivery is the entire point.