1) The basic journey of an email
When you press Send, your mail app hands your message to a server that is allowed to send on your behalf. From there, the message is transferred between mail servers until it reaches the recipient’s provider, which decides whether to accept it and where to place it.
It helps to separate email into two layers. The first is transport: how servers hand messages to each other. The second is identity and trust: how receiving providers decide whether a message should be accepted. A message can be valid for transport and still be rejected for policy or authentication reasons.
2) SMTP: the delivery protocol
SMTP (Simple Mail Transfer Protocol) is the system mail servers use to transfer messages. SMTP is not what you use to read a mailbox; that’s typically IMAP or POP3. SMTP is about moving mail between systems.
Two SMTP situations are common. Submission is when a mail app submits a message to a provider’s server,
usually via port 587 with authentication. Server-to-server delivery is when one mail server delivers
to another mail server, traditionally on port 25. Many networks restrict outbound port 25 for consumer connections
because it is frequently abused.
SMTP can use TLS via STARTTLS, which protects the connection on a given hop while two systems talk to each other. It is valuable, but it is not automatic end-to-end encryption from sender to recipient.
3) DNS & domains: how delivery is routed
DNS stands for Domain Name System. Think of it as the internet’s address book:
it turns human-friendly names like example.com into technical routing information (like IP addresses),
and it also publishes “service information” such as where email for a domain should be delivered.
A domain is the part after the @ in an email address. When a mail server needs to deliver to
user@example.com, it must find out which server is responsible for receiving mail for example.com.
That discovery step is done through DNS lookups.
MX records: where to deliver mail
The key DNS record for email is the MX record (Mail Exchanger). MX records list one or more hostnames that accept mail for a domain, along with a priority. The sender will normally try the lowest priority number first, and fall back to the others if needed.
Those MX hostnames then need to resolve to an IP address. That happens via A records (IPv4) and AAAA records (IPv6). In other words: MX tells you the mail host name, and A/AAAA tells you how to reach it.
If DNS is misconfigured — missing MX records, wrong hostnames, broken A/AAAA records — mail can’t be routed reliably,
and you often see routing-related bounces (for example 5.4.4 or “host not found” wording).
DNS caching and “propagation”
DNS answers are cached for performance. That’s why changes sometimes appear to “take time”. Each record has a TTL (time to live), which tells resolvers how long they may reuse the cached answer before asking again. When you change DNS, different networks may pick it up at different times depending on caching and TTL.
Reverse DNS (PTR): a common trust signal
Another DNS concept that shows up often is reverse DNS (a PTR record). It maps an IP address back to a hostname. Many providers treat a sensible PTR (that matches the sending infrastructure) as one of several trust signals. Reverse DNS is usually controlled by whoever owns the IP address block (often your hosting provider), not by your domain registrar.
4) Envelope vs headers
Headers are the visible fields inside a message, such as From:, To:, and Subject:.
Your mail client displays these.
The SMTP envelope is the routing information used during delivery. It includes the envelope sender
(MAIL FROM) and the envelope recipient (RCPT TO). These values can differ from what you see in headers.
Bounces are typically returned to the envelope sender.
5) SPF, DKIM, DMARC
Receiving providers need a way to decide whether email claiming to be from a domain is actually authorized by that domain. SPF, DKIM, and DMARC are the core mechanisms used for this.
SPF
SPF is a DNS rule that specifies which servers are allowed to send mail for a domain. SPF is mainly evaluated against the
envelope sender domain (the SMTP MAIL FROM), not necessarily the visible From: header.
DKIM
DKIM adds a cryptographic signature to a message. The receiving side can verify the signature to confirm that the message wasn’t altered in transit and that the signer domain controls the key.
DMARC
DMARC ties SPF and DKIM to the visible sender identity. It lets a domain owner publish guidance for how to handle failures
and requires alignment so that authentication matches the domain shown in From:.
6) Bounce messages & status codes
A bounce is a delivery failure report. Somewhere along the delivery path, a server decided it could not (or would not) deliver the message and returned diagnostic information.
Temporary failures (often called soft bounces) indicate “not right now” and are usually retried automatically. Permanent failures (hard bounces) indicate “don’t retry; this won’t work as-is” and typically require changes.
SMTP reply codes (three digits)
Examples include 421, 450, 451, 550, and 554.
In general, 4xx means temporary and 5xx means permanent.
Enhanced status codes (X.Y.Z)
Examples include 4.2.2, 5.1.1, and 5.7.1. These are more specific and are often the best label
for what actually went wrong. If you see both a three-digit code and an enhanced code, the enhanced code is usually more useful.
Common enhanced codes
5.1.1 usually means the recipient address does not exist. 5.2.2 typically indicates a mailbox is full.
5.7.1 is commonly a policy rejection and may involve authentication failures, reputation, blocklists, or content filters.
Many 4.7.x responses are temporary deferrals such as rate limiting or greylisting.
Extensive list of bounce codes
Where to look in a bounce
Many bounces include a structured section with fields like Status:, Action:, and Diagnostic-Code:.
If you find Status: and Diagnostic-Code:, you usually have enough information to categorize the issue.
What to do next
If the error is addressing-related (often 5.1.x), verify the recipient address and domain. If it is temporary
(4xx or 4.x.x), retries may succeed, but persistent deferrals can indicate throttling or policy concerns.
If it is policy/auth-related (often 5.7.1), focus on SPF/DKIM/DMARC alignment and consistent sending identity.