Email Delivery Flow

Email delivery is a store and forward system. Unlike a live chat message, an email does not require the sender and recipient servers to be online at the same moment. The message can be accepted, queued, relayed, filtered, and finally placed in the recipient's mailbox later. That design is why email is resilient across organisations, but it also means delivery quality depends on many policy checks beyond simple transport success.

From mail client to sender's server

A user composes a message in a mail client or web app. When they press send, the client usually submits the message to an outgoing mail server using SMTP submission, often on port 587 with authentication. The outgoing server becomes responsible for delivery from that point.

The server may add headers, apply rate limits, and queue the message if it cannot deliver immediately. Queues are normal. Email systems are designed to retry for a period rather than failing permanently at the first network problem.

Finding the recipient server

To deliver the message, the sender's mail transfer agent looks up the recipient domain's MX records in DNS. Those records identify which servers accept mail for that domain. The sender then opens an SMTP connection to one of those hosts and tries to hand over the message.

The receiving server can accept, temporarily defer, or permanently reject it. A temporary failure, such as a greylisting policy or transient network issue, leads to later retries. A permanent failure, such as a nonexistent recipient, usually triggers a bounce.

Filtering before inbox placement

Acceptance by the recipient domain is not the same as inbox delivery. Modern mail systems perform spam filtering, malware scanning, content checks, and sender reputation analysis before deciding where the message belongs. Authentication standards also matter. SPF checks whether the sender is allowed to send from the claimed domain. DKIM verifies a cryptographic signature attached to the message. DMARC ties policy to those checks.

Messages that fail these signals are more likely to be quarantined or rejected, even if the SMTP exchange itself was technically correct. That is why bulk email systems spend so much effort on domain reputation, authentication records, and complaint handling.

Mailbox storage and retrieval

Once accepted and classified, the message is stored in the recipient's mailbox. The user later retrieves it with IMAP, POP3, or a webmail interface. Delivery and reading are separate concerns. A message can be delivered successfully and still go unread.

Failure modes that operators care about

Email is full of edge cases: forwarding can break SPF, mailing lists can alter content and affect DKIM, attachment scanning can delay delivery, and a receiving system may silently place a message in spam rather than rejecting it outright. Large senders therefore monitor not only SMTP acceptance rates but also inbox placement and complaint rates.

Email delivery works because SMTP, DNS, and mailbox protocols divide responsibility cleanly. The cost of that openness is policy complexity. Sending mail is easy. Delivering it reliably to the inbox, at scale and with good reputation, is a much stricter operational discipline.