How Email Works, Part One: The Story of "Send"

Following a column about five things every email marketer should know, this columnist goes into detail about the specifics of what exactly happens when you press "send."

Last year, I wrote an article listing five things every email marketer should know. A common response was “ok, so where can we learn this?” Here then is my explanation of how email is delivered. i.e. What happens when you hit “send” in your email platform.

The first thing that happens when you hit send is your request goes into a queue. Fair warning, email is a “store and forward” system and queues feature heavily. Your queued request will be processed as soon as resources are available to handle it.

how-email-works

The next step is to create a unique message for each recipient from the template you put into the platform. The message is unique because even without content personalization the tracking links and recipient headers are individually personalized. A submission engine in the ESP’s platform creates these unique messages and passes them to an MTA (Mail Transfer Agent), more commonly just called a mail server. In modern ESPs the submission process has become quite sophisticated with advanced personalization and scripting performed for each recipient. An error here can cause partial or complete failure of your deployment.

The MTA’s job is to queue up and then deliver messages to the appropriate receiving MTAs. For each message it determines where it should be delivered, attempts delivery and records success or failure. The MTA determines where a message should be delivered based on the domain name (everything after the @ sign) in the ‘To’ field. It uses DNS (Domain Name System) to identify servers willing to accept email for the domain, connects to them on port 25 and attempts to deliver the message using SMTP (Simple Mail Transfer Protocol).

SMTP is a very forgiving protocol able to work around significant network or transmission problems. If the MTA cannot identify any servers willing to receive an email or cannot connect to them it will put it back in the queue and try again later. It will keep trying for a number of hours (even days). This is why message delivery may be delayed on occasion.

If a connection can be made the sending server attempts to hand off the email. SMTP is a very simple protocol and for the purposes of understanding the process I’m sticking just to SMTP rather than getting into later ESMTP extensions. A typical transaction can use just five commands (HELO, MAIL FROM, RCPT TO, DATA and QUIT). A typical transaction will look something like this:

email-transaction-five-commands

The commands sent are in blue while the remote server’s responses are in black. The receiving server starts with a banner, the sending server then indicates who it is by saying hello, who the message is from, who it is to and what the message is, before finally saying goodbye. The receiving server responds with a three digit code acknowledging each command. Codes starting with a 2 indicate success, those starting with a 3 mean send more information, while 4 and 5 are temporary and permanent failures respectively.

If the entire transaction succeeds as far as your ESP is concerned the email was successfully delivered. From this point on your ESP has no visibility of what happens to your message.

If the transaction results in an error code starting with a 5 (a “5xx” response) your ESP will record a hard bounce. 5xx responses often indicate issues such as an unknown recipient but can happen for any number of reasons including spam filtering. Though there is some consistency 5xx can vary from server to server which presents challenges to senders. The protocol also only addresses delivery of this message at this time. The errors say nothing about what might happen to future messages. That has to be inferred by the sender.

4xx errors indicate a temporary problem. The sending MTA will place the message back in the queue and try again later. It will keep retrying until it succeeds or until eventually it gives up and the message is considered to have bounced.

In part 2 we’ll look at what happens to your message on the receiving side: How the receiving server decides whether or not to accept your message and what it does with your message once it has accepted it.

Subscribe to get your daily business insights

Whitepapers

US Mobile Streaming Behavior
Whitepaper | Mobile

US Mobile Streaming Behavior

5y

US Mobile Streaming Behavior

Streaming has become a staple of US media-viewing habits. Streaming video, however, still comes with a variety of pesky frustrations that viewers are ...

View resource
Winning the Data Game: Digital Analytics Tactics for Media Groups
Whitepaper | Analyzing Customer Data

Winning the Data Game: Digital Analytics Tactics for Media Groups

5y

Winning the Data Game: Digital Analytics Tactics f...

Data is the lifeblood of so many companies today. You need more of it, all of which at higher quality, and all the meanwhile being compliant with data...

View resource
Learning to win the talent war: how digital marketing can develop its people
Whitepaper | Digital Marketing

Learning to win the talent war: how digital marketing can develop its peopl...

2y

Learning to win the talent war: how digital market...

This report documents the findings of a Fireside chat held by ClickZ in the first quarter of 2022. It provides expert insight on how companies can ret...

View resource
Engagement To Empowerment - Winning in Today's Experience Economy
Report | Digital Transformation

Engagement To Empowerment - Winning in Today's Experience Economy

1m

Engagement To Empowerment - Winning in Today's Exp...

Customers decide fast, influenced by only 2.5 touchpoints – globally! Make sure your brand shines in those critical moments. Read More...

View resource