How Email Travels: Store-and-Forward Across Mail Systems

Email crosses independently operated systems.

The sender's application does not usually connect directly to the recipient's phone. It submits a message to a mail service, which discovers the recipient's server, transfers the message, and retries temporary failure.

Email is store-and-forward communication: servers accept, queue, transfer, filter, and store messages on one another's behalf.

Delivery can take time even when Send appears immediate.

A concrete example: sending to another company

Alice sends a message from alice@example-a.com to bob@example-b.com.

Her provider:

authenticates Alice,
accepts the message,
looks up mail servers for example-b.com,
connects to one using SMTP,
transfers the envelope and content,
receives a delivery response.

Bob's provider filters and stores the message for his mailbox.

Message submission

An email client submits mail to its provider through:

authenticated SMTP submission,
web API,
or webmail backend.

The provider verifies the sender's account and applies size, policy, and rate limits.

Submission success means the provider accepted responsibility, not necessarily that the recipient has received it.

Envelope versus headers

Email has an SMTP envelope:

envelope sender,
recipient addresses.

The message also contains visible headers:

From,
To,
Subject,
Date,
Message-ID.

They can differ, much like a postal envelope and letter content.

DNS MX records

The sending server queries DNS for the recipient domain's MX records.

MX records list mail exchangers and priorities. The sender tries the preferred reachable server, with fallbacks when necessary.

If no MX exists, protocol rules may try another domain record depending on configuration.

SMTP transfer

Simple Mail Transfer Protocol coordinates server-to-server mail delivery.

The conversation broadly exchanges:

server identity,
sender,
recipients,
message data,
and status responses.

TLS can encrypt the network connection.

Store and forward

If the recipient server is temporarily unavailable, the sender queues the message.

It retries over a configured period with increasing delays. This design lets independently operated systems recover without requiring both to be online at one instant.

Permanent failure produces a bounce or delivery-status notification.

Temporary and permanent responses

SMTP response categories distinguish:

success,
temporary failure,
permanent failure.

A full mailbox may be temporary or permanent by provider policy. An invalid recipient is usually permanent.

Correct classification prevents endless retry of impossible delivery.

Message format

Email content uses standardized headers and body formats.

MIME allows:

plain text,
HTML,
attachments,
multiple alternatives,
and character encodings.

Attachments are encoded into textual transport representation, increasing message size.

Message identity

A Message-ID helps identify one logical email across systems and threads.

Providers also add Received headers as the message passes through servers. Reading them from bottom to top can reveal the transfer path.

Headers can contain untrusted claims, so not every field proves identity.

Sender authentication: SPF

SPF publishes which servers may send envelope mail for a domain.

The recipient compares the connecting server with the domain's policy.

SPF can break through forwarding because the forwarder is not listed as the original domain's sender.

Sender authentication: DKIM

DKIM adds a cryptographic signature over selected message headers and body.

The recipient retrieves the domain's public key from DNS and verifies that signed content was not altered.

DKIM authenticates a signing domain, not necessarily the human visible in the message.

Sender authentication: DMARC

DMARC connects the visible From domain with SPF or DKIM alignment and publishes handling policy.

Domain owners can request:

monitor,
quarantine,
or reject

for failing messages and receive aggregate reports.

Spam and malware filtering

Receiving systems evaluate:

sender reputation,
authentication,
content,
links,
attachment type,
user reports,
and behavior.

Legitimate mail can be misclassified, while attackers continually adapt.

Mailbox delivery

After acceptance, the provider stores the message and places it in:

inbox,
spam,
quarantine,
rule-defined folder,
or another category.

SMTP acceptance does not guarantee inbox placement or that a person reads the message.

Reading mail

Clients access mail through:

provider APIs,
IMAP,
POP,
or web interfaces.

IMAP synchronizes mailbox state across devices. POP traditionally downloads messages with a simpler model.

Push signals may notify devices that new mail is available.

End-to-end encryption

TLS protects connections between systems when supported.

Mail providers may still process and store plaintext content. End-to-end encryption formats encrypt content for recipient keys, but key distribution, metadata, search, and usability become more complex.

Transport encryption and end-to-end encryption are different guarantees.

Bounces

A bounce reports non-delivery.

It may include:

failed recipient,
response code,
diagnostic,
and retry status.

Backscatter is unwanted bounce traffic sent to forged sender addresses, so systems should reject invalid recipients during SMTP where practical.

Mailing lists and forwarding

Forwarders and lists modify the path and sometimes message content.

They can affect sender authentication. Modern mechanisms and rewriting strategies help preserve or communicate authentication across intermediaries.

Email's open federation creates complex compatibility.

Deliverability

Bulk senders need:

authenticated domains,
permission-based lists,
unsubscribe,
low complaint rate,
bounce handling,
gradual volume,
and stable infrastructure.

Sending more retries does not fix damaged reputation.

Privacy and metadata

Email metadata reveals:

participants,
time,
subject,
routing,
and provider information.

Even encrypted content does not hide all metadata. Retention and access policies matter across sender, receiver, backups, and devices.

Knowledge check

What does message submission success promise?
How do MX records guide delivery?
Why does email use queues and retries?
How do SPF, DKIM, and DMARC differ?
Why does SMTP acceptance not prove inbox placement?

The one idea to remember

Email is a federated store-and-forward system: the sender's service accepts and queues a message, DNS identifies receiving servers, SMTP transfers it, authentication and filters evaluate it, and the recipient service stores it for later access.