KAHIBARO
Discord Login Register ☰
☰

18.1 How Email Works

Table of Contents

The Big Picture: How Email Moves Across the Internet

Email looks simple in your inbox, but behind every message there is a small “conversation” between multiple servers. As a backend developer, you do not need to become an email admin, but you must understand this flow, because you will often send registration emails, password reset links, and notifications from your applications.

At a high level, email works like this:

  1. A user or application composes an email.
  2. The email is submitted to an outgoing mail server.
  3. That server looks up where to send the email by checking DNS records.
  4. The sender server connects to the receiver server and delivers the message.
  5. The recipient’s mail server stores the email.
  6. The recipient’s email client fetches and displays the message.

We will walk through each part with practical examples that matter for backend development.

Key idea: An email is not sent “directly” from your app to someone’s inbox. It passes through one or more mail servers using standard protocols, especially SMTP for sending and IMAP/POP3 for receiving.

The Core Components in Email Delivery

Mail User Agent, Mail Transfer Agent, Mail Delivery Agent

There are three classic roles in the email world. Sometimes one program plays more than one role, but the concepts stay the same.

ComponentAlso calledWho uses itTypical examples
Mail User Agent (MUA)Email clientHumans or appsGmail web UI, Outlook, Apple Mail, Thunderbird
Mail Transfer Agent (MTA)Mail serverServers talk to serversPostfix, Exim, Sendmail, Microsoft Exchange
Mail Delivery Agent (MDA)Local deliveryServer stores mail for usersDovecot LDA, Procmail, built into some MTAs

In many modern setups:

As a backend developer, your code usually:

Step‑by‑Step: What Happens When You Send an Email

Imagine your application lives at api.myapp.com and you send a welcome email to alice@example.com.

We will follow the path:

  1. App → Outgoing mail server (SMTP submission)
  2. Outgoing mail server → DNS lookup for example.com
  3. Outgoing mail server → Recipient mail server (SMTP delivery)
  4. Recipient mail server → Recipient mailbox

1. Your Application Submits the Email

Your app prepares an email, which at the protocol level is a plain text document with headers and a body, for example:

text 
From: "MyApp" <no-reply@myapp.com>
To: Alice <alice@example.com>
Subject: Welcome to MyApp
Date: Fri, 01 Jan 2026 10:00:00 +0000
Message-ID: <abc123@myapp.com>
Content-Type: text/plain; charset="utf-8"
Hi Alice,
Welcome to MyApp!
Best,
The MyApp Team

Your app then:

Typical scenarios:

From your point of view:

python 
# Pseudocode, not full implementation
send_email(
    smtp_host="smtp.mailprovider.com",
    username="apikey",
    password="SECRET",
    from_="no-reply@myapp.com",
    to="alice@example.com",
    subject="Welcome to MyApp",
    body="Hi Alice..."
)

The mail provider now has the message and is responsible for getting it to example.com.

2. The Outgoing Server Uses DNS To Find the Recipient Server

To deliver to alice@example.com, the mail server must find where example.com receives mail.

It asks DNS: “What are the MX records for example.com?”

An MX record says: “Mail for this domain should go to this host.”

Example DNS for example.com:

Record typeNameValuePriority
MXexample.com.10 mx1.example.com.10
MXexample.com.20 mx2.example.com.20

The server:

  1. Queries DNS for MX example.com.
  2. Gets a list of mail hosts (here mx1.example.com and mx2.example.com).
  3. Chooses the lowest priority number first (10 before 20).
  4. Resolves mx1.example.com to an IP address using an A or AAAA record.

Important rule: Email delivery uses MX DNS records to find the correct mail server for the recipient’s domain. Without MX records, many servers will not know where to send email.

If mx1.example.com is down, the sender will try mx2.example.com.

3. SMTP Conversation Between Mail Servers

Now the sender’s MTA opens a TCP connection, usually to port 25, on mx1.example.com, and speaks SMTP.

A very simplified conversation looks like this:

text 
S: 220 mx1.example.com ESMTP Ready
C: EHLO smtp.mailprovider.com
S: 250-mx1.example.com Hello
S: 250-SIZE 52428800
S: 250-PIPELINING
S: 250 8BITMIME
C: MAIL FROM:<no-reply@myapp.com>
S: 250 2.1.0 Ok
C: RCPT TO:<alice@example.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "MyApp" <no-reply@myapp.com>
C: To: Alice <alice@example.com>
C: Subject: Welcome to MyApp
C:
C: Hi Alice,
C:
C: Welcome to MyApp!
C:
C: .
S: 250 2.0.0 Queued as XYZ123
C: QUIT
S: 221 2.0.0 Bye

Key points:

If everything is accepted, the recipient server will keep the message and either:

4. Recipient Server Stores the Email

Once the recipient’s MTA accepts the message, it must deliver it to the user’s mailbox. This is where MDA-like functionality happens.

For a hosted email provider, typical flow:

  1. MTA receives email for alice@example.com.
  2. It looks up Alice’s account and mailbox.
  3. It applies filters, such as spam checks and rules.
  4. It stores the message in the right folder, for example Inbox.

Emails are usually stored in formats like Maildir or in a database-like storage in large systems. From your perspective as a backend developer, the details of local storage rarely matter, unless you work directly on mail infrastructure.

How Recipients Read Email

There are two main protocols for reading emails from a server:

Users rarely see these names anymore, because:

