Why SMTP requires TCP
SMTP is a stateful conversation, not a single datagram. The client and server exchange commands and responses in sequence, where each step depends on the one before it, and the session carries state from EHLO through to the final dot.
TCP guarantees delivery, ordering and integrity. A message body split across many packets must arrive complete and in order, and TCP's acknowledgement and retransmission handle that without SMTP implementing it.
The connection-oriented model is what makes the response codes meaningful. A client issues RCPT TO and waits for the server's verdict before continuing, which requires a persistent bidirectional channel.
UDP provides none of that. It is connectionless, unordered, and does not guarantee arrival, so a protocol built on it would have to reimplement everything TCP already does. For a protocol whose entire purpose is reliable transfer, that is the wrong foundation.
The ports SMTP uses
All three assigned ports are TCP.
Port 25 is for server-to-server relay. It is not a submission port, and most cloud and residential providers block it outbound to limit spam.
Port 587 is the submission port and the correct default for an application, expecting authentication and a STARTTLS upgrade per RFC 3207.
Implicit TLS runs on 465, encrypting from the first byte, an arrangement reinstated as a recommended submission port by RFC 8314.
Where UDP does appear in email
The question is worth answering precisely, because UDP is involved in email delivery without SMTP ever using it.
DNS runs primarily over UDP, and every message delivery depends on DNS lookups. MX records to find the receiving server, SPF and DMARC records published as TXT, and DKIM public keys are all fetched this way.
That is the resolution layer rather than the transfer layer. A DNS query travels over UDP, and the mail transaction that follows travels over TCP.
DNS falls back to TCP when a response exceeds what UDP can carry, which matters for email specifically because a long SPF record or a large DKIM key can exceed the limit. A resolver or firewall that blocks DNS over TCP will fail those lookups intermittently, and the symptom presents as an authentication failure rather than a network one.
The resolution layer produces its own false negatives. Our DNS record validator was failing tracking health checks for managed sending domains because a Cloudflare proxy flattens delegation CNAMEs to A records, so the CNAME lookup returned blank and reported a record missing that actually existed. The fix added an A-record fallback scoped to delegate records only, with 9 of 9 specs green. When a DNS check says missing, it is worth asking whether the record is absent or just flattened.
Why this matters in practice
The practical consequence is about firewalls rather than trivia. Opening SMTP through a firewall means opening TCP on the relevant port, and a rule written for UDP does nothing.
We run our own relay on exactly that logic. TCP 2525 is firewall-restricted to our API host, TLS and exact SMTP authentication are mandatory, every one-recipient route and MX snapshot is HMAC-signed, and arbitrary destinations, MX loops, extra recipients and unsigned or replayed requests are rejected. A TCP port that is open to the world is a liability, not a feature.
The second is diagnostic. A connection that hangs with no server greeting is a TCP-level problem, meaning a blocked port or an unreachable host, and no amount of changing credentials or encryption settings will resolve it.
Chong, on our team, closed one support case by doing nothing more than fixing the app's SMTP port, which is the level most of these tickets resolve at.
Testing follows from the same fact. Because SMTP is TCP, a session can be opened by hand and driven command by command, which is why manual diagnosis with openssl works at all.