SMTP protocol: how email sending works under the hood

Every email you've ever sent, whether it was a password reset or a 3am message to your coworker that probably should have waited until morning, traveled through the same protocol: SMTP. Simple Mail Transfer Protocol. It was first defined in 1982, and with some updates along the way, it still moves over 300 billion emails every day.

That's not a typo. A protocol older than most of the people reading this handles more daily traffic than any social network on earth. Understanding how SMTP works isn't just trivia. If you're building anything that sends email, this is the plumbing you're standing on.

What SMTP actually is#

SMTP is an application-layer protocol for transmitting email between servers. Jonathan Postel defined it in RFC 821 in August 1982, and RFC 5321 updated it substantially in 2008. The name tells you what it does: it transfers mail, simply.

Here's what trips people up: SMTP only handles sending. It pushes messages from one server to another. When you open Gmail and see your inbox, that's a different protocol (IMAP or POP3) pulling messages down to your client. SMTP is the delivery truck. IMAP is you checking your mailbox.

SMTP runs over TCP, typically on one of three ports:

• Port 25 is for server-to-server relay. This is how mail servers talk to each other across the internet.
• Port 587 is the submission port. Your email client or application submits outgoing mail to your server here, usually with authentication required.
• Port 465 is for implicit TLS submission. Same purpose as 587, but the TLS handshake happens immediately instead of upgrading mid-connection.

If you're sending email from an application, you're almost certainly using port 587 or 465.

The SMTP conversation, step by step#

SMTP is text-based and follows a command-response pattern. When your server wants to deliver an email, it opens a TCP connection to the recipient's mail server and they have a structured conversation:

Client connects to mail.example.com on port 25
Server: 220 mail.example.com ESMTP ready
Client: EHLO sender.example.org
Server: 250-mail.example.com Hello
        250-STARTTLS
        250 OK
Client: MAIL FROM:<agent@sender.example.org>
Server: 250 OK
Client: RCPT TO:<hello@example.com>
Server: 250 OK
Client: DATA
Server: 354 Start mail input
Client: From: agent@sender.example.org
        To: hello@example.com
        Subject: Test message

        This is the body of the email.
        .
Server: 250 OK: queued as ABC123
Client: QUIT
Server: 221 Bye

That's the whole exchange. The client identifies itself (EHLO), declares who the mail is from (MAIL FROM), specifies the recipient (RCPT TO), transmits the message content (DATA), and disconnects (QUIT). The server responds with numeric status codes at each step.

Those three-digit codes tell you everything you need to know:

• 2xx means success. Keep going.
• 3xx means the server needs more input. After DATA, for example, it's waiting for the message body.
• 4xx means temporary failure. Try again later.
• 5xx means permanent failure. The message was rejected, and retrying won't change the outcome.

If you've ever encountered a 550 denied by policy bounce, that 5xx is SMTP telling you the recipient's server has permanently refused your message.

How your email finds the right server#

Before the SMTP conversation can begin, your server needs to know where to connect. That's where DNS comes in.

When you send an email to hello@example.com, your mail server queries DNS for the MX (Mail Exchanger) records of example.com. MX records specify which servers accept email for a domain, each with a priority number:

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.

Lower priority values are tried first. Your server connects to mail1.example.com on port 25 and starts the SMTP handshake. If that server is unreachable, it falls back to mail2.example.com.

No MX records at all? The sending server tries the domain's A record as a last resort, though most production setups have explicit MX entries.

This lookup happens for every email. It's fast (usually cached by DNS resolvers), but it's running behind the scenes every single time.

Authentication: proving you're allowed to send#

Original SMTP has no built-in way to verify that the sender is who they claim to be. The MAIL FROM field is entirely self-reported. In 1982, the internet was a few hundred machines and everyone more or less trusted each other. Today, that trust gap is exactly why phishing and spam exist at the scale they do.

Three protocols were added over the decades to patch this hole.

