Learning Objectives

By the end of this module, you will be able to:

1. Name and describe the role of each component in the email delivery chain: mail user agent (MUA), mail submission agent (MSA), mail transfer agent (MTA), mail delivery agent (MDA), gateway, relay, filter, and recipient system.
2. Explain the difference between SMTP submission and SMTP relay, and identify which ports and authentication requirements apply to each.
3. Distinguish the SMTP envelope (MAIL FROM / RCPT TO) from the visible message headers (From / To), and explain why this distinction is the single most important concept in email troubleshooting and anti-spoofing analysis.
4. Walk through a live SMTP conversation (EHLO → MAIL FROM → RCPT TO → DATA → response) and identify where a failure could occur at each stage.
5. Interpret SMTP response codes by class (2xx, 4xx, 5xx) and correctly distinguish a temporary deferral from a permanent failure.
6. Read a non-delivery report (NDR/bounce) and extract the failing recipient, the responsible hop, and the stated reason.
7. Explain store-and-forward behavior and why a message can be "in flight" for a period of time without being lost.
8. Identify a message's Message-ID, correlate timestamps across hops, and account for time zone differences when reading a header trace.
9. Describe MIME structure well enough to explain why an attachment might not render, why an email might display incorrectly, or why an attachment might be miscategorized by a filter.
10. Distinguish internal, inbound, and outbound mail flow and explain why each is diagnosed differently.

Key Terminology

MUA (Mail User Agent)

The email client the end user interacts with (Outlook, Gmail web client, Apple Mail). Composes and submits messages; renders received messages.

MSA (Mail Submission Agent)

The server that accepts a message from an MUA, typically on port 587 or 465, usually requiring authentication.

MTA (Mail Transfer Agent)

A server that relays SMTP traffic between systems. A message may pass through several MTAs before delivery.

MDA (Mail Delivery Agent)

The component that places a message into the recipient's actual mailbox store.

Gateway

An MTA specifically positioned to apply policy — filtering, encryption, DLP — usually at the boundary between the customer's environment and the internet.

Relay

An MTA forwarding a message on behalf of another system, not as the final destination.

Envelope

The SMTP-level addressing (MAIL FROM, RCPT TO) used for routing and bounce handling. Not visible to the end user.

Header (visible)

The From:, To:, Cc:, Subject: fields inside the message itself. Can differ from the envelope.

Store-and-forward

The model where each MTA fully receives and queues a message before attempting to forward it.

NDR / bounce

A non-delivery report generated by an MTA explaining why a message could not be delivered.

MIME

Multipurpose Internet Mail Extensions — lets one message carry multiple parts with distinct content types and encodings.

Lesson

Email feels instantaneous to the people who use it, but nothing about it actually is. Every message you'll ever investigate travels through a chain of discrete systems — and your job, almost without exception, is to work out which link in that chain is responsible for whatever the customer is reporting. That's impossible if you don't know what each link actually does. This module builds that mental map, plus the handful of foundational facts (the envelope/header split above all) that every later module assumes you already have cold.

1.1 The Delivery Chain, Piece by Piece

Start with the shape of the whole journey. When someone hits "send," their message does not travel directly to the recipient — it hops through a sequence of purpose-built systems, each of which can succeed, delay, modify, or reject it.

Walk the chain left to right:

