Understanding the Email Delivery Stack: From MTA to Inbox

• June 2015
• Engineering Memo · External Release

The simple model is wrong. Email delivery is described in most introductory material as "sender sends, receiver receives" — a two-party exchange mediated by SMTP. The production reality is a seven-layer stack, each layer with its own technical requirements, failure modes, and monitoring signals. Operators who understand the stack as a whole — rather than as isolated components — diagnose delivery problems faster, configure infrastructure more effectively, and design systems that fail gracefully rather than catastrophically.

Seven layers, each with its own failure modes. This note maps the complete email delivery stack from application injection through inbox placement, explaining what each layer does, what can go wrong at that layer, and what signals indicate problems at that layer.

Layer 1: Application Injection

Layer 1 is where the message starts. The delivery stack begins at the application layer — the system that generates messages and submits them to the MTA for delivery. This is typically a marketing platform (MailWizz, Salesforce Marketing Cloud), a transactional sending service (a custom application that calls an SMTP API), or a CRM system with email integration. The application's role is to produce correctly formatted RFC 5322 messages and inject them into the MTA's queue through an SMTP injection connection.

Injection has its own checklist. The connection itself has configuration requirements: SMTP AUTH credentials (LOGIN or PLAIN mechanism), TLS negotiation for encrypted injection, and the source port (typically 587 for submission or a custom injection port). Injection failures at this layer produce connection refused or authentication failed errors that appear in the application's error logs, not in the MTA's delivery accounting log — because messages that fail at injection never enter the MTA queue.

Layer 1 fails loud. The diagnostic signal for Layer 1 problems: injection port unavailability (MTA is down or not accepting connections), authentication failures (SMTP AUTH credentials are incorrect), and TLS negotiation failures (certificate expired or cipher suite incompatibility). These are distinct from delivery failures — the application may report "failed to send" but the failure occurred before the message reached the MTA.

Layer 2: MTA Queue Management

Layer 2 begins quietly. Once injected, the message enters the MTA's internal queue. PowerMTA maintains separate queues per virtual MTA per destination domain — a key architectural feature that isolates traffic streams and prevents a queue problem at one destination from affecting others. Queue management decisions include: which virtual MTA handles the message (determined by the injection port and routing rules), what priority the message has within the queue (transactional messages may have higher priority than bulk campaign messages), and how long the message can remain in the queue before expiry (bounce-after configuration).

Queue problems are silent until they are not. Layer 2 problems manifest as: queue depth growing continuously (delivery rate below injection rate — a throughput capacity problem), messages expiring without delivery (bounce-after window too short, or ISP refusing all delivery attempts), and queue routing errors (messages going to the wrong virtual MTA). The accounting log and PowerMTA's real-time queue statistics (accessible through the web management interface) are the diagnostic tools for Layer 2.

Layer 3: DNS Resolution

Layer 3: DNS. Before establishing an SMTP connection to the recipient's mail server, the MTA must resolve the recipient domain's MX records to identify the receiving server's hostname, then resolve that hostname to an IP address. DNS resolution happens at every delivery attempt — it is not cached across attempts by default. DNS resolution failures at this layer produce delivery deferrals that appear as temporary failures in the accounting log even though no SMTP connection was made.

