What is SMTP? The protocol that moves every email

SMTP (Simple Mail Transfer Protocol) is the protocol used to transfer email from a sending client or server to a receiving mail server, and from one mail server to another. It has been the backbone of how email moves since the early 1980s, with extensions added over time (ESMTP) to support authentication, larger attachments, and encryption.

What SMTP does and doesn't do

SMTP's job ends at delivery to the receiving server's mailbox. Retrieving that mail into an email client - what you actually see in your inbox - is handled by a different protocol, either IMAP (which keeps mail synced on the server, the standard for most webmail and modern clients) or the older POP3 (which typically downloads and removes mail from the server). SMTP is strictly the transfer protocol; IMAP/POP3 is the retrieval protocol.

The three roles in an SMTP transaction

• MSA (Mail Submission Agent): accepts mail from a client (your email app) for delivery, typically on port 587 with authentication required (this is "SMTP AUTH").
• MTA (Mail Transfer Agent): relays mail between servers, traditionally on port 25.
• MDA (Mail Delivery Agent): hands the message off into the recipient's actual mailbox storage once it arrives at the destination server.

The commands, in sequence

A basic SMTP conversation looks like this once connected:

HELO mail.example.com
MAIL FROM:<sender@example.com>
RCPT TO:<recipient@destination.com>
DATA
Subject: Test message
...message body...
.
QUIT

EHLO (rather than HELO) is used for ESMTP, the extended version that supports authentication, STARTTLS encryption, and larger message sizes - almost all mail today uses EHLO.

The three ports and what each is for

Where SMTP causes visible problems

Most of the SMTP error codes senders encounter (550, 554, 421, and others) are the receiving server's response during the RCPT TO or DATA stage, rejecting or deferring the message - these are policy and reputation decisions expressed through the protocol, not SMTP malfunctioning.

What not to do

• Don't confuse an SMTP delivery failure with an inbox-placement problem - SMTP accepting a message (a 250 response) only means the receiving server took custody of it; it says nothing about whether it lands in the inbox or spam folder.
• Don't assume port 25 will work for sending from a home connection or many cloud VPS providers - it's commonly blocked at the network level regardless of your mail server's configuration.
• Don't skip SMTP AUTH on your submission port - unauthenticated open relays are both a spam risk and, on modern networks, usually blocked outright by the receiving side.

Common SMTP response codes you'll actually see

The future of SMTP, briefly

SMTP itself hasn't changed structurally in decades - what's changed around it is mandatory encryption (STARTTLS is now effectively universal rather than optional), authentication requirements (SMTP AUTH is standard for submission, and DMARC adds a domain-level authentication layer on top), and the shift toward API-based sending for many applications, which still uses SMTP under the hood at the ESP's infrastructure even when your application code never constructs an SMTP command directly. The protocol's basic transaction model - connect, identify, specify sender and recipient, transfer data, disconnect - has proven durable precisely because it's simple enough to extend rather than replace.

SMTP security measures worth knowing by name

• STARTTLS: upgrades a plaintext connection to an encrypted one mid-session, now effectively universal for submission on port 587.
• SMTP AUTH: requires a username and password (or token) before a client can submit mail, preventing anonymous relay abuse.
• MTA-STS: a newer policy mechanism letting a domain declare that it only accepts mail over TLS, rejecting unencrypted delivery attempts from compliant senders.
• DANE/TLSA: a DNSSEC-backed mechanism for pinning which TLS certificate a mail server should present, closing a gap STARTTLS alone leaves open to interception.

None of these change the basic SMTP command sequence - they wrap additional security guarantees around the same underlying protocol rather than replacing it.

MailPilot works directly over SMTP/IMAP for custom mail servers, SendGrid, Amazon SES, Mailgun and Postmark (alongside OAuth for Gmail and Outlook), so the protocol-level setup is something it verifies as part of connecting a mailbox, not something you have to debug blind.