How Email Delivery Actually Works

Email feels instant when it is working well, which is one reason so many people misunderstand what it is doing underneath. A person in Athens clicks send, another person in Berlin sees the message a few seconds later, and the whole thing looks like a direct conversation between two inboxes.

It is not. Email delivery is a store-and-forward network made of submission servers, queue managers, DNS lookups, SMTP sessions, policy engines, local delivery agents, mailbox stores, and later retrieval through IMAP or webmail. At each hop, one machine either accepts responsibility for the message or refuses it. Every acceptance changes who now owes the next step. Every refusal changes whether the sender should retry, rewrite, or bounce.

That model explains most of the odd things users and developers see in production. A 250 after DATA does not mean the recipient read the message. A greylisting 450 is not a hard failure. A message can pass SMTP delivery and still land in spam. A bounce goes to the envelope sender, not necessarily the visible From: address. A mail provider can accept one recipient in a multi-recipient transaction and reject another. A null reverse path on a bounce is not suspicious by itself. It is how the protocol prevents loops.

This article walks through the actual path. We will start with the split between submission and transfer, then look at the SMTP envelope, MX selection, queueing, retries, recipient filtering, mailbox delivery, and the traces operators read when something goes wrong.

Email Is A Store-And-Forward System, Not A Live End-To-End Socket

The core mental model is simple: email is a chain of custody.

A sender does not open one magical connection to the recipient's mailbox. The sender submits a message to a server that agrees to take responsibility for it. That server may hand the message to another server. That server may queue it, retry it later, or forward it to the final destination. Each hop is independent. The protocol is built to tolerate delay, intermittent reachability, and administrative boundaries between different organisations.

That design is old on purpose. SMTP was standardised in RFC 821 in 1982 and later revised into RFC 5321. It came from a world where links were slower, hosts were less reliable, and direct end-to-end reachability was not a safe assumption. The surprising part is not that email looks this way. The surprising part is how well this shape still fits the modern internet.

Suppose Eleni at a small accounting firm in Athens sends an invoice to a supplier at [email protected]. The path may look like this:

1. Eleni's mail client submits the message to her provider's submission server.
2. The provider's outbound MTA places the message in its queue.
3. The MTA resolves berlin-wholesale.example and learns its MX hosts.
4. The MTA opens an SMTP session to one of those hosts.
5. The recipient side accepts the message into its own inbound queue.
6. Local policy, malware checks, content checks, and mailbox rules run.
7. The message is written into Nikos's mailbox store.
8. Nikos later reads it through IMAP, JMAP, Exchange ActiveSync, or webmail.

Each stage has different failure semantics.

• Submission can fail because the user is unauthenticated or over quota.
• DNS can fail because the domain has no reachable MX path.
• Transfer can fail temporarily because the recipient is greylisting or rate limiting.
• Filtering can reject the message after looking at SPF, DKIM, DMARC, IP reputation, links, attachments, and local policy.
• Mailbox delivery can fail because the mailbox no longer exists or is full.

Once you see email as a relay network with durable queues, many confusing user-facing outcomes become normal protocol behaviour rather than weird bugs.

Submission Starts On A Different Boundary Than Delivery

The first important split is between message submission and message transfer.

A user's device normally does not deliver mail directly to every destination domain on the internet. It submits mail to a trusted service, usually called a Mail Submission Agent or MSA. That MSA authenticates the user, enforces local policy, and then hands the message to the provider's Mail Transfer Agent or MTA fleet for actual delivery.

Operationally, that means you should think of two different SMTP contexts:

• Submission from a user agent to its home provider, usually on port 587 with authentication and often STARTTLS
• Transfer between MTAs, usually on port 25 without user authentication but with host-level reputation and policy controls

A typical authenticated submission session looks like this:

220 submit.mail.athens-accounting.example ESMTP ready
EHLO laptop.office.local
250-submit.mail.athens-accounting.example
250-STARTTLS
250-AUTH PLAIN LOGIN
250 SIZE 52428800
STARTTLS
220 Ready to start TLS
EHLO laptop.office.local
250-submit.mail.athens-accounting.example
250-AUTH PLAIN LOGIN
250 SIZE 52428800
AUTH PLAIN AGVsZW5pQGF0aGVucy1hY2NvdW50aW5nLmV4YW1wbGUAc2VjcmV0
235 2.7.0 Authentication successful
MAIL FROM:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: Eleni <[email protected]>
To: Nikos <[email protected]>
Subject: June invoice
Date: Mon, 1 Jun 2026 08:14:22 +0300
Message-ID: <[email protected]>
 