DNS fails in distinctive ways. NX domain (the recipient domain's DNS does not exist), no MX record (the domain exists but has no MX record — PowerMTA can be configured to attempt A record delivery in this case or to bounce immediately), DNS timeout (the DNS resolver is unreachable or slow), and DNSSEC validation failure (for domains using DNSSEC, a validation failure prevents resolution). DNS resolution problems at the recipient domain are not actionable by the sender — they indicate that the recipient domain has a configuration problem. PowerMTA's treatment of these (immediate bounce versus extended retry) depends on the domain block configuration.

Layer 4: TCP + TLS Connection

Layer 4: the wire. After DNS resolves the recipient MX server's IP address, the MTA initiates a TCP connection to port 25. A successful TCP three-way handshake is followed by TLS negotiation if both parties support it. TLS for SMTP delivery is now standard — Gmail, Yahoo, and Microsoft all support and prefer TLS for inbound connections, and some enforce it for senders they identify as bulk or authenticated senders.

TCP fails three ways. Layer 4 failures: TCP connection refused (the receiving server is not accepting connections on port 25 — either down or blocking this IP), TCP timeout (the server is reachable but not responding — network path issues), TLS handshake failure (certificate expired, cipher suite mismatch, or SNI requirements not met), and MTA-STS enforcement (the receiving domain has published an MTA-STS policy requiring TLS, and the TLS negotiation failed — the message must not be delivered in the clear per the policy).

MTA-STS adds a constraint. Mail Transfer Agent Strict Transport Security is increasingly published by large organisations that want to enforce TLS for inbound mail delivery. If a receiving domain has an MTA-STS policy and the sending MTA cannot negotiate a valid TLS connection, it must defer or bounce the message rather than deliver in the clear. PowerMTA supports MTA-STS validation — check that the configuration is current and handles MTA-STS policies for the domains in the recipient list.

Layer 5: SMTP Transaction

Layer 5 is the protocol itself. The SMTP transaction is the core protocol interaction: EHLO (the sender identifies itself), MAIL FROM (specifies the bounce/return address), RCPT TO (specifies the recipient), and DATA (transmits the message content). The receiving server's response to each command is a three-digit SMTP code — the codes documented in the SMTP error taxonomy note. Layer 5 is where most deliverability problems are visible in the accounting log: 5XX permanent failures, 4XX temporary deferrals, and the specific enhanced status codes that indicate reputation, authentication, and policy failures.

FCrDNS is the silent gate. The check happens at Layer 5 — the receiving server verifies that the EHLO hostname resolves to the sending IP address. The HELO/EHLO hostname in PowerMTA's virtual MTA configuration must match the PTR record for the sending IP for FCrDNS to pass. If the EHLO hostname is set to mail.yourdomain.com but the PTR record points to mail01.sendinghost.net, FCrDNS fails and the receiving server notes the inconsistency.

Layer 6: Authentication Evaluation

Acceptance is not delivery. After the message is accepted at Layer 5 (250 OK), the receiving server evaluates the message's authentication. This is a post-acceptance evaluation — the SMTP transaction is complete, the message is in the receiving server's queue, and the authentication evaluation happens within the receiving infrastructure. The authentication checks: SPF (did the sending IP match the authorised sources in the SPF record for the MAIL FROM domain?), DKIM (is there a valid DKIM signature that aligns with the From: domain?), and DMARC (do either SPF or DKIM pass in alignment with the From: domain?).

Always check the headers. Authentication evaluation results are recorded in the Authentication-Results header added to the message by the receiving server. They also appear in DMARC aggregate reports as daily pass/fail counts per source IP. A 250 OK at Layer 5 followed by authentication failure at Layer 6 does not cause the message to be rejected — it is already accepted. The authentication failure influences subsequent routing decisions at Layer 7.

Layer 7: Inbox Placement

Layer 7 decides everything visible. The final and most consequential layer — the post-acceptance routing decision by the receiving ISP's filtering systems. A message that reaches Layer 7 has been accepted (250 OK), has had its authentication evaluated (Layer 6), and is now being classified for routing: inbox, spam folder, promotions tab, or silently discarded by a post-acceptance filter (a rare but real outcome at some ISPs and corporate mail servers).

Convergence point. Layer 7 is where all the factors discussed throughout the operational note series converge: domain reputation, IP reputation, authentication quality, engagement history, complaint rate, content signals, and sending pattern consistency all contribute to the routing decision. This is why delivery rate (Layer 5 success) is not the same as inbox placement (Layer 7 outcome). A message that reaches Layer 7 is counted as "delivered" by the sending MTA — but where it lands within the recipient's mailbox is determined by ISP-internal systems that the sender cannot directly observe.

Tools are limited at Layer 7. The diagnostic tool is Gmail Postmaster Tools (for Gmail routing signals) and seed testing (for per-campaign inbox placement measurement). Neither provides complete visibility — Postmaster Tools shows domain-level reputation trends without per-campaign inbox placement data, and seed testing provides per-campaign data but with the seed-address bias limitations documented elsewhere. Together, they provide the best available approximation of Layer 7 outcomes for the sending programme.

Using the Stack Model for Faster Diagnosis

Diagnosis, not just description. The seven-layer model's operational value is in diagnosis. When a delivery problem is reported — "our emails aren't getting through" — the stack model provides a structured diagnostic path that identifies which layer the problem is at, rather than checking everything simultaneously.

Top-down works. Start at Layer 1: is injection working? Check application logs for SMTP submission errors. If injection is working (messages are in the MTA queue), move to Layer 2: is the queue processing? Check queue depth and bounce-after. If the queue is processing (delivery attempts are being made), move to Layer 3: is DNS resolving? Check for NXDOMAIN or DNS timeout errors in the accounting log. Continue through the layers until the failure point is identified. The layer where the failure occurs determines the remediation — a Layer 3 DNS failure requires different action than a Layer 5 5XX SMTP rejection, which requires different action than a Layer 7 inbox placement problem.

Faster, every time. This structured approach consistently produces faster root cause identification than unstructured investigation, because it eliminates all layers above the failure point from consideration. An operator who has confirmed that TCP connections succeed (Layer 4) and SMTP transactions complete with 250 OK (Layer 5) does not need to investigate DNS or queue issues — the problem is at Layer 6 (authentication) or Layer 7 (inbox placement). The stack model is the mental model that makes experienced email operators faster, not because they know more facts, but because they have a framework that directs investigation efficiently.

Cross-Layer Interactions That Create Difficult Problems

Cross-layer is where it gets hard. Some of the most persistent and confusing delivery problems arise from interactions between layers rather than failures at a single layer. Understanding these cross-layer interactions explains why some problems are difficult to diagnose even after individual layers appear to be functioning correctly.

Layer 3 → Layer 5 interaction: DNS caching and IP reputation. When a domain's MX record changes — for example, when a large ISP migrates its receiving infrastructure to new IP addresses — the MTA may continue attempting delivery to the old MX IP addresses if DNS caching is retaining stale records. The TCP connection may succeed (the old IPs may still be reachable for a period), but the SMTP transaction may produce unusual responses because the receiving infrastructure at the old IP is being decommissioned. This appears as intermittent Layer 5 failures that are not reproducible when tested directly but appear in production because cached DNS produces old IP targets for some delivery attempts.

Layer 5 → Layer 7 interaction: connection count reputation signals. The Layer 5 connection rate (how aggressively the MTA opens connections to the ISP per time window) is itself a Layer 7 reputation signal. An MTA that opens connections too aggressively — even if each individual SMTP transaction completes with 250 OK — is generating a sending pattern at Layer 5 that the ISP's Layer 7 filters classify as spam-like behaviour. The Layer 5 transactions appear successful, but Layer 7 inbox placement degrades. This is the retry pressure mechanism described elsewhere — the Layer 5 connection pattern is generating Layer 7 reputation signals that are only visible through Postmaster Tools, not through accounting log delivery rates.

Layer 6 → Layer 7 interaction: authentication quality as a routing signal. DMARC pass rate, DKIM key strength, and SPF alignment quality are Layer 6 measurements. But these measurements feed directly into the Layer 7 routing decision — a domain with 100% DMARC alignment pass rate at the highest DKIM key strength receives a different Layer 7 classification than a domain with 97% DMARC pass rate and 1024-bit DKIM keys. The Layer 6 authentication quality is an input to the Layer 7 classification algorithm, not just a compliance check. Improving authentication quality (upgrading DKIM key size, escalating DMARC policy, improving SPF alignment coverage) produces Layer 7 improvements that are visible in Postmaster Tools domain reputation trends over weeks and months.

Monitoring Architecture Aligned to the Stack

Effective monitoring covers every layer of the stack, with the right tool for each layer:

Layer 1 monitoring: application error rate on the SMTP injection connection. Alert on: injection port connectivity failure, authentication failure rate above 0%, sustained injection latency above expected threshold.

Layer 2 monitoring: PowerMTA queue depth per virtual MTA per ISP destination. Alert on: queue depth growing for more than 30 minutes during an active send window, queue depth exceeding 3× normal maximum for that time of day.

Layer 3 monitoring: DNS resolution failure rate in the accounting log (NXDOMAIN, timeout responses). Alert on: DNS failure rate above 0.5% for any destination domain, which indicates either the destination domain has DNS problems or the MTA's DNS resolver is experiencing issues.

Layer 4 monitoring: TCP connection failure rate and TLS negotiation failure rate by ISP. Alert on: connection refused rate above 2% at any major ISP (may indicate IP block), TLS failure rate above 0% (indicates certificate or cipher issue).

Layer 5 monitoring: accounting log delivery rate, deferral rate, and hard bounce rate by ISP — the primary operational metrics. Alert thresholds as documented in the deliverability audit note.

Layer 6 monitoring: DMARC aggregate report pass rates daily, Postmaster Tools authentication section weekly. Alert on: any source showing DMARC alignment pass rate below 99%.

Layer 7 monitoring: Gmail Postmaster Tools domain reputation daily, spam rate trend weekly, ISP-segmented engagement rate per campaign. Alert on: any domain reputation tier decline, spam rate above 0.08%.

Each layer warrants its own watch. This seven-layer monitoring architecture is thorough but not excessive — each layer requires different tools and different alerting thresholds, and the total monitoring investment is manageable within a daily operational cadence. The operators who maintain this monitoring discipline consistently detect and resolve problems at the earliest possible layer — catching Layer 2 queue depth issues before they become Layer 5 delivery failures, and catching Layer 6 authentication drift before it becomes a Layer 7 inbox placement problem. The stack model is both a diagnostic framework and an operational discipline — its value compounds over time as the monitoring it implies catches problems earlier, with lower remediation cost, than reactive monitoring that only detects the symptoms of advanced problems.

Practical Application: Stack Analysis for Common Scenarios

Scenario: "Delivery rate looks fine but open rates are declining." Layers 1–5 are functioning — injection, queue, DNS, TCP, and SMTP transactions are all working. The problem is at Layer 7. Investigation path: check Postmaster Tools domain reputation trend. Check DMARC aggregate reports for authentication drift (Layer 6 feeding into Layer 7). Check FBL complaint data for a recent campaign that may have elevated complaint rates. Check whether a new list segment was introduced recently. The open rate decline is a Layer 7 inbox placement indicator — the investigation is entirely within Layers 6–7.

Scenario: "Specific campaign has high deferral rate at Gmail but others are fine." This is a campaign-specific Layer 5 problem. Investigation path: check the accounting log for the specific campaign's Gmail deferral codes — are they rate-limit codes (421 4.7.0) or content/reputation codes (421 4.7.26)? Check whether the campaign was sent from the same virtual MTA as campaigns that performed well. Check whether the campaign used a different list segment or a higher injection rate. If the deferral codes are rate-limit codes and the injection rate was higher than usual, the campaign created a connection rate spike at Gmail (Layer 5 interaction with Layer 7).

Scenario: "Transactional messages delayed by 30–45 minutes." Investigation path: check the MTA queue depth (Layer 2) during the delay period — was a large campaign simultaneously running that was consuming the queue processing capacity? Check whether transactional messages are using a priority queue or are competing with campaign messages in the same queue. Check whether the delivery delay corresponds to greylisting events (Layer 3 / Layer 5 interaction) — if messages are being delivered successfully but 30–45 minutes after injection, greylisting at the destination is the most likely cause. Check the accounting log for first-attempt deferral followed by successful delivery on retry — the greylisting signature.

Each of these scenarios is resolved faster with the stack model than without it, because the model provides a hypothesis immediately: the symptom maps to specific layers, and the investigation focuses on those layers. Without the model, investigation is exploratory — checking random components without a guiding hypothesis. The stack model is not a guarantee of fast diagnosis, but it is the framework that makes systematic diagnosis possible. Operators who internalise it — who think in terms of layers when symptoms appear — consistently outperform those who investigate delivery problems ad hoc.

The seven-layer email delivery stack is a mental model, not a formal specification. Email does not technically have seven layers in the OSI sense — it operates over TCP/IP, uses SMTP, and the "layers" described here are functional groupings that reflect where different categories of problems occur and which data sources illuminate those problems. The model's value is not in technical precision but in operational usefulness: it organises the complex landscape of email delivery into a navigable structure that makes diagnosis, monitoring, and communication about delivery problems more efficient. For operators who manage email infrastructure professionally, the stack model is one of the core mental tools that distinguish experienced operators from beginners — not because of the knowledge it represents, but because of the thinking framework it enables.