A Bit about Email

Email moves through a chain of components: a user’s mail app submits it to a submission server, which passes it to a transfer server; the recipient’s transfer server then hands it to local delivery and storage for the recipient’s app to retrieve. This separation arose when servers and network links were unreliable: sending servers could queue messages and retry delivery rather than bounce them during brief outages. The explanation walks through SMTP, including how DNS MX records identify receiving servers, how commands specify sender and recipient addresses, and how message data is handed off. It distinguishes the SMTP “envelope” addresses from the visible From and To headers, explains delivery errors and bounce messages, and describes headers added by servers to record a message’s route.

The original SMTP system trusted senders, allowing anyone to claim any identity, so modern providers use authentication checks to make filtering possible. SPF lists authorized sending IP addresses; DKIM uses a cryptographic signature to verify message content and sender identity. These checks do not stop spam by themselves, and providers also expect sender hostnames to match forward and reverse DNS records - a barrier to sending directly from many residential connections. The discussion closes by reading a delivered message’s headers, including Received, Return-Path, and authentication results, and introduces MIME, which lets email carry formatted or alternative content rather than plain text alone. It also notes that large providers’ strict policies can make independent email delivery difficult.