SPF, or Sender Policy Framework, is a DNS TXT record listing which IP addresses are authorized to send email for your domain. When a receiving server gets a message claiming to be from your-domain.com, it checks the SPF record to see if the sending IP is on the approved list. Fail that check, and the email gets flagged.

DKIM (DomainKeys Identified Mail) takes a different approach. Your mail server signs each outgoing message with a private key. The matching public key lives in a DNS record. The receiving server checks the signature to confirm the message wasn't altered in transit and genuinely originated from your domain's infrastructure.

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together with a policy. It tells receiving servers what to do when authentication fails: quarantine the message or reject it outright. DMARC also provides reporting, so you can see exactly who is sending email using your domain name.

If you're sending email from a custom domain without all three configured, your messages are probably landing in spam. Not because the content is bad, but because you haven't proven you're authorized to send.

Encryption in transit#

SMTP was originally plaintext. Every command and every email body transmitted in the clear. STARTTLS was added as an upgrade mechanism: after the initial TCP connection, the client asks to switch to encrypted, and if the server supports it, they negotiate a TLS session before continuing the conversation.

Port 465 skips that negotiation entirely. The connection is encrypted from the very first byte. It was actually deprecated in 1998, then reinstated in RFC 8314 (2018) because the industry recognized that implicit TLS is more secure than opportunistic STARTTLS, which can be stripped by a man-in-the-middle attack.

Today, over 90% of inbound Gmail traffic uses TLS encryption. The holdouts shrink every year.

Where SMTP gives you no help#

SMTP has proven remarkably durable for a 44-year-old protocol, but it has real blind spots. These become obvious the moment you're building automated systems instead of clicking "send" in a desktop client.

The protocol says nothing about warm-up. You can blast 500 messages from a brand-new IP address on day one and SMTP won't stop you. But the receiving servers' reputation systems will. They'll blocklist you, and SMTP provides zero warning before it happens. New senders need to ramp up volume gradually over weeks, and getting that wrong is one of the most common mistakes in agent email setups.

Reputation tracking lives entirely outside the protocol. It's per-IP and per-domain. If another sender on your shared IP is blasting spam, your deliverability suffers too. SMTP can't distinguish a legitimate sender on a bad IP from a bad sender, period.

Spam complaint signals travel through separate feedback loops (FBLs), not SMTP. When a recipient marks your email as spam, you might not find out for hours. Some providers don't participate in FBLs at all, leaving you permanently in the dark.

Bounce handling is its own engineering project. SMTP bounce messages (DSNs) arrive as new emails with formats that vary wildly between mail servers. Parsing them reliably across providers requires dedicated code and constant maintenance.

For anyone building automated email, these gaps around SMTP are where the real complexity lives. The protocol itself is straightforward. Everything surrounding it is what makes email genuinely hard. If you're building an agent that needs its own inbox, services like LobsterMail exist specifically to handle this infrastructure layer so the agent can focus on its actual job.

The full journey of an email#

Putting it all together, here's what happens when a message is sent:

1. Your email client submits the message to your outgoing mail server via SMTP (port 587 or 465, authenticated and encrypted).
2. Your server queries DNS for the recipient domain's MX records.
3. Your server opens an SMTP connection to the recipient's mail server on port 25.
4. They run through the EHLO, MAIL FROM, RCPT TO, and DATA exchange.
5. The recipient's server checks SPF, DKIM, and DMARC authentication.
6. If authentication passes, content filters run (spam scoring, malware scanning).
7. The message is delivered to the recipient's mailbox.
8. The recipient retrieves it via IMAP or POP3.

The whole process usually takes two to ten seconds. Sometimes longer if greylisting or retry queues are involved.

Forty-four years after RFC 821, that basic flow is unchanged. The security layers are thicker, the volumes are orders of magnitude higher, and spam filters use machine learning now. But at its core, SMTP is still two servers having a polite text conversation, one command at a time. If you're debugging email delivery issues, start with the SMTP response codes. They'll tell you exactly where the conversation broke down.