Invoice attached.
.
250 2.0.0 Queued as 9F2A1C3D
QUIT
221 2.0.0 Bye

Several details matter here.

First, the user's laptop did not speak directly to Berlin. It spoke to its own provider.

Second, the 250 2.0.0 Queued as 9F2A1C3D at the end means the provider accepted the message into its submission or outbound queue. The provider now owns the next steps. It still has to resolve MX, connect outward, retry if needed, and potentially generate a bounce later.

Third, message submission is where many user-facing rules live.

• maximum message size
• allowed sender identities
• whether the authenticated user may submit for a given domain
• DKIM signing policy on outbound mail
• malware scanning of outgoing attachments
• rate limits on account abuse

This is why "my SMTP client got 250" does not mean "the recipient received it". It only means the first trust boundary accepted it.

Many providers also support implicit TLS on port 465 for submission, historically called SMTPS. The exact port matters less than the boundary: authenticated user submission is a different operational problem from cross-domain transfer.

The Envelope Decides Routing, The Headers Explain The Story

SMTP has two layers of addressing that people constantly confuse.

The envelope lives in SMTP commands such as MAIL FROM and RCPT TO. It is used for routing and for delivery status notifications.

The message headers live inside the DATA block. They contain visible fields such as From:, To:, Cc:, Subject:, Date:, and Message-ID:.

Those layers often line up, but they do not have to.

Here is a small example:

MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: Eleni <[email protected]>
To: Nikos <[email protected]>
Cc: Accounts Payable <[email protected]>
Subject: June invoice
Message-ID: <[email protected]>
Return-Path: <[email protected]>

The visible sender is Eleni. The envelope sender, which will receive bounces, is a specialised bounce-processing address. That is normal. Bulk mailers and transactional systems do this routinely because they need machine-readable delivery feedback.

This separation explains several everyday behaviours.

Bcc Is Envelope-Only Delivery

A blind carbon copy recipient appears in RCPT TO but not in visible headers. The message can be delivered to them even though no Bcc: line is shown to other recipients.

Bounces Follow The Envelope Sender

If the remote site later decides the address does not exist, the delivery status notification goes to the envelope sender, not to the From: header. That is why customer support teams are often confused when a bounce appears at [email protected] rather than in the human sender's inbox.

Mailing Lists Rewrite Different Fields For Different Reasons

A mailing list may preserve the visible From: line, rewrite the envelope sender, add List-Id, add Sender:, and insert Received: lines and other policy headers. The route taken by the message is an accumulation of these machine-facing changes, not just what the user typed in the compose window.

Authentication Checks Look At Specific Layers

SPF evaluates whether the sending host is authorised for the envelope sender domain. DKIM signs selected headers and the body. DMARC compares visible author identity against SPF and DKIM alignment. These are related but not identical claims. Mixing up the layers leads to wrong mental models and bad tooling.

The same split matters for error handling. If an MTA receives one message addressed to five recipients, it can accept some recipients and reject others in the same SMTP transaction. The message body may still be sent once. Delivery state then branches per recipient even though the headers are identical.

This is one reason mail software talks so much about queues, recipient maps, and transport status by address. The protocol routes delivery per envelope recipient, not per human conversation thread.

DNS MX Resolution Chooses The Next Hop

Once the outbound MTA has accepted responsibility, it has to discover where the recipient domain wants mail delivered.

That is a DNS problem first, not an SMTP problem.

For a domain like berlin-wholesale.example, the sender asks DNS for MX records:

$ dig MX berlin-wholesale.example
 
;; ANSWER SECTION:
berlin-wholesale.example.  3600 IN MX 10 mx1.berlin-wholesale.example.
berlin-wholesale.example.  3600 IN MX 20 mx2.berlin-wholesale.example.

An MX record contains a preference value and a host name.

• Lower preference values are tried first.
• Equal preference values are usually shuffled for basic load spreading.
• The target host names then need their own A and AAAA lookups.

If no MX records exist, RFC 5321 says the sender falls back to the domain's A or AAAA records as an implicit mail target. Many operators forget this and assume "no MX" means "undeliverable". It often does not.

