Jarle Mathiesen
← Back to all posts

Understanding Email Under the Hood: A Developer's Guide

22 Sept 2025•7 min read

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 post 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 + 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 (simplified):

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 ~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 does one server even know 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’s called this because 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 (HELO, MAIL FROM, RCPT TO, DATA) over a TCP connection. It is the standard used to send mail between servers, typically over TCP port 25. Your provider (e.g., 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 shown earlier with plain text, HTML, and attachments separated by boundaries.
  3. Gmail’s SMTP server asks DNS for the recipient’s MX record (a special DNS entry that lists which mail servers handle mail for that domain). This is like doing a DNS query such as dig MX gmail.com, which returns hostnames like aspmx.l.google.com. That tells Gmail exactly which server it should connect to in order to hand over the message.
  4. The sending SMTP server then resolves the MX hostname to an IP address (via DNS), connects directly to that IP on the recipient’s MX server using the SMTP protocol (usually 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, often in the user’s mailbox directory or database. The storage format (e.g., Maildir, mbox, or a proprietary system like Gmail’s) is up to the provider, not defined by SMTP.
  6. The recipient email client downloads or syncs the raw MIME file from the provider’s mail storage (if you’ve seen terms like IMAP or POP3 and wondered what they were: these are just common protocols clients use to fetch mail from storage, along with web APIs). The client now has the same text-based MIME content that the server stored.
  7. The client then parses and decodes the MIME parts. Conventionally, it shows the HTML part if present, or plain text otherwise. Attachments appear separately, and inline images are displayed in context. These conventions come from how MIME and clients evolved, not from SMTP itself.

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: anyone can put From: [email protected] in a header. To fight spoofing, we have three key mechanisms:

SPF (Sender Policy Framework)

  • Domain owner publishes a TXT record in DNS, often called an SPF record, which lists the IPs allowed to send mail for that domain.
  • Receiver checks: “What IP address did this message actually come from when the sending server connected?” and then: “Does this sender IP match the domain’s SPF record?”
  • If not → SPF fails. Concretely, this means the receiver has detected that the sending IP is not authorized for that domain. What happens next depends on policy: some providers still deliver the mail (maybe to spam), others quarantine it. Later we’ll see how DMARC lets the domain owner say “reject this mail entirely” if SPF or DKIM fail.

Example:

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

The include:_spf.google.com part is itself a reference to another SPF record. This means the receiver must do another DNS lookup to fetch and apply Google’s own published 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 (for example the From, To, Subject headers and the body), makes a cryptographic hash of them, and then signs that hash with a private key only it knows. This signature is added to the message in a special header called DKIM-Signature.

When the receiving server gets the message, it looks up the corresponding public key in DNS (the domain owner publishes this as a TXT record, for example: selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."). Using that public key, it can check 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 (since only it had the private key).
  • The message hasn’t been altered in transit — if even a single character changes, the signature check fails.

So DKIM helps answer the question: Did this email really come from who it claims, and is it intact? For example, you might see a DKIM-Signature header in a raw email that looks like this:

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 you (the receiver) to do with it.” In other words, it’s the domain owner’s way of telling the world how strictly to treat unauthenticated mail.

Without DMARC, a receiver might just make its own guess — deliver anyway, put it in spam, or reject. 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.

So while SPF answers “Is this IP allowed?” and DKIM answers “Is this message intact and signed by the right domain?”, DMARC answers “What should happen if those checks fail, and how can I monitor attempts to abuse my domain?”

Example:

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

This means providers like Gmail will 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 (Gmail, Outlook, Yahoo, ProtonMail, etc.) do. But weaker or poorly configured providers might not check SPF/DKIM/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 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/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 and reliably 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, I hope this post made things a little clearer.

💡 A fun next step: open one of your own emails and view the raw source (most clients have a “Show original” or “View source” option). In Gmail, for example, you can click the three-dot menu and choose Show original, then even download the full raw message as a .eml file. That .eml file is the MIME message — you can open it in a text editor to see all the headers, boundaries, and Base64 attachments yourself.