In this series of posts, I’m going to share what I know about email. Over the last 20 years, I’ve learned to set up, diagnose, and do just about everything with email that you can imagine at any scale. In this series, I’ll be talking about email over the Internet, which uses protocols like SMTP and IMAP. I won’t be talking about the inner workings of commercial email software like Exchange.

Understanding how email is sent
As mentioned above, email works with a few protocols, and the one used to send email is SMTP. The idea here is the sender’s email is converted into a string of characters and is passed to an SMTP Gateway, typically at an ISP. This gateway receives this email transmission and relays it to its recipient, typically the receiver’s SMTP gateway. This hot-potato-relay idea allows SMTP gateways to forward an email to its next “hop” along the way. While you may think of an email being sent from me to you directly, it really takes a few hops before it reaches you. This is often why sometimes email arrives quickly, and sometimes it takes a few minutes. Email, by its design, is asynchronous.

What happens when a gateway is down
Email gateways are really just pieces of software that run on a server, listen for inbound connections, and forward an email to another gateway. And, like other pieces of software, they can go offline for any number of reasons. When they do, they’re unable to send or receive email, causing the delays you sometimes experience. The good news is that the SMTP protocol was designed to be resilient to servers going offline. So, if an SMTP gateway tries to send to another SMTP gateway, and the receiving gateway is offline, the sending gateway will pause and then try and resend the email. How long it will pause and how long it will keep trying are configurable by the person managing the SMTP gateway. Typically, the pause is about a minute, and the gateway will keep retrying for three days. If the sending SMTP gateway gives up sending the email after its predetermined time, the email is returned to its original sender. This is known as a “bounceback”, and has a numeric code associated with it that’s typically in the 500-600 range. I’ll explain these “result codes” in another post.

Part 2 of this series will include more.