Email: SMTP, IMAP and deliverability

Why it matters

Password resets, receipts, verification codes and alerts all depend on email, and an email that lands in spam is, to the user, a broken product. Email is also the oldest widely used application protocol and a useful contrast with HTTP: asynchronous, store-and-forward, retried over days, authenticated after the fact. Sending email from a product is mostly an exercise in DNS records and reputation, which this lesson makes concrete.

The idea

Email separates sending from reading. SMTP (Simple Mail Transfer Protocol) moves messages from the sender's client to their server and from server to server across the internet. IMAP (or the older POP3) lets the recipient's client read messages stored on their server. Delivery is store-and-forward: each server accepts responsibility for a message, queues it, and retries the next hop until it succeeds or gives up, typically after several days.

The SMTP conversation

SMTP is a text, command-response protocol. The client connects, greets with EHLO, upgrades to encryption with STARTTLS, declares the envelope sender with MAIL FROM and recipients with RCPT TO, sends the message with DATA, and the server replies with numeric codes: 2xx accepted, 4xx temporary failure (retry later), 5xx permanent failure (bounce). Port 25 is for server-to-server relay; port 587 is for authenticated submission from clients and applications. Many cloud providers block outbound port 25 by default to curb spam.

Finding the destination

The sending server takes the domain after the @ and looks up its MX records, each with a preference value; it tries the lowest value first and falls back to the others. A domain with no working MX cannot receive mail, which is why MX records are part of any domain migration checklist.

Authentication: proving you may send

SMTP originally let anyone claim any sender, which is why spam and phishing flourished. Three DNS-published mechanisms now let receivers check senders.

Major mailbox providers now require SPF, DKIM and DMARC for bulk senders; without them, mail from a product is likely to be filtered or rejected.

Deliverability beyond DNS

Passing authentication makes mail eligible; reputation decides whether it reaches the inbox. Receivers score the sending IP and domain on complaint rates, bounce rates, spam-trap hits and engagement.

1. 1

   Use a dedicated sending service

   Transactional providers manage IP reputation, retries, bounces and feedback loops; running your own SMTP servers for product email is rarely worth it.
2. 2

   Separate streams

   Send transactional mail (receipts, resets) from a different subdomain or IP pool than marketing, so a marketing complaint spike cannot sink password resets.
3. 3

   Handle bounces and complaints

   Stop sending to addresses that hard-bounce or mark mail as spam; repeated sends to dead addresses damage reputation quickly.
4. 4

   Warm up new domains and IPs

   Ramp volume gradually; a new sender blasting large volume looks like spam.
5. 5

   Treat sending as asynchronous

   Queue emails from the application, send from workers with retries, and never make a user request wait on an SMTP call.

Trade-offs

Store-and-forward with retries makes email remarkably robust to outages, at the cost of unpredictable delivery time and no end-to-end guarantee. Bolted-on authentication works but depends on getting several DNS records exactly right, and reputation systems trade openness for spam resistance, which makes new senders work to be trusted. Using a provider trades control and some cost for deliverability expertise most teams lack.

In an interview

Treat email as an external, asynchronous dependency: "Account emails are enqueued and sent by workers through a transactional provider from a dedicated subdomain with SPF, DKIM and a DMARC reject policy; bounces and complaints come back by webhook and suppress the address. A password reset never blocks on the provider; it retries, and the user can request a resend."