Several operational constraints live here.

The MX Host Is A Host, Not An Alias Fantasy

The target of an MX record is expected to resolve to addresses. Using a CNAME there causes problems because mail delivery code expects a canonical host target. Some DNS software will let you publish bad data. That does not make it a good idea.

Sender Choice Is Local Policy Over Shared DNS Data

DNS publishes possible destinations. It does not dictate one universal algorithm. Most MTAs try the lowest-preference MX first, then fail over. Some remember historical failures. Some cache dead targets. Some prefer IPv6 first and fall back to IPv4. Some have transport maps that override normal DNS routing for selected domains.

DNS Failure Modes Become Delivery Outcomes

If DNS times out, returns SERVFAIL, or yields bogus data, the message often remains deferred, not bounced immediately. That is because many DNS failures are temporary. A broken authoritative name server in Amsterdam for ten minutes should not cause permanent loss of all incoming invoices.

Queueing Starts Before SMTP Starts

People often imagine that queueing begins only after a remote server responds. In practice, the outbound MTA may already queue mail while waiting for DNS, while rotating across multiple MX targets, or while backing off from repeated connection failures.

The MX lookup is also the first place where mail reveals its old, federated architecture. There is no central mail router that knows every inbox. The sender has to ask the recipient domain how it wants to be reached, every time the cache expires.

SMTP Delivery Is A Negotiated Conversation With Responsibility Shifts

After DNS provides a target, the sender opens an SMTP session to the receiving MTA. This is where responsibility moves from one queue to another.

A simplified server-to-server exchange might look like this:

220 mx1.berlin-wholesale.example ESMTP ready
EHLO out-01.mail.athens-accounting.example
250-mx1.berlin-wholesale.example
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 ENHANCEDSTATUSCODES
STARTTLS
220 Go ahead
EHLO out-01.mail.athens-accounting.example
250-mx1.berlin-wholesale.example
250-PIPELINING
250-SIZE 52428800
250 ENHANCEDSTATUSCODES
MAIL FROM:<[email protected]>
250 2.1.0 Sender ok
RCPT TO:<[email protected]>
250 2.1.5 Recipient ok
DATA
354 End data with <CR><LF>.<CR><LF>
[message bytes]
.
250 2.0.0 queued as 81C4B6A2
QUIT
221 2.0.0 Bye

The critical moment is the final 250 after the terminating dot.

That reply means the receiving MTA accepted responsibility for this recipient and queued the message or otherwise committed to downstream processing. It does not mean any of the following:

• the human recipient has read the message
• the message will land in the inbox rather than spam
• local delivery has already finished
• downstream mailbox indexing is complete

It means the remote SMTP server took custody.

That distinction matters because an SMTP receiver may reject at several different stages.

• At connection time, based on IP reputation or protocol policy.
• At MAIL FROM, because of sender policy.
• At RCPT TO, because the recipient does not exist or local policy blocks it.
• After DATA, because content scanning or DMARC enforcement decides the message is unacceptable.

The sender must interpret each response in the right place.

A 550 5.1.1 at RCPT TO means the address is invalid and further retries are pointless. A 450 4.2.0 after DATA means the receiver is temporarily refusing the message and the sender should queue it for another attempt.

One SMTP connection can also handle multiple recipients. A receiver may accept three and reject two. The sending MTA then has to split delivery state by recipient, which is why queue software tracks per-recipient status internally even when the original message body is shared.

If you run Postfix, Exim, Exchange, Haraka, or a cloud mail transfer fleet, this is the part where queue IDs, delivery records, and bounce generation become central. The protocol is small. The operational machinery around it is not.

Temporary Failures Are Normal, And Retries Are Part Of The Protocol

A lot of internet software treats delay as failure. Email cannot.

A receiving mail system may be busy, rate limited, under maintenance, temporarily suspicious of a new sender, or waiting for a downstream mailbox store to recover. SMTP handles this with temporary failures, typically 4xx status codes.

Greylisting is the classic example. A recipient sees a triplet such as sender IP, envelope sender, and recipient address for the first time, returns a temporary failure like 450 4.7.1, and waits to see whether the sender retries later. Real MTAs do. Many spam bots historically did not.

An actual failure sequence might look like this:

MAIL FROM:<[email protected]>
250 2.1.0 Sender ok
RCPT TO:<[email protected]>
450 4.7.1 Please try again later