Typical flows:

As a backend developer building a web application, you usually:

SMTP vs IMAP vs POP3: What You Must Remember

PurposeProtocolTypical Port (with TLS)Used by
Sending mailSMTP587 (submission), 465Clients / Apps
Server-to-server sendSMTP25Mail servers (MTAs)
Reading / managing mailIMAP993Email clients
Simple downloadPOP3995Older email clients

Rule to remember:

  • SMTP is for sending and transferring emails.
  • IMAP/POP3 are for retrieving emails.
    Your backend normally only talks SMTP, or uses an HTTP API that wraps SMTP.

The Role of DNS in Email: MX, SPF, DKIM, DMARC (Overview)

You already saw MX records, which tell senders where to deliver mail. There are three other important DNS-based mechanisms that affect deliverability and security. You will use them often when configuring production systems, but their full details are covered in later chapters.

Here is a quick backend-focused overview.

MX: Where to Deliver Email

text 
myapp.com.  IN  MX 10  mx1.mailprovider.com.
myapp.com.  IN  MX 20  mx2.mailprovider.com.

This tells other servers: “Send mail for @myapp.com to mx1.mailprovider.com first, or mx2 if that fails.”

SPF: Who Can Send Email for Your Domain

SPF (Sender Policy Framework) is stored as a DNS TXT record and says which servers are allowed to send email for your domain.

Example:

text 
myapp.com. IN TXT "v=spf1 include:_spf.mailprovider.com ~all"

This means:

For backend work, you will often see provider instructions like:

Add this SPF record to your DNS: v=spf1 include:sendgrid.net ~all.

DKIM: Cryptographic Signature for Email

DKIM (DomainKeys Identified Mail) uses a public/private key pair.

Example DKIM record:

text 
selector1._domainkey.myapp.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_HERE"

You usually:

DMARC: Policy for Handling Failed SPF/DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells recipients how strictly to treat messages that fail SPF or DKIM checks.

Example:

text 
_dmarc.myapp.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@myapp.com"

Meaning:

For now, just remember: SPF, DKIM, and DMARC greatly impact whether your app’s emails land in Inbox or in Spam.

Message Routing, Relaying, and Queues

Real email flow is not always one hop from sender to recipient. There can be relays and queues.

Relays

A relay is an MTA that forwards email to another server.

Example flows:

Reasons for relays:

As a backend developer, you usually interact with a submission server and let it decide the internal relay path.

Queues and Retries

Sometimes the recipient server is:

In that case, the sending MTA:

Example issues that cause queueing:

Your application may see:

Handling retries in your app (background jobs, backoff strategies) is often separate from the MTA’s own retries but complements them.

Headers, Body, and MIME: What an Email Really Looks Like

An email is a text document divided into:

  1. Headers: key-value pairs at the top.
  2. A blank line.
  3. Body: the content.

Basic example:

text 
From: "MyApp" <no-reply@myapp.com>
To: Alice <alice@example.com>
Subject: Welcome to MyApp
Date: Fri, 01 Jan 2026 10:00:00 +0000
Message-ID: <abc123@myapp.com>
Hi Alice,
Welcome to MyApp!

Common headers:

HeaderPurpose
FromHuman-visible sender
To, Cc, BccVisible recipients
SubjectSubject line
DateWhen the email was sent
Message-IDUnique identifier for the message
Reply-ToWhere replies should go
MIME-VersionUsually 1.0, indicates MIME usage
Content-TypeText encoding, HTML vs plain text, etc.

For richer content, such as HTML and attachments, emails use MIME (Multipurpose Internet Mail Extensions). You will see things like:

text 
Content-Type: multipart/alternative; boundary="boundary123"

Which means there are multiple parts inside, for example a plain text part and an HTML part.

For backend work:

Example End‑to‑End Scenario for a Backend Developer

Imagine you implement:

The high-level flow looks like this:

  1. User action
    User signs up with email alice@example.com.
  2. Your backend generates a token
    For example, a signed token valid for 24 hours.
  3. Your backend builds the email
    • From: no-reply@myapp.com
    • To: alice@example.com
    • Subject: “Verify your email”
    • Body containing a link https://myapp.com/verify?token=...
  4. Your backend sends via SMTP or provider API
    • Connect to smtp.mailprovider.com:587, or
    • POST https://api.mailprovider.com/v3/send with JSON.
  5. Provider handles delivery
    • Uses DNS MX records of example.com.
    • Talks via SMTP to the MX server.
    • Retries or bounces on failure.
  6. Recipient reads
    • Alice’s mail provider accepts the message.
    • Stores it in her Inbox.
    • Alice opens it using webmail or an app via IMAP/POP3.

Your concern:

Key Takeaways for Backend Developers

To close, here are the most important points to remember:

  • Email flow: Client / App → SMTP server → DNS (MX) → Recipient server → Recipient client.
  • SMTP is used to send and relay email, IMAP/POP3 to read it.
  • MX records in DNS tell senders where to deliver email for a domain.
  • SPF, DKIM, DMARC strongly affect whether your app’s emails reach the Inbox.
  • Your backend usually uses an SMTP server or an email provider API, not raw protocol handling.

In the following chapters, you will learn how to use SMTP and providers in practice, send HTML and transactional emails, and integrate email sending into your backend applications safely and reliably.

Views: 8

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3133 / 24h
Impressum / Imprint
Datenschutz / Data Policy