SMTP
Simple Mail Transfer ProtocolSMTP is the postal service of email. It is a push protocol — it moves a message from your client to your provider, then from server to server, until it lands in the recipient’s mailbox. Reading that mail is another protocol’s job; SMTP only ever carries it forward.
SMTP only ever pushes mail forward — retrieving it from the mailbox is IMAP’s and POP3’s job.
Open the MAIL lab →
One email from Alice’s laptop to Bob’s phone: SMTP hands it off twice and stops at a mailbox, then IMAP reads it in place—or POP3 downloads it, with optional deletion demonstrated clearly.
How it works
The envelope (MAIL FROM / RCPT TO) decides delivery — separately from the From: header you see. If the next hop is down, the server queues and retries rather than losing the mail.
What SMTP does, step by step
Your client hands the message to its server on port 587, authenticated and over TLS.
The server looks up the recipient domain’s MX record in DNS to learn which host accepts its mail.
It connects to that MX on port 25 and runs the same envelope dialog to hand the message over.
Accepted mail lands in the mailbox; a temporary failure is retried, a permanent one bounces back.
In cybersecurity
SMTP was built for a trusting network where any server would relay for anyone — so almost every layer of email security since has been about proving a message is really from who it claims.
The From: header is free text; SPF, DKIM and DMARC exist because SMTP alone can’t vouch for a sender.
A server that relays for anyone becomes a spam cannon — authenticated submission closed that door.
Look-alike domains and forged display names carry most business email compromise — DMARC blunts it.
STARTTLS encrypts server-to-server hops, but a downgrade is possible — MTA-STS enforces it.
A sending IP’s history decides whether mail is trusted, greylisted or dropped before content is even read.
VRFY and verbose RCPT errors leak valid addresses; hardened servers give nothing away.