How Email Works: SMTP, IMAP, SPF, DKIM, and DMARC Explained

Introduction

You click Send, and a few seconds later your message appears in someone's inbox on the other side of the world. Behind that moment is a system older than the web itself, built at a time when everyone on the network knew each other and nobody expected forgery.

That history explains two things about email today. First, the core machinery is simple and text-based, and it works remarkably well. Second, the original design never checked whether a "From" address was real, so a layer of add-ons (SPF, DKIM, and DMARC) was bolted on later to restore trust.

This post follows one message from sender to recipient, then explains how those three add-ons catch fakes. It builds on our How DNS Works post, because email leans on DNS at almost every step.

The Short Version

• Your email app hands the message to your provider's server using SMTP.

• Servers pass it along, again using SMTP, and find the destination through DNS MX records.

• The recipient's server stores the message in a mailbox, and the recipient reads it with IMAP (or a webmail site).

• SPF, DKIM, and DMARC let the receiving server check that the sender is who they claim to be.

[embedded content: email route · 2 SMTP hops, 1 IMAP fetch]

The route at a glance: two SMTP hops carry the message to the recipient's provider, and IMAP delivers it to their app. DNS answers the question of where mail should go along the way.

The Cast of Characters

Several programs cooperate on every message. Their official names are a mouthful, so here they are in plain terms:

• Mail client (MUA, mail user agent): the app you use, such as Gmail in your browser, Outlook, or Apple Mail.

• Outgoing server (MSA, mail submission agent): your provider's server, which accepts your message after checking that you're allowed to send.

• Mail transfer agent (MTA): server software that relays mail from one domain to another.

• Mailbox: where the recipient's server keeps incoming mail until it is read.

In practice, one provider usually runs all of the server roles for its users.

Step 1: Sending With SMTP

SMTP (Simple Mail Transfer Protocol) is the protocol for sending and relaying email. It's a plain-text conversation between two programs. A simplified exchange between a sending and a receiving server looks like this:

S: 220 mx.example.org ESMTP ready
C: EHLO mail.example.com
S: 250 OK
C: MAIL FROM:<[email protected]>
S: 250 OK
C: RCPT TO:<[email protected]>
S: 250 OK
C: DATA
S: 354 Go ahead
C: From: Alice <[email protected]>
C: To: Bob <[email protected]>
C: Subject: Lunch?
C:
C: Are you free at noon?
C: .
S: 250 Message accepted
C: QUIT

(S is the receiving server, C is the sender.) EHLO introduces the sender, MAIL FROM gives the sender's address, RCPT TO names the recipient, and DATA begins the message, which ends with a line containing only a period.

Notice that there are two "from" addresses. The envelope sender (MAIL FROM) is what servers use for delivery and bounce messages. The header From is the address your recipient actually sees. Basic SMTP doesn't force them to match, which is exactly what spoofers exploit and why SPF and DMARC care about the difference.

SMTP is spoken on a few different ports:

• 25: server-to-server relay.

• 587: your email app submitting a message to your provider, with a login, upgraded to TLS using STARTTLS.

• 465: the same submission, but encrypted with TLS from the very first byte.

Step 2: Finding the Recipient's Server With MX Records

Your provider's server now needs to know where to deliver mail for example.org. It asks DNS for the domain's MX (mail exchanger) records:

example.org.   3600   IN   MX   10 mail1.example.org.
example.org.   3600   IN   MX   20 mail2.example.org.

The lower number has higher priority, so the sender tries mail1 first and falls back to mail2. If neither can be reached, the sending server doesn't give up immediately. It queues the message and keeps retrying for a few days before returning a bounce notice. Our DNS post covers how MX and other record types work.

Step 3: Accepting and Storing the Message

The recipient's server accepts the message, runs its checks (SPF, DKIM, DMARC, and spam filtering, covered below), and files it in the recipient's mailbox, or in the spam folder if something looks wrong.

Step 4: Reading Mail With IMAP

Storing mail and reading it are separate jobs. Your email app fetches messages from the mailbox using one of two protocols:

• IMAP (Internet Message Access Protocol, ports 143, or 993 with TLS) keeps mail on the server and syncs your folders, read marks, and drafts across every device. It's the modern default.

• POP3 (Post Office Protocol, ports 110, or 995 with TLS) downloads mail to one device and usually removes it from the server. It's older and simpler.

If you use webmail such as Gmail or Outlook on the web, the provider's website talks to the mailbox for you, so you never see IMAP at all. A handy way to remember the split: SMTP sends, IMAP reads.

Inside a Message: Envelope, Headers, and Body

Every email has three parts:

• The envelope, built from the SMTP commands. You never see it, but servers use it to route the message.

• The headers: fields such as From, To, Subject, Date, and Message-ID, plus a trail of Received lines.

• The body: the text or HTML, with attachments encoded using a standard called MIME.

Most email apps have a "Show original" or "View headers" option. Each server that handles the message adds a Received header at the top, so reading them from the bottom up shows the message's route. This is the first place to look when a message is delayed or suspicious.

The Trust Problem

Because SMTP doesn't verify the visible From address, anyone can send a message that claims to come from your bank or your boss. This is called spoofing, and it's the basis of much phishing. Three DNS-based standards work together to fight it.

SPF: Which Servers May Send for This Domain

SPF (Sender Policy Framework) is a DNS TXT record listing the servers allowed to send mail for a domain:

example.com.   IN   TXT   "v=spf1 ip4:203.0.113.25 include:_spf.mailprovider.example -all"

Reading it left to right: v=spf1 marks it as an SPF record, ip4: authorizes a specific address, include: borrows your mail provider's list of servers, and -all says to reject anything else. (~all is the softer version, meaning "treat anything else as suspicious.")

The receiving server compares the IP address that connected to it against the SPF record of the envelope sender's domain. SPF has some well-known limits: a domain can have only one SPF record, the record can trigger at most 10 DNS lookups, and forwarded mail often fails SPF because the forwarding server isn't on the original list.

DKIM: A Signature That Survives the Trip

DKIM (DomainKeys Identified Mail) attaches a digital signature to each outgoing message. The sending server signs selected headers and the body with a private key, and the matching public key is published in DNS. The receiver fetches that key and checks that the signature is valid, which proves two things: the message really was signed by that domain, and it wasn't altered along the way.

A DKIM signature appears as a header:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
  h=from:to:subject:date; bh=...; b=...

Here d= is the signing domain and s= is the selector, which tells the receiver where to find the public key: in this case, a TXT record at mail2026._domainkey.example.com. Because DKIM travels with the message, it usually survives forwarding, unless the forwarder changes the content.

DMARC: Setting the Rules

SPF and DKIM each check something, but neither says what the visible From address has to do with it, or what to do on failure. DMARC closes both gaps. It is a TXT record at _dmarc.example.com:

_dmarc.example.com.   IN   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

DMARC does two things:

1. Alignment. A message passes only if SPF or DKIM passes and the domain it authenticated matches the domain in the visible From header. This is what stops a scammer from passing SPF with their own domain while displaying yours.

2. Policy and reporting. The p= tag tells receivers what to do with failures: none (just monitor), quarantine (send to spam), or reject (refuse the message). The rua= address receives daily summary reports showing who is sending mail using your domain.

A safe rollout is gradual: start with p=none and read the reports, fix any legitimate services that fail, then move to quarantine, and finally to reject. Large providers such as Gmail and Yahoo now expect bulk senders to have SPF, DKIM, and DMARC in place, and even small senders benefit from better deliverability.

Is Email Private?

Not by default. Servers usually encrypt the connections between them using opportunistic TLS (STARTTLS), but that encryption can be downgraded or skipped, and standards like MTA-STS and DANE exist to enforce it. More importantly, your email provider and the recipient's provider can read your messages. Email isn't end-to-end encrypted unless both sides use something like PGP or S/MIME, which few people do.

The practical takeaway: treat email like a postcard in a sealed envelope. The envelope deters casual snooping, but it's not a vault.

Why Email Fails: Bounces, Delays, and Spam Folders

SMTP replies carry a three-digit code. Codes starting with 4 mean a temporary problem, so the sender will retry. Codes starting with 5 mean a permanent failure, and the sender gives up and bounces the message.

Common problems and their usual causes:

• "User unknown" bounce (550 5.1.1): the recipient address doesn't exist, usually a typo.

• Rejected for authentication: SPF, DKIM, or DMARC failed, often because a service sending on your behalf isn't included in your records.

• Lands in spam: failing authentication, a poor sending reputation, or content that looks like spam.

• Delayed messages: the recipient's server is unreachable or busy, and the sender is retrying.

• Forwarded mail fails: SPF breaks when a message is forwarded, so DKIM and DMARC settings matter.

To see how a message was judged, open its headers and look for Authentication-Results:

Authentication-Results: mx.example.org;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

You can also inspect the DNS side from a terminal: dig MX example.com, dig TXT example.com for SPF, and dig TXT _dmarc.example.com for DMARC.

A Checklist for Your Own Domain

• Point your MX records at your mail provider.

• Publish one SPF record that lists only the services that really send mail for you.

• Turn on DKIM signing at your provider and publish the public key it gives you.

• Publish a DMARC record, starting with p=none and a reporting address.

• Make sure every third-party service that sends as you (newsletters, invoicing, support tools) is covered by SPF or DKIM.

• Review the DMARC reports, then tighten the policy to quarantine and later reject.

• If you run your own mail server rather than using a provider, set up reverse DNS and keep it patched. Most people are better off using a provider.

Key Takeaways

• SMTP sends and relays email, while IMAP reads it from the mailbox.

• MX records in DNS tell servers where to deliver mail for a domain.

• Every message has two "from" addresses: the envelope sender and the visible header, and attackers exploit the gap.

• SPF lists who may send, DKIM signs the message, and DMARC ties them to the visible From address and sets the policy.

• Email isn't private by default, so treat sensitive information accordingly.

Conclusion

Email is a patchwork: a trusting, decades-old delivery system with authentication layered on top. Once you see the path (client, outgoing server, MX lookup, recipient's server, mailbox), most email mysteries become traceable. A bounce tells you where it failed, the headers tell you which servers touched it, and the DNS records tell you whether the sender was legitimate.

If you own a domain, spending an hour on SPF, DKIM, and DMARC is one of the highest-value things you can do for both your security and your deliverability.