Email fundamentals

How a message travels

Your app hands a message to a sending service over an API or SMTP. The sending server looks up the recipient domain’s MX records, connects to the highest-priority server, and delivers the message with SMTP. The receiving server authenticates it, scores it for spam, and files it in the inbox, the spam folder or nowhere at all.

Envelope vs. headers

Every email has two sets of addresses. The envelope — MAIL FROM and RCPT TO — is used by servers during delivery and is where bounces are sent. The headers — From:, To:, Reply-To: — are what people see in their mail client.

They don’t have to match, which is exactly why DMARC exists: it checks that the domain people see in From: lines up with the domains SPF and DKIM actually verified.

Headers worth knowing

• From — the sender people see. Must be on a domain you have authenticated.
• Reply-To — where replies go, if different from From.
• Message-ID — a unique identifier; useful for tracing a message through logs.
• List-Unsubscribe — tells mail clients how to unsubscribe, powering the one-click unsubscribe button.
• DKIM-Signature — the signature receivers verify; its s= tag names the DKIM selector.

MIME: HTML and plain text

A modern email is a MIME message with several parts. Most include both an HTML part and a plain-text part as "multipart/alternative", and the mail client shows the best one it can render. Attachments and inline images are further parts.

Always send a plain-text version alongside HTML. Some people prefer it, some clients need it, and spam filters view HTML-only mail with suspicion.

multipart/mixed
├── multipart/alternative
│   ├── text/plain
│   └── text/html
└── application/pdf   (attachment)

Check it yourself