How email delivery works

Updated: Oct 28, 2026

Email moves through several systems. A sending client submits a message to a mail server, which looks up the recipient domain’s mail records and transfers the message to a receiving server. The recipient’s app later retrieves or synchronises it. Every step in that chain is a place where a message can be delayed, rejected, filed as spam or forged, which is why a basic map of the journey is useful both for people who receive email and for anyone who runs a domain.

From your outbox to the recipient’s server

Suppose anna@example.org writes to ben@example.com. The journey looks like this:

1. Submission. Anna’s mail app hands the message to her provider’s outgoing server, authenticating with her account credentials. This uses SMTP, the same protocol that has moved email since the 1980s, wrapped in TLS today.
2. Lookup. The outgoing server asks DNS for the MX records of example.com. MX records list the servers willing to accept mail for that domain, in order of preference.
3. Transfer. The sending server connects to the receiving server and delivers the message. The receiver can accept it, reject it with an error code, or accept it and decide later what to do with it.
4. Filtering. The receiving system checks authentication records, reputation, content and user rules to decide between the inbox, the spam folder or silent discard.
5. Retrieval. Ben’s phone or desktop client fetches the message using IMAP (or a proprietary sync protocol), and it appears in his inbox.

If step three fails because the receiving server is busy or down, the sender queues the message and retries for hours or days before giving up and returning a “bounce”. That is why email is described as store-and-forward: reliable, but not instant by design.

How receivers decide whether to trust a message

SMTP was designed when the internet was small and trusting, and the visible “From” address is simply text the sender fills in. Three DNS-based mechanisms were added later so that domain owners can say which mail is genuinely theirs:

• SPF lists which servers are allowed to send mail for a domain. A message from an unlisted server fails the check.
• DKIM adds a cryptographic signature to each message. The receiver fetches the public key from DNS and verifies that the signed parts were not altered and really came from the domain’s infrastructure.
• DMARC ties the two together: it tells receivers what to do when SPF or DKIM fail for the domain in the visible From header (do nothing, quarantine or reject) and where to send reports.

Together these make it much harder to send mail that claims to be from a domain you do not control. They do not stop every attack. A phisher can register a look-alike domain with perfect SPF, DKIM and DMARC and send from there; the checks pass because the mail really is from that (misleading) domain. Authentication verifies infrastructure, not intent.

Why legitimate mail lands in spam

Receiving systems score each message using many signals: whether authentication passed, the sending server’s reputation, how often recipients marked previous mail as spam, the presence of links to suspicious domains, and how similar the message is to known campaigns. A newly registered domain or a server that suddenly sends thousands of messages looks risky regardless of content. Warming up gradually, sending only to people who asked, and keeping bounce rates low are the reliable ways to build reputation.

Keeping your mail out of spam folders

For readers:

• Look at the full address, not just the display name. “Your Bank <alerts@secure-bank-verify.info>” is not your bank.
• Be cautious with urgency: “act within 24 hours” is a manipulation technique, not a normal business practice.
• Hover over links or long-press them to inspect the real destination before opening; when in doubt, type the site’s address yourself.
• Do not reply to a suspicious message to “check”. Use a contact method you already trust.

For domain owners:

• Publish SPF, DKIM and DMARC records even if you send little mail; without them, anyone can impersonate your domain.
• Start DMARC in monitoring mode, read the reports, then move to quarantine and reject once you are sure all legitimate senders are covered.
• Route transactional and marketing mail through separate domains or subdomains so a marketing complaint does not hurt password-reset delivery.
• Watch bounce messages and delivery failures; they are the earliest signal of a configuration or reputation problem.

Frequently asked questions

Why did my email take an hour to arrive?

Usually because a server along the path was temporarily unavailable and the sender retried later, or because a filtering system deferred the message to check it. Delays of minutes are normal; hours are unusual but not a sign of loss.

Is email encrypted?

In transit between servers, usually yes, with TLS. At rest on the provider’s servers, it is readable by the provider unless you use end-to-end encryption such as PGP or S/MIME, which is rare outside specialised environments.

Can I see the path a message took?

Yes. Most clients let you view the raw headers, which list each server that handled the message and the results of SPF, DKIM and DMARC checks.

A familiar display name is not proof of identity; email is a transport system with many points where trust must be checked.

In short: Email travels through a chain of servers using decades-old protocols that were later reinforced with SPF, DKIM and DMARC. Those checks protect domains from forgery, but readers still need to verify addresses and links before acting.