From the sender's perspective, this is not a bounce. It is a defer.

A reasonable outbound queue manager will then:

1. record the temporary failure and the remote text
2. keep the message in its queue
3. schedule another attempt after a backoff interval
4. possibly try another MX host if policy allows
5. keep retrying until queue lifetime expires

Typical retry policy is implementation-specific, but the pattern is consistent: immediate retry is rare, intervals grow, and messages eventually age out. Postfix defaults, Exchange transport queues, and cloud providers all differ in exact timing, but the underlying logic is the same.

This is why users sometimes see "message delayed" notices hours before any hard bounce. The sender is still doing exactly what the protocol expects.

Operators read these states in logs, not in UI myths. A Postfix defer might look like this:

Jun 01 08:17:04 out-01 postfix/smtp[24177]: 9F2A1C3D: to=<[email protected]>, relay=mx1.berlin-wholesale.example[2001:db8:44::25]:25, delay=142, delays=0.2/0.01/120/22, dsn=4.7.1, status=deferred (host mx1.berlin-wholesale.example[2001:db8:44::25] said: 450 4.7.1 Please try again later)

The parts worth reading are:

• queue id 9F2A1C3D
• destination recipient
• remote relay host
• DSN class 4.7.1
• status=deferred
• the exact remote text

That one line usually tells an experienced operator more than three pages of helpdesk paraphrase.

Retries also interact with MX preference. If the primary MX is down, the sender may try the lower-priority backup MX. If the backup only accepts and queues mail but then forwards slowly to the primary, the sender may see success while the recipient sees delay. That is still correct behaviour. Responsibility moved. Final user experience is a later question.

STARTTLS Protects SMTP Hops, Not The Whole Message Lifetime

People often hear that email uses TLS and then mentally promote that into a guarantee that the message stayed encrypted from sender to recipient inbox. Sometimes that is close enough for a casual explanation. Mechanically, it is wrong.

SMTP transport security is usually hop-by-hop.

When one MTA connects to another, they may negotiate STARTTLS and wrap that TCP session in TLS. That protects the bytes on that network hop from passive interception and some active tampering. It does not mean the message stays opaque to every server that handles it. Each MTA that accepts the message can usually inspect it in the clear because that server is one endpoint of its own TLS hop.

That means these two statements can both be true:

• the SMTP session from Frankfurt to Berlin used TLS
• the provider in Frankfurt could still scan the message body for malware or policy

That is not hypocrisy. It is the expected consequence of hop-by-hop transport protection.

The SMTP conversation shows this clearly:

220 mx1.berlin-wholesale.example ESMTP ready
EHLO out-01.mail.athens-accounting.example
250-mx1.berlin-wholesale.example
250-STARTTLS
250 SIZE 52428800
STARTTLS
220 Go ahead
[TLS handshake happens here]
EHLO out-01.mail.athens-accounting.example

The sender sees 250-STARTTLS, upgrades the transport, and then continues SMTP inside the encrypted channel. That protects this one leg. If the message later moves from the recipient edge to a filtering tier, and from there to a mailbox tier, those are separate trust boundaries with their own internal controls.

Historically, SMTP TLS was opportunistic. If both sides supported it, great. If not, mail still flowed in cleartext. That improved compatibility across a messy internet, but it also meant downgrade risk and inconsistent security posture. Modern policy layers such as MTA-STS, DANE for SMTP, and TLS reporting try to tighten this by letting domains publish stronger expectations about transport security and certificate validation.

Those mechanisms matter because SMTP is federated. The sender is often delivering to a server it has never seen before and may not trust by default. Publishing policy through DNS or HTTPS lets the recipient domain say, in effect, "when you bring me mail, this is the TLS posture I expect".

Even then, transport TLS is not the same thing as end-to-end message secrecy.

• If the sender's provider signs or scans the message, it sees the plaintext.
• If the recipient provider filters the message, it sees the plaintext.
• If a compliance archive, journaling system, or secure mail gateway is in the route, that system may also see the plaintext.

True end-to-end secrecy in email lives above SMTP, in systems such as S/MIME or OpenPGP, and those are far less universal than TLS on SMTP hops. Most real-world email is transport-protected across many legs, not cryptographically opaque to every intermediary.

