← RFC Reference

The Lifecycle of an Email

From the moment you click "Send" to the moment a message appears in someone's inbox — every hop, every protocol, every decision along the way.

The Actors

The Internet Mail Architecture (RFC 5598) defines the roles that participate in email delivery. Understanding these roles is essential because the same piece of software often plays multiple roles, and the boundaries between them matter for understanding how mail flows.

In practice, these roles are often collapsed. Gmail's infrastructure is simultaneously MSA, MTA, MX, MDA, and MRA. Postfix can act as both MSA and MTA. But the logical roles remain distinct, and understanding them helps you debug delivery problems.

Stage 1: Composition (MUA)

The lifecycle begins when a user composes a message in their mail client, or when an application generates a message programmatically (via an API or SMTP library).

The MUA constructs the message according to RFC 5322 (Internet Message Format):

Key decisions at this stage:

• The From: header identifies the author to the recipient (and is what DMARC checks for alignment).
• The Message-ID: is generated — a globally unique identifier for this specific message.
• MIME encoding is applied: attachments are Base64-encoded, the body is structured as multipart if needed.
• The MUA does not add Received: headers. Those are added by each server that handles the message.

Stage 2: Submission (MUA → MSA)

The MUA connects to the MSA (RFC 6409) to hand off the message. This is the submission step.

What the MSA does upon receiving the message:

• Authenticates the sender. The MUA must provide valid credentials (username/password via AUTH). This is what prevents random people from using your mail server as an open relay.
• Validates the envelope. The MSA may check that the MAIL FROM domain matches the authenticated user's domain.
• Adds a Received: header. This records the first hop: who submitted the message, when, and from what IP.
• May add or fix headers. The MSA can add a Date: header if missing, generate a Message-ID: if the MUA did not, and add DKIM-Signature headers.
• Queues the message for delivery. The message enters the MTA's outbound queue.

The API submission path

When using a transactional email service like Mailer To Go, your application typically submits via an HTTP API rather than SMTP. The API server accepts the message, constructs the SMTP envelope and headers, applies DKIM signing, and injects the message into the MTA queue. The API call replaces both the MUA and the MUA-to-MSA SMTP transaction, but everything downstream remains the same.

Stage 3: Routing and Transfer (MTA → MTA)

The sending MTA must now deliver the message to the recipient's domain. This is the relay phase, governed by RFC 5321 (SMTP).

DNS resolution

The MTA looks up the MX records for the recipient's domain:

It tries the lowest-priority MX first. If that server is unreachable, it falls back to the next. See DNS and Mail Routing for the full algorithm, including fallback to A/AAAA records and Null MX handling.

The transfer

At this stage:

• STARTTLS encrypts the connection. Without MTA-STS or DANE, the sending MTA will fall back to plaintext if TLS negotiation fails. This is a security risk — an active attacker can strip TLS from the connection.
• No authentication (AUTH) is used. Server-to-server SMTP on port 25 does not require credentials. The receiving server relies on the IP address, SPF, DKIM, and DMARC to verify the sender.
• Another Received: header is added. Each MTA prepends a Received: header, building a chain that documents the message's path.
• The message may pass through multiple MTAs. Internal routing within large organizations, forwarding rules, and mailing lists can add additional hops.

Queuing and retries

If the receiving MX returns a 4xx temporary error (server busy, greylisting, rate limiting), the sending MTA queues the message and retries later. Retry schedules typically use exponential backoff: 15 minutes, 30 minutes, 1 hour, 2 hours, etc. If the message cannot be delivered after the retry period (usually 4–5 days), the MTA generates a bounce message (DSN) and sends it back to the envelope sender.

Stage 4: Reception (MX)

The receiving MX (the MTA that accepts incoming mail for the recipient's domain) is where most filtering happens. This is the gatekeeper.

At connection time, before any message content arrives:

• IP reputation check. The receiving MX checks the connecting IP against its internal reputation database and external blocklists.
• Reverse DNS check. The IP should have a valid PTR record that resolves back to the same IP.
• Rate limiting. Excessive connections from the same IP may be throttled.

During the envelope phase:

• Recipient validation. Does the mailbox exist? If not: 550 5.1.1 User unknown.
• SPF check. The MAIL FROM domain is checked against its SPF record to verify the sending IP is authorized.

After DATA (the full message is received):

• DKIM verification. The DKIM signature is validated against the public key in DNS.
• DMARC evaluation. SPF and DKIM results are checked for DMARC alignment with the From: header.
• Content filtering. The message passes through spam filters: content analysis, URL checking, Bayesian classification, machine learning models.
• Authentication-Results header added. The MX records the results of all authentication checks in an Authentication-Results header.

Stage 5: Delivery (MDA)

The Mail Delivery Agent takes the message that passed filtering and deposits it into the recipient's mailbox. In many systems, the MDA is integrated into the MX server rather than being a separate process.

The MDA's responsibilities:

• Mailbox selection. Determine which mailbox (user account) receives the message based on the RCPT TO address, aliases, and routing rules.
• Folder placement. Based on the spam filter's verdict and user-defined rules, the message goes to the Inbox, Spam/Junk folder, a specific label (Gmail), or a custom folder (Sieve rules).
• Sieve filtering. Many mail systems support Sieve (RFC 5228), a language for user-defined mail filtering rules. Rules can file messages into folders, forward them, reject them, or trigger vacation auto-replies.
• Quota enforcement. If the mailbox is over quota, the MDA may reject the message with 452 4.2.2 Mailbox full or 552 5.2.2 Mailbox full.
• Notification. The MDA may trigger a push notification to the user's devices (new mail alert).

At this point, the message is at rest in the recipient's mail store. The SMTP transaction is complete. The sending MTA's responsibility ended when it received the 250 OK from the receiving MX.

Stage 6: Retrieval (MRA → MUA)

The recipient's mail client retrieves the message from the mail store using one of three protocols:

IMAP (RFC 9051)

The dominant mail access protocol. IMAP keeps messages on the server and synchronizes state (read/unread, flags, folders) across multiple clients. The client downloads message headers first and fetches full bodies on demand. Changes made on one client (marking as read, moving to a folder) are reflected on all clients.

POP3 (RFC 1939)

The older, simpler protocol. POP3 downloads messages to the client and (by default) deletes them from the server. It does not synchronize state between clients. Largely superseded by IMAP, but still used in some scenarios.

Web and API access

Webmail interfaces (Gmail, Outlook.com) and mobile apps access the mail store through proprietary APIs or JMAP (RFC 8620), bypassing IMAP/POP3 entirely. The message never leaves the provider's servers — the client displays it via a web request.

Where Things Go Wrong: Failure Modes at Each Stage

Submission failures

Authentication fails (wrong password, expired token), the MSA rejects the message (over size limit, policy violation), or the connection times out. The user sees an error immediately.

Routing failures

DNS resolution fails (no MX records, DNS timeout), all MX hosts are unreachable, or every MX returns a permanent error. After retries are exhausted, the sender receives a bounce (DSN).

Reception-time rejection

The receiving MX rejects the message at SMTP time: blocklisted IP (550), failed authentication (550 5.7.1), unknown recipient (550 5.1.1), or content rejection (554). The sending MTA generates a bounce notification to the envelope sender.

Post-acceptance filtering

The MX accepted the message (250 OK) but the MDA routes it to the spam folder based on content analysis and reputation scoring. The sender does not receive a bounce — the message was technically "delivered" — but the recipient never sees it. This is the most common and most difficult deliverability problem to diagnose.

Mailbox full

The recipient's mailbox is over quota. Depending on implementation, this is either a rejection at RCPT TO time or a bounce generated after DATA acceptance.

The Headers Tell the Story

Every stage of the lifecycle adds headers to the message. Reading headers from bottom to top reconstructs the journey:

The Received: headers are the bread crumbs. Each one records the sending host, the receiving host, the protocol used (ESMTP, ESMTPS for TLS, ESMTPSA for authenticated+TLS), a queue ID, and a timestamp. See Anatomy of Email Headers for a full guide.

The Transactional Email Path

When an application sends email through a service like Mailer To Go, the lifecycle is slightly different:

1. Application calls the API. Your app sends a POST request with the message content, recipients, and metadata.
2. The service constructs the message. It builds the MIME structure, adds required headers (Date, Message-ID, List-Unsubscribe if applicable), and applies DKIM signing with your domain's key.
3. The service's MTA sends the message. The message is sent from the service's IP to the recipient's MX via SMTP on port 25, with STARTTLS.
4. The rest is identical. MX reception, authentication checks, content filtering, MDA delivery, and client retrieval all proceed as described above.

The key difference: your application never speaks SMTP directly. The API abstracts away the entire submission layer. But the message still traverses the same infrastructure, undergoes the same authentication checks, and is evaluated by the same spam filters.

Key Takeaways

• Email has six distinct stages: composition, submission, transfer, reception, delivery, and retrieval. Each stage involves different protocols and different actors.
• The envelope and the message are separate. MAIL FROM / RCPT TO (the envelope) can differ from the From: / To: headers (the message). This distinction matters for authentication, bounces, and Bcc.
• Most filtering happens at reception. The receiving MX is where authentication, reputation, and content are evaluated. This is the stage that determines inbox vs. spam.
• A 250 OK means accepted, not delivered to inbox. The receiving MX may still route the message to spam, or the MDA may reject it later (mailbox full, Sieve rules).
• Received: headers document the journey. Read them bottom-to-top to trace a message's path. They are the single most useful debugging tool for delivery problems.
• Every hop adds latency and risk. More hops mean more chances for failure, delay, or content modification (which can break DKIM signatures).

Further Reading

Related RFCs