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.

SPF: Is this sending IP authorized?

SPF checks the connecting server's IP against a DNS TXT policy for the SMTP envelope sender (MAIL FROM) domain. It does not authenticate the visible From address or sign the message. Forwarding can change the connecting IP and cause SPF to fail even for legitimate mail.

DKIM: Does the signed content verify?

DKIM signs selected headers and the message body. The receiver uses the signing domain (d=) and selector (s=) to find the public key at selector._domainkey.domain in DNS. Verification detects changes to the signed content; it does not prove the sender is honest or the content harmless.

DMARC: Does authentication align with From?

DMARC connects authentication to the visible From domain. It passes when either SPF passes for an aligned envelope domain or DKIM passes for an aligned signing domain. Relaxed alignment allows the same organizational domain; strict alignment requires an exact domain match.

A TXT policy at _dmarc.example.com can request p=none (no particular delivery action), p=quarantine, or p=reject for failures, and request reports about domain use. The receiver still applies its own handling policy.

Pass is not a safety verdict. SPF and DKIM can both pass for domains unrelated to the visible From address, yet DMARC can fail because neither aligns. Conversely, mail from an attacker-controlled domain or a compromised legitimate account can pass all three checks.

Read an Email Header

Open the mail client's original message or full headers view. This is a constructed teaching example using reserved domains and IP addresses, not a captured email. The body and DKIM hash/signature values are omitted, so the example cannot be cryptographically verified.

Return-Path: <bounce@example.com>
Received: from outbound.example.com (outbound.example.com [192.0.2.25])
    by mx.example.net with ESMTPS id RX123
    for <alex@example.net>; Mon, 28 Sep 2026 09:15:04 +0000
Authentication-Results: mx.example.net;
    spf=pass smtp.mailfrom=example.com;
    dkim=pass header.d=example.com header.s=mail2026;
    dmarc=pass header.from=example.com
Received: from client.example.com (client.example.com [192.0.2.10])
    by outbound.example.com with ESMTPSA id TX456;
    Mon, 28 Sep 2026 09:15:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
    h=from:to:subject:date:message-id;
    bh=[body-hash-omitted]; b=[signature-omitted]
From: Sam <sam@example.com>
To: Alex <alex@example.net>
Subject: Project update
Date: Mon, 28 Sep 2026 09:15:00 +0000
Message-ID: <20260928.091500.1234@example.com>

Establish trust before reading the path. Start with headers added by the recipient's known mail infrastructure; older entries below that boundary may be forged. Within the trusted portion, read Received entries bottom to top to follow the journey. Trust Authentication-Results only when your receiving service generated or explicitly trusts it—not merely because a header says pass.

Field	How to read this example
Received	from identifies the peer and by the server recording the hop; id is its queue/trace reference, for is the recipient when shown, and the timestamp records that handoff. ESMTPS indicates TLS on that hop; ESMTPSA also indicates SMTP authentication. Neither proves every hop was protected.
Return-Path	The envelope return address recorded at final delivery, normally used for delivery-failure notices. Here it is bounce@example.com, not the visible author address or a reply instruction.
Authentication-Results	mx.example.net identifies the checking service. smtp.mailfrom records the SPF domain; header.d and header.s identify the DKIM signer and selector; header.from identifies the domain evaluated by DMARC. The illustrated passes align on example.com.
DKIM-Signature	v is the version, a the algorithm, d the signing domain, and s the selector. h lists signed headers, bh holds the body hash, and b holds the signature. Here the key lookup is mail2026._domainkey.example.com. A signature's presence alone is not a pass.
From / To	The presented author and recipients, including optional display names. They are message content, not a complete record of the SMTP envelope.
Subject / Date	The sender's topic and stated message-creation time. The Date field is not independent proof of when a receiving server handled the message.
Message-ID	An identifier intended to be unique to the message, useful for correlating copies and logs. Its domain is not proof of origin, and it is separate from each server's queue ID.

Email Security: What Authentication Does Not Solve

Threat	Important distinction
Phishing and spear phishing	Deceptive messages try to steal credentials, deliver malware, or induce an action. Spear phishing is tailored to a particular person or organization; polished, relevant wording does not make it safe.
Business email compromise (BEC)	Impersonated or compromised business accounts request payments, sensitive information, or process changes. No malicious attachment is necessary. Verify sensitive requests through an independently known channel.
Display-name spoofing	The friendly name claims “IT Support” or a colleague while the actual address is unrelated. Inspect the full address, not just the displayed name.
Domain spoofing and lookalikes	DMARC helps detect unauthorized use of the exact From domain. It does not stop an attacker using a similar-looking domain they own or sending through a compromised authorized account.
Malicious attachments and URLs	A message may carry malware or link to a credential-stealing site even when authentication passes. Use approved attachment/link inspection and reporting tools, not a test click or opening the file.

Authentication, spam and malware filtering, account protection, and independent verification cover different risks. TLS protects a connection between two endpoints—not automatically every hop or the message at rest.

Troubleshoot Delivery and Authentication

Use the handoff checks to locate the stage first, then narrow the cause. Preserve the original headers, exact error, timestamp, and queue or trace ID.

Symptom	What to check next
Mail rejected or deferred	Read the full SMTP response or delivery-status notice and identify the rejecting server. Distinguish a temporary 4xx from a permanent 5xx; recipient, quota, reputation, and policy errors need different fixes.
Mail lands in spam	Check receiving-side filtering or quarantine details. Reputation, content, links, and local rules can affect placement even with SPF, DKIM, and DMARC passing.
SPF failure or error	Compare the connecting IP with the envelope domain's SPF policy, including approved third-party senders and forwarding. Distinguish fail from DNS-related temperror or policy/lookup-limit permerror.
DKIM failure	Resolve the actual s= selector under the d= domain. Check key publication or rotation and whether a relay, footer, or mailing list changed signed content after signing.
DMARC failure	Compare the visible From domain with each passing SPF or DKIM domain using the configured alignment mode. A pass for an unrelated domain does not count; at least one aligned pass is needed.
MX or routing problem	Check the recipient domain's MX records, their preference and target addresses, then reachability and the receiving service. Use the DNS troubleshooting checks; changing MX does not repair an outbound SPF or DKIM failure.

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.