This distinction becomes important in audits and incident response. An organisation may correctly say "all inbound and outbound SMTP sessions require TLS" and still also say "the mail gateway scans attachments and DLP rules inspect message content". Those are compatible claims because the gateway is a trusted endpoint for one transport hop, not a passive bystander.

So when someone asks whether email was encrypted, the precise answer is usually: which leg, and against whom?

INS.POST 408:

Forwarding, Aliases, And Mailing Lists Rewrite Delivery Mid-Flight

The route to a mailbox is often not the route the original sender thought it was taking.

Recipient domains frequently rewrite delivery through aliases, forwarding rules, shared mailboxes, helpdesk systems, and mailing lists. SMTP is designed to cope with that, but each rewrite complicates trust, error handling, and debugging.

Start with the simplest case: an alias.

Suppose [email protected] is an alias that expands to three real mailboxes and one external archival system. The inbound MTA may accept one recipient during SMTP, then expand it internally into four final destinations. Delivery state now fans out after the public SMTP exchange is over.

That matters because final success is no longer one bit.

• one mailbox may exist and accept the mail
• one may be over quota
• one external forward target may defer temporarily
• the archive connector may be down

Good mailbox systems track those outcomes separately. Weak ones collapse them and create mystery.

Forwarding to another domain is even trickier. If Berlin forwards Nikos's mail to a hosted mailbox in Amsterdam, the Berlin system becomes a new sender in SMTP terms. That has consequences for authentication and reputation. SPF, for example, checks whether the forwarding host is authorised for the original envelope sender domain. Usually it is not. This is one reason forwarding and SPF have always had a tense relationship.

Operators built workarounds such as Sender Rewriting Scheme, or SRS, which rewrites the envelope sender on forwarded mail so bounces can return correctly without pretending the forwarder is the original sender. The visible From: header may remain untouched while the transport envelope changes under it.

Mailing lists add another layer.

A list manager may:

• replace the envelope sender
• prepend a subject tag
• add List-Id, List-Post, and archive headers
• append a footer
• rewrite the visible From: field for DMARC compatibility
• send one copy to hundreds or thousands of recipients

Those changes are not cosmetic. They can invalidate DKIM signatures if signed headers or the body are modified. They can change how DMARC is evaluated. They can alter bounce handling, unsubscribe flows, and complaint processing. Modern list software therefore has to act not only like a bulk sender but also like a careful policy translator between the original author and many recipient domains.

This is one reason ARC, Authenticated Received Chain, was introduced. ARC lets intermediaries preserve evidence of upstream authentication results when the message is forwarded or modified in a way that would otherwise break direct downstream evaluation. It does not magically solve trust. It gives the next receiver more context.

From a delivery-debugging perspective, forwarding means that the first domain's 250 accepted may only prove that the message reached an intermediate stop. The final user's mailbox may still depend on another MX lookup, another SMTP session, another filtering stack, and another queue. Users describe this as "mail forwarding is flaky". Mechanically, it means one delivery path became two.

This is also why a helpdesk address that pipes mail into a ticketing system can behave differently from a normal personal mailbox. The SMTP edge may accept the message correctly while the application that parses it later rejects the body, strips an attachment, or drops it because of ticket-matching rules. Once again, transport success and application success are separate states.

Forwarding is not an edge case. It is one of the reasons email remains operationally subtle even when the SMTP transcript itself looked fine.

Authentication And Reputation Decide Whether Acceptance Means Inbox

Cross-domain SMTP delivery answers one question first: will the receiving MTA accept responsibility for this message at all?

Inbox placement answers a different question: after acceptance, how trustworthy and desirable does the message look?

This distinction matters because modern mail systems do far more than route bytes. Before, during, and after SMTP acceptance, the recipient side evaluates signals such as:

• SPF alignment for the envelope sender domain
• DKIM signatures over selected headers and body chunks
• DMARC policy for visible author identity
• reverse DNS and forward-confirmed host naming
• IP reputation and recent complaint rates
• TLS posture and policy where configured
• historical sender behaviour
• URL reputation in the body
• attachment type and malware results
• language, formatting, and content heuristics

SPF, DKIM, and DMARC deserve their own deep treatment, but at this layer it is enough to understand their role. They are policy inputs into recipient trust decisions. They do not transport the message. SMTP already did that.

This is why two seemingly contradictory statements can both be true:

• "The remote server accepted the mail."
• "The recipient never saw it in the inbox."

