Email Basics

Email is a store-and-forward system. Your app submits a message, mail servers route and transfer it, a delivery service places it in a mailbox, and the recipient's app reads it. Sending and reading use different protocols.

The Architecture at a Glance

01 · Sender sideCompose and submit

PersonSenderWrites the message

→

MUAMail clientBuilds headers, body, and attachments

→SMTP submission

MSASubmission serverAuthenticates and accepts outgoing mail

↓Message enters the outbound queue

02 · TransportFind the destination and transfer

Outbound MTASending mail serverChooses a route; queues and retries when needed

→SMTP relay
port 25

Inbound MTAReceiving mail serverReceives SMTP traffic; may reject before accepting

Before that SMTP hop · DNS query and answer

Supporting lookup · no mail passes through DNSRecipient-domain MX recordReturns the mail host and preference, then its A/AAAA address, to the sending MTA

↓Receiving-side policy and delivery

03 · Recipient sideCheck and deliver

Gateway / policyReceiving checksSPF, DKIM, DMARC, spam, and malware; some checks run before SMTP acceptance

→

MDADelivery agentFinal local handoff; may use LMTP

→

Message storeMailboxMessage reaches an account or folder

↓Mailbox access is separate from SMTP delivery

04 · ReadingAccess the delivered message

Mailbox serviceIMAP / POPOr a provider's webmail backend

→

Recipient MUAMail clientSynchronizes or retrieves the message

→

PersonRecipientOpens and reads the message

This is a map of roles, not a fixed number of machines. A provider may combine components or add relays, filtering gateways, and separate mailbox servers.

Who Does What?

Part	Job
Mail client (MUA)	The app used to compose, send, and read mail, such as a desktop, phone, or webmail interface. MUA means message user agent.
MSA	The message submission agent accepts outgoing mail from a client, normally after authentication, and passes it into the mail system.
MTA	The mail transfer agent relays mail between servers. It uses the recipient domain and DNS to find where to send it next.
MDA	The mail delivery agent performs final delivery into the recipient's mailbox. It may be part of the receiving mail service.
Mailbox	The stored messages and folders associated with an account. The mail client accesses them through a mailbox service.

Follow One Message

1. Compose and submit: the sender writes to alex@example.net. The mail client submits the message to its MSA using SMTP submission.
2. Find the destination: the sending MTA looks up the MX records for example.net. An MX record names a mail server and gives it a preference value; the sending server then resolves that server's address.
3. Transfer: the sending MTA connects to a receiving MTA using SMTP. A large system may pass the message through more than one relay or security gateway.
4. Deliver: the receiving service checks the recipient and its policies. If accepted, an MDA or equivalent delivery component places the message in the mailbox.
5. Read: the recipient's client accesses the mailbox through IMAP or POP. A webmail interface usually talks to its provider over HTTPS while the provider handles the mailbox access behind the scenes.

example.net.  IN MX 10 mail.example.net.
mail.example.net. IN A 192.0.2.25

Here, the MX record points to a host name, not directly to an IP address. Lower MX preference numbers are tried before higher ones. With no MX record, SMTP can fall back to the domain's A/AAAA address; a null MX explicitly says the domain accepts no mail. MX records route incoming mail for a domain, not a user's outgoing SMTP or incoming IMAP connection.

Handoffs That Matter in Troubleshooting

Trace the envelope recipient, time, Message-ID, and each server's queue or trace ID. The visible To header alone may not show every recipient.

Stage	What to verify
Submission	An SMTP 250 after submission means the MSA accepted responsibility for the message—not that it reached the recipient's inbox.
Routing	Check the recipient domain's MX answer, preference, target address, and DNS errors before blaming the receiving server.
Transfer	A 4xx SMTP response is temporary and normally leads to queueing and retry; 5xx is a permanent failure. Read the exact response and the outbound queue state.
Delivery and access	Receiving-side acceptance can precede quarantine or a later local delivery failure. If the message is stored but unseen, check the mailbox, filters, and IMAP/POP client behavior.

SMTP Sends; IMAP and POP Read

Protocol	Purpose and common ports
SMTP submission	Mail client → submission server. 587 with STARTTLS or 465 with implicit TLS.
SMTP relay	Mail server → mail server. Usually port 25.
IMAP	Accesses and synchronizes a server mailbox. 993 with implicit TLS; 143 may use STARTTLS.
POP3	Retrieves messages from a server mailbox. 995 with implicit TLS; 110 may use STARTTLS.

IMAP treats the server mailbox as the shared source of truth: folders, read state, and changes can synchronize across devices. POP3 is a simpler retrieval model, often used for downloading mail to one client. A POP client may delete server copies after retrieval or be configured to leave them there. Neither IMAP nor POP sends an outgoing message.

The Message Is Not the Delivery Envelope

An email has visible headers such as From, To, Subject, and Date, plus a body. MIME allows structured content such as HTML parts and attachments. SMTP also carries an envelope with sender and recipient addresses used for routing and delivery. Envelope addresses and visible headers can differ: for example, a Bcc recipient can receive a copy without appearing in the visible To header.

SPF, DKIM, and DMARC

The receiving mail service commonly checks these as a message arrives. The domain owner publishes the relevant information in DNS; the sender configures authorized sending systems and DKIM signing.

Check	What it checks—and does not
SPF	Checks whether the connecting server's IP is authorized by the SMTP envelope sender (MAIL FROM) domain, using a DNS TXT record. It does not, by itself, authenticate the visible From address.
DKIM	Verifies a message signature against the signer's public key in DNS, selected by domain and selector. A valid signature identifies a signing domain, not whether the message is trustworthy.
DMARC	Checks whether a passing SPF or DKIM result aligns with the visible From domain. Its DNS policy asks receivers to monitor, quarantine, or reject failures; local policy can also affect handling.

For example, a message claiming From: user@example.net can pass DMARC if SPF passes for an aligned envelope domain or DKIM passes with an aligned signing domain. DMARC can request aggregate reports so the domain owner can see how its domain is used. Forwarding and mailing lists may complicate these checks.

These checks complement spam and malware filtering; none guarantees a message is safe. TLS protects a connection between two endpoints, not automatically every hop or the message at rest.

Quick Recap

• MUA → MSA → MTA → MDA → mailbox is the core send-to-deliver path.
• DNS MX tells a sending server which host accepts mail for a recipient domain.
• SMTP moves outgoing mail; IMAP/POP let a client access delivered mail.
• SPF checks a sending IP, DKIM checks a signature, and DMARC checks alignment with the visible From domain.
• The roles are logical. One product can implement several of them.