• MUA → MSA (submission). When a user hits send, their client authenticates to a submission server — typically the customer's own outbound relay, or Microsoft 365 / Google Workspace's submission endpoint — on port 587 (STARTTLS) or port 465 (implicit TLS). This step always requires authentication; an open, unauthenticated submission endpoint is itself a misconfiguration worth flagging on sight.
• MSA/MTA → MTA (relay). From there the message is relayed MTA to MTA, using port 25, until it reaches the MTA responsible for the recipient's domain (found via the domain's MX record — Module 3). Every MTA hop can add headers, apply policy, and choose to accept, defer, or reject.
• MTA → gateway. In a secure-email-gateway or API-based-security deployment, one or more of these hops is the security product itself, or the product intercepts/copies the message via API after M365/Google has already accepted it. Which model is in play changes exactly where in the chain scanning happens — that's the subject of Module 2, and it's the first thing to pin down on any mail-flow ticket.
• MTA → MDA (final delivery). The last MTA responsible for the recipient's domain hands the message to an MDA, which writes it into the actual mailbox store. This is where "delivered" becomes true in the strictest sense — a message can be accepted by a domain's border MTA and still fail later, at the MDA step. That gap is exactly why "the trace says delivered but the user doesn't have it" is one of the most common ticket shapes you'll see.

1.2 Submission vs. Relay vs. Delivery

Customers use these three words interchangeably. You can't afford to — they describe different points in the chain, governed by different rules, and diagnosed with completely different steps.