Acceptance may mean the remote MTA queued the message and later put it in spam, quarantine, or a policy hold. Large mailbox providers in particular separate SMTP edge acceptance from later classification decisions performed by deeper filtering systems.

Some systems reject during SMTP instead, especially for obvious failures such as nonexistent recipients, known malware, or strong DMARC policy failures. Others accept first because they want full message inspection or centralised policy handling. Implementation differs.

A simplified trace may add headers like these after acceptance:

Authentication-Results: mx1.berlin-wholesale.example;
    spf=pass smtp.mailfrom=mailer.athens-accounting.example;
    dkim=pass header.d=athens-accounting.example;
    dmarc=pass header.from=athens-accounting.example
X-Spam-Score: 1.2
X-Spam-Status: No

Those lines are not part of SMTP transport itself. They are evidence produced by the receiving side while deciding what to do next.

The practical consequence is straightforward. If you are debugging deliverability, you need to ask two separate questions.

1. Did the message transfer succeed from one MTA to another?
2. Once accepted, what classification path did it take?

Teams that collapse those into one vague word, "delivered", lose hours.

Local Delivery Writes To A Mailbox Store, Not To "The User"

Once the receiving side accepts the message, the next step is usually local delivery into a mailbox system. That is another boundary people gloss over.

The SMTP edge is often not the mailbox store. Large providers split these roles aggressively. One system handles internet-facing SMTP, another runs filtering, another writes mailbox storage, another serves IMAP or webmail, and another builds search indexes and conversation views.

Even on smaller systems, the inbound MTA often hands the message to a Local Delivery Agent or an LMTP service.

A common Unix-style path is:

1. SMTP edge accepts the message.
2. Content and policy filters run.
3. Recipient aliases and forwarding rules are expanded.
4. Final mailbox delivery uses a local transport, often LMTP.
5. The mailbox is updated in Maildir, mbox, or a proprietary store.
6. Indexes or caches are updated for clients.

LMTP, the Local Mail Transfer Protocol, looks like SMTP but is designed for final local delivery and can return per-recipient status after the message body. Systems like Postfix and Dovecot use this pattern because it maps well onto per-mailbox outcomes.

Storage format matters operationally.

Maildir

Maildir stores each message as a separate file, usually under tmp/, new/, and cur/. That reduces lock contention and makes atomic file moves easy.

mbox

mbox stores many messages in one file. It is simpler conceptually but trickier under concurrency and large mailbox workloads.

Proprietary Stores

Cloud providers, Exchange, and large mailbox platforms usually store messages in databases or custom blob and index systems rather than classic filesystem formats.

Whatever the storage engine, the important point is this: SMTP delivery success usually means "the receiving mail system accepted responsibility", not "the user has rendered the message on screen".

A user still needs a retrieval path.

• IMAP sync on a phone
• webmail reading from a mailbox API
• Exchange ActiveSync on older clients
• JMAP on newer systems

Those later protocols handle folder state, seen flags, conversation threading, and multi-device sync. SMTP knows none of that. SMTP moved a message into the recipient domain. Mailbox software and retrieval protocols expose it to a person.

This separation also explains delayed visibility bugs. The mail may be in the mailbox store while search indexing is behind, or on webmail but not yet on a mobile client whose IMAP sync stalled. Those are real user problems, but they are not SMTP transport failures.

Bounces And DSNs Follow Strict Rules Because Loops Are Expensive

When final delivery becomes impossible, the system has to report failure somewhere. That is the job of a Delivery Status Notification, or DSN, described in RFC 3464 and related standards.

A bounce is itself an email message, but it follows special rules.

The most important one is the null reverse path. A proper bounce is sent with:

MAIL FROM:<>

The empty envelope sender prevents bounce loops. If a bounce itself cannot be delivered, the receiving side must not generate another bounce to the bounce, and then another to that, forever.

The DSN goes to the original envelope sender, not necessarily to the visible author in the headers. That is why well-run mailing platforms use structured bounce addresses such as:

MAIL FROM:<[email protected]>

The +4819 token lets the sender map later DSNs back to one specific outbound message or campaign.

A DSN body contains machine-readable fields as well as human text. For example:

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx1.berlin-wholesale.example
Diagnostic-Code: smtp; 550 5.1.1 <[email protected]> User unknown

Those fields matter because not all failures are alike.

• 5.1.1 usually means address does not exist.
• 5.2.2 often means mailbox full.
• 4.4.1 suggests network or connection trouble.
• 4.7.1 often means policy deferral or temporary rate control.

Backscatter happens when a server accepts unauthenticated mail with a forged envelope sender and later bounces it to an innocent third party. Good receiving systems try hard to reject bad mail during SMTP instead of accepting it and generating collateral damage later.

This is one reason strong SMTP-time rejection is preferable when the server already knows the message is unacceptable. Once you accept responsibility, the next steps become your problem.

The opposite mistake also exists: silently discarding mail without a DSN where policy and safety would allow a rejection. Large providers make different trade-offs here, especially under active abuse. The important point is to be precise about the stage. A rejection during SMTP, a later DSN, and a silent spam-folder placement are three different operational outcomes.

Operators Debug Delivery By Reading Traces, Queue State, And Remote Replies

When a user says, "I sent the message and they never got it", the right response is not to guess. It is to reconstruct the path.

The main tools are boring and extremely effective.

Start With The Outbound Queue And Logs

Find the queue id at submission time. Follow its log lines. See whether the message is still queued, deferred, bounced, or marked delivered to a remote host.

On a traditional Postfix host, examples include:

postqueue -p
postcat -q 9F2A1C3D

The first shows whether the message is still in queue. The second prints the queued message and metadata for one queue id.

Check DNS From The Sender's Point Of View

Verify that MX resolution works and that the target hosts resolve to usable A or AAAA addresses.

dig MX berlin-wholesale.example
dig A mx1.berlin-wholesale.example
dig AAAA mx1.berlin-wholesale.example

If DNS is broken, SMTP never had a fair chance.

Read The Received: Chain In The Right Direction

Each relay prepends its own Received: header, so the newest hop is at the top and the earliest trustworthy route is lower down. Analysts regularly read this backwards and invent stories the trace does not support.

A typical path might show:

Received: from out-01.mail.athens-accounting.example by mx1.berlin-wholesale.example
Received: from submit.mail.athens-accounting.example by out-01.mail.athens-accounting.example
Received: from laptop.office.local by submit.mail.athens-accounting.example

That tells you the message reached the recipient domain's MX, which is a very different conclusion from "the sender's provider accepted it".

Separate Transport Success From Inbox Placement

If the remote MX accepted the message, the next question is whether spam filtering, quarantine, mailbox rules, or alias expansion changed where it landed. That may require the recipient side to inspect mailbox logs, Authentication-Results, Sieve actions, or quarantine systems.

Use SMTP Test Tools Carefully

Tools like swaks, raw openssl s_client -starttls smtp, or provider-specific delivery consoles let operators reproduce sessions and observe exact replies. They are useful when you need to confirm protocol behaviour rather than trust screenshots from a GUI.

Look For Timing, Not Just End States

A message that arrived twelve minutes late is a different incident from one that never arrived. Queue delay fields, retry timestamps, and the gap between Date: and final Received: lines often identify greylisting, DNS trouble, rate limiting, or a slow mailbox backend.

This is why experienced mail operators sound unusually literal. They ask for the envelope sender, recipient, exact timestamp, queue id, full headers, and the remote reply text. Those are not obsessive details. They are the shortest path to the real mechanism.

Email Still Works Because It Assumes Delay, Partial Failure, And Independent Operators

Email is one of the oldest large-scale internet application protocols still in daily use, and it is full of scars.

It has accumulated spam defences, authentication layers, policy signalling, mailbox abstractions, and provider heuristics far beyond the original SMTP core. Delivery can be delayed by greylisting, blocked by reputation, reshaped by forwarding, and hidden by mailbox classification. From the outside that looks messy.

Underneath, the core design is still strong.

• It does not require the recipient to be online right now.
• It lets each administrative domain publish its own delivery targets.
• It uses durable queues instead of pretending the network is always available.
• It treats temporary failure as a first-class state.
• It separates user submission, inter-domain transfer, and mailbox retrieval into distinct problems.

That is why a message can leave a laptop in Athens during a fibre cut, sit in a queue in Frankfurt, retry against a recipient MX in Berlin, pass through spam checks, and appear in a mailbox long after the original sender closed the lid and went home.

If you want one sentence to keep in your head, make it this one: email delivery is not one action. It is a sequence of custody transfers, each with its own rules, and the system works because every transfer is explicit about who now owes the next step.