Guides

Understanding Email Under the Hood

  • Email
  • Infrastructure
  • DNS
  • Security

A developer's guide to how email actually works, from MIME and MX records to SMTP, SPF, DKIM, and DMARC.

Like many developers, I’ve used email libraries to send messages, created MimeMessage objects, and attached files. But until recently, I didn’t really know what was happening under the hood.

If you’ve ever asked yourself questions like “What actually happens when I press send?”, “Why do I have to add all these DNS entries?”, or “How does SPF or DMARC actually stop spoofing?”, this guide is for you.

From Plain Text to MIME

Originally, email was just plain ASCII text. No attachments, no emojis, no HTML. That quickly became limiting, so MIME (Multipurpose Internet Mail Extensions) was introduced. MIME allows emails to include:

  • Multiple character sets (UTF-8, etc.)
  • Attachments (images, PDFs)
  • Multiple representations (plain text and HTML)
  • Embedded content (inline images)

A MIME email is just a specially formatted text file. Attachments are Base64-encoded and embedded right in the message.

Example:

From: [email protected]
To: [email protected]
Subject: Hello
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="123"

--123
Content-Type: text/plain; charset=UTF-8

This is the plain text body.
--123
Content-Type: application/pdf; name="file.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="file.pdf"

JVBERi0xLjQKJ... (base64 content)
--123--

No hosting magic: the file is right there in the email. If your 5 MB PDF gets attached, Base64 encoding makes it roughly 6.7 MB over the wire.

So far we’ve talked about what an email looks like and how it’s packaged up. The next natural question is how one server even knows where to send it. That’s where MX records come in.

MX Records Explained

Before authentication, the very first step is knowing where to deliver mail. MX (Mail Exchange) records in DNS are like an address card that lists which computers on the internet are responsible for receiving mail for a domain.

In normal speak, they tell other mail servers exactly which machines they should connect to. Each record has a priority, and mail servers try the lowest number first.

Example:

gmail.com.  IN MX 10 aspmx.l.google.com.
gmail.com.  IN MX 20 alt1.aspmx.l.google.com.
gmail.com.  IN MX 30 alt2.aspmx.l.google.com.

This tells the world that Gmail accepts mail at aspmx.l.google.com first, and if that fails, try the alternates in order.

How the Email Travels

Before we go step by step, let’s define a key actor: the SMTP server.

SMTP stands for Simple Mail Transfer Protocol. It is a simple, text-based set of rules for transferring mail. What makes something “SMTP” is that both the client and server speak this protocol: they exchange specific commands and responses like HELO, MAIL FROM, RCPT TO, and DATA over a TCP connection. It is the standard used to send mail between servers, typically over TCP port 25.

Your provider, such as Gmail, operates one or more SMTP servers to accept outgoing mail and deliver it to the recipient’s MX servers.

  1. You hit send in Gmail or your provider.
  2. Gmail builds a MIME message, just like the example above, with plain text, HTML, and attachments separated by boundaries.
  3. Gmail’s SMTP server asks DNS for the recipient’s MX record. This is like running dig MX gmail.com, which returns hostnames like aspmx.l.google.com. That tells Gmail exactly which server it should connect to.
  4. The sending SMTP server resolves the MX hostname to an IP address, connects directly to that IP on the recipient’s MX server using SMTP, usually over TCP port 25, and streams the full MIME message over that connection.
  5. The recipient MX server hands the message off to the provider’s mail storage system. In practice, this means writing the raw MIME file onto disk or distributed storage managed by the provider.
  6. The recipient email client downloads or syncs the raw MIME file from storage, usually via IMAP, POP3, or a web interface.
  7. The client parses and decodes the MIME parts. It usually shows the HTML part if present, or plain text otherwise. Attachments appear separately, and inline images are displayed in context.

When we receive a message, how can we know that the sender is really who they claim to be? That’s where authentication comes in.

Authenticating Email: SPF, DKIM, DMARC

Email’s biggest problem is that anyone can put From: [email protected] in a header. To fight spoofing, we have three key mechanisms.

SPF (Sender Policy Framework)

  • The domain owner publishes a TXT record in DNS that lists the IPs allowed to send mail for that domain.
  • The receiver checks which IP address the message actually came from, then compares that IP against the domain’s SPF record.
  • If the sender IP is not authorized, SPF fails.

Example:

example.com. TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all"

The include:_spf.google.com part is a reference to another SPF record. This means the receiver has to do another DNS lookup to fetch and apply Google’s own list of authorized sending servers.

DKIM (DomainKeys Identified Mail)

DKIM is like putting a wax seal on your message. When the sending server prepares your email, it takes certain parts of the message, such as the From, To, Subject headers and the body, hashes them, and signs that hash with a private key only it knows. This signature is added to the message in a DKIM-Signature header.

When the receiving server gets the message, it looks up the corresponding public key in DNS and checks that the signature matches the message contents. If it does, it proves two things:

  • The message really was sent by a server trusted by that domain.
  • The message hasn’t been altered in transit.

Example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
 h=from:to:subject:date;
 bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
 b=Y2c7sQqA...longsignature...

Here d=example.com shows which domain signed it, s=selector1 points to the DNS record holding the public key, and b= is the cryptographic signature itself.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

SPF and DKIM each tell part of the story, but DMARC ties it all together. DMARC lets the domain owner publish a rule in DNS that says: if a message claims to be from me but fails SPF and or DKIM, here’s what I want the receiver to do with it.

Without DMARC, a receiver might make its own guess: deliver anyway, put it in spam, or reject it. With DMARC, the sender can explicitly request one of those actions.

DMARC also adds reporting. Receivers like Gmail or Outlook can send the domain owner daily XML reports showing how many emails passed or failed, which IPs sent them, and whether spoofing attempts are happening.

Example:

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
  • p=reject means reject failed mail.
  • rua=... means send daily aggregate reports of spoofing attempts.

This means providers like Gmail can send you XML reports showing who is trying to spoof your domain, how many emails failed, and from where.

Do All Providers Respect This?

No. Responsible providers such as Gmail, Outlook, Yahoo, and ProtonMail do. But weaker or poorly configured providers might not check SPF, DKIM, and DMARC strictly, which can let spoofed emails through.

Still, publishing correct records and enforcing a strict DMARC policy greatly reduces risk for both your brand and your recipients.

Other Pieces Worth Knowing

  • Envelope vs From header: SPF checks the hidden SMTP envelope sender, not just the visible From: header. DMARC ties them together.
  • Spam filters: even with SPF, DKIM, and DMARC, providers add IP reputation, content checks, and heuristics.
  • ARC (Authenticated Received Chain): a newer standard to preserve authentication results when mail is forwarded.

Closing Thoughts

Most of us developers just want to send a reset link or attach a PDF invoice. But under the hood, email is a 50-year-old protocol that has proven remarkably robust. Over decades it has been extended with things like MIME, DNS-based records, and authentication layers, yet it continues to interoperate globally across countless providers.

Understanding how MIME, SMTP, SPF, DKIM, and DMARC fit together will make you:

  • Better at diagnosing delivery issues.
  • Safer when handling user-facing communication.
  • A more confident owner of your domain’s reputation.

If you’ve ever scratched your head at an email header dump, the best next step is simple: open one of your own emails and view the raw source. Most clients have a “Show original” or “View source” option. That raw .eml file is the MIME message, and it is one of the fastest ways to make all of this feel concrete.