• Submission is an authenticated act by a known sender, submitting a new message for the first time (RFC 6409). It always requires authentication.
• Relay is one MTA forwarding a message it did not originate, on behalf of another system, toward the next hop. Relay between trusted systems is expected and normal (e.g., a customer's on-prem Exchange relaying outbound through the security gateway). Relay from unauthenticated, untrusted sources is an "open relay" — a serious misconfiguration and a common abuse vector.
• Delivery is the final act: the last MTA in the chain handing the message to the MDA for storage in the recipient's mailbox.

Here's why the distinction is a working tool, not trivia: a ticket that says "mail isn't sending" could mean the user can't submit (auth failure at the MSA), the message is stuck in relay (queued at an intermediate MTA), or the message was relayed successfully but never delivered (rejected or discarded at the final hop). Each of those needs a different first move. Before you touch any tooling, your first triage question on any "not sending" ticket should always be: which of these three is actually failing?

1.3 The SMTP Conversation

Underneath every hop is a literal, human-readable text conversation between two MTAs. Being able to read one — live, or reconstructed from logs — is a foundational skill you'll use in nearly every investigation. Here's a complete one, annotated:

Read it line by line, because each line is a place something can go wrong:

• EHLO/HELO identifies the sending system and negotiates capabilities (STARTTLS, SIZE, AUTH, 8BITMIME). A missing or mismatched EHLO hostname is a common reputation/deliverability flag — usually not a hard failure by itself, but worth noting.
• MAIL FROM is the envelope sender, also called the Return-Path once accepted. This is not necessarily what the recipient sees in their "From" field — a fact that underlies SPF, most spoofing analysis, and most "why does this look wrong" tickets. Hold onto this; it recurs constantly in Modules 4 and 5.
• RCPT TO is the envelope recipient. A single conversation can succeed for one recipient and fail for another — a frequent source of "some people got it, some didn't" tickets.
• DATA streams the actual message content. A rejection after DATA (a 5xx on the final .) means the receiving system read and evaluated the full content — including any filtering — before rejecting. That's a fundamentally different situation from a rejection at MAIL FROM or RCPT TO, before content was ever seen.
• The final response — the "queued as ..." string — is the receiving MTA's local queue ID. Useful for the customer's own postmaster, but generally not visible to the security product beyond that hop.

1.4 Envelope vs. Visible Headers — the Core Distinction

A message carries two separate identity systems that most end users have never heard of and conflate constantly:

These do not have to match, and often legitimately don't. A mailing list, for example, commonly sends with an envelope sender that's the list's bounce-handling address while the visible From: shows the original poster — nothing wrong there. A spoofed phishing message, on the other hand, often carries a completely unrelated envelope sender while the visible From: is forged to impersonate someone the recipient trusts.

The practical consequence: if you conflate "envelope sender" and "the From address the user sees," you will misdiagnose SPF results, misjudge spoofing, and give customers wrong explanations — with real consequences, since those explanations sometimes get relied on for security decisions. Whenever you look at authentication results, force yourself to name which identity each mechanism actually validated before drawing a conclusion.

1.5 SMTP Response Codes

The extended status code (the X.Y.Z after the 3-digit code — RFC 3463) is often more diagnostically useful than the 3-digit code alone. A 550 5.7.1 ("rejected as spam") is a categorically different investigation from a 550 5.1.1 ("user unknown"), even though both start with "550." Get in the habit of reading both.

1.6 Non-Delivery Reports (NDRs)

An NDR is generated by whichever system gave up on delivery, and is sent to the envelope sender (Return-Path) — not necessarily the visible From address, which is exactly why 1.4 matters here too. When you read one, extract:

1. The failing recipient address (may differ from what the customer reports, if it was a distribution-list expansion).
2. The responsible hop — the NDR usually names the reporting server.
3. The stated SMTP code and extended status code.
4. The literal diagnostic text — often the most useful part, and the part that frequently gets cut off when customers forward NDRs as screenshots instead of the original message.

1.7 Store-and-Forward Behavior

SMTP is store-and-forward, not a live end-to-end stream. That means a message can be legitimately "in flight" — fully accepted by one hop, not yet attempted by the next — for a meaningful stretch of time, and that's normal, not a fault. It also means "the message isn't in the inbox yet" and "the message is lost" are two different claims. The first diagnostic move for any non-delivery report is always to determine which of the chain's hops last touched the message, and what it did with it (see Module 12, Troubleshooting Methodology).

1.8 Message-ID, Timestamps, and Hops

Every properly formed message carries a Message-ID: header, generated once by the originating system and preserved — not regenerated — as the message transits hops. That makes it the single most reliable correlation key across systems: M365 message trace, Google log search, the security product's own logs, the customer's on-prem MTA logs. Get in the habit of capturing the Message-ID first, before anything else, at the start of any investigation.

Each Received: header records a timestamp in the timezone of the reporting server — very often not UTC and not the customer's local time. Comparing timestamps at face value, without normalizing to one timezone first, is a common analysis mistake that can make a message look "delayed by hours" when the real delay is a timezone misread. Always convert every Received: timestamp to a single reference timezone — UTC is recommended — before calculating hop-to-hop delay.

1.9 MIME Structure (Support-Relevant Level)

A message isn't a single blob of text — it's a MIME tree. A typical HTML email with an attachment is structured like this:

A few support-relevant consequences of this structure:

• A filter or the security product may reach different decisions depending on which MIME part it inspects — a message that looks clean as text/plain can carry a materially different message in text/html. This is a known phishing technique, covered fully in Module 9.
• Attachment "type" for filtering purposes is normally determined by the declared Content-Type and/or file signature — not simply the file extension. A customer asking "why was a .docx blocked, it's not an .exe" often has a mismatched Content-Type or an embedded object worth explaining plainly.
• Character-encoding issues (e.g., a Content-Transfer-Encoding: base64 part misread as quoted-printable) cause garbled-text tickets that are a MIME parsing problem, not a security or delivery problem. Knowing the structure lets you correctly triage these away from a threat investigation instead of chasing the wrong thing.

1.10 Internal vs. Inbound vs. Outbound Mail Flow

These three flows are diagnosed differently and are often owned by different systems entirely — always identify which one you're looking at before choosing tools.

• Inbound — external sender → the customer's environment. Most threat-detection scanning is concentrated here, and DNS/authentication analysis (Modules 3–4) is used most heavily.
• Outbound — customer's environment → external recipient. Concerned more with the customer's own sender reputation, outbound DLP, and encryption policy than with inbound threat detection.
• Internal — sender and recipient both inside the customer's own environment (mailbox to mailbox, same tenant). Internal mail may or may not transit the security product at all, depending on deployment model (Module 2) — a frequent source of "why wasn't this internal phishing test scanned" tickets. The honest answer often depends on the deployment architecture, not a product defect.

Hands-On Lab

Scenario-Based Exercise

Knowledge Check

Answer each question yourself before expanding it.