The TLDR

Email was designed in 1971 as a way for researchers to send messages between computers on a trusted network. Security was not a consideration because the internet didn’t exist yet. Fifty-five years later, email is still the primary communication channel for business, authentication (password resets, verification codes), and phishing. The security protocols layered on top — SPF, DKIM, DMARC — prevent sender spoofing but don’t encrypt the message. Your email travels across the internet like a postcard: the address is verified, but anyone handling it can read the contents.

The Reality

Let’s trace a phishing email through the delivery stack:

  1. Attacker registers arnazon-support.com — close enough to Amazon to fool a glance
  2. Attacker sets up SPF, DKIM, and DMARC on their domain — yes, phishing domains can pass authentication because these protocols verify the domain, not the sender’s intent
  3. Email is sent via SMTP from the attacker’s server. The “From” display name says “Amazon Customer Support.” The actual domain is arnazon-support.com.
  4. Receiving server checks SPF: Is this server authorized to send for arnazon-support.com? Yes — the attacker configured it.
  5. Receiving server checks DKIM: Is the message cryptographically signed by arnazon-support.com? Yes — the attacker has the private key for their own domain.
  6. Receiving server checks DMARC: Does the sender’s DMARC policy pass? Yes — all checks pass for the attacker’s domain.
  7. Email lands in your inbox. It passed every authentication check. The only clue is the domain, and most people don’t check.

This is why SPF, DKIM, and DMARC are necessary but insufficient. They verify that an email came from who it claims to come from. They don’t verify that who it claims to come from is trustworthy.

How Email Works

SMTP — The Protocol

Simple Mail Transfer Protocol, designed in 1982 (RFC 821), is the protocol that sends email. It’s a text-based protocol with no built-in authentication, encryption, or integrity checking.

When you send an email:

  1. Your email client connects to your mail server (usually over TLS now)
  2. Your mail server looks up the recipient’s mail server via DNS MX records
  3. Your mail server connects to the recipient’s server and delivers the message
  4. The recipient’s server stores the message until the recipient retrieves it

Each hop in this chain is a potential interception point. TLS encrypts the connection between servers (opportunistic TLS is widespread), but it’s not guaranteed, and the servers themselves can read the message.

Why the “From” Header Can Lie

SMTP has two layers of addressing:

This is like writing someone else’s return address on an envelope. The postal system doesn’t verify return addresses. Neither does SMTP by default. SPF, DKIM, and DMARC were created to fix this.

Authentication Protocols

SPF (Sender Policy Framework)

SPF lets a domain owner publish a DNS record listing which servers are authorized to send email for that domain.

When your mail server receives an email claiming to be from bank.com, it checks bank.com’s SPF record. If the sending server’s IP isn’t listed, SPF fails.

What SPF prevents: Unauthorized servers sending email that claims to be from your domain.

What SPF doesn’t prevent: An attacker sending email from their own domain that looks like yours. SPF only checks the envelope sender, not the display name.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to the email headers. The sending server signs the message with a private key; the receiving server verifies the signature using a public key published in DNS.

What DKIM prevents: Message tampering in transit. If anyone modifies the email after it’s signed, the signature breaks.

What DKIM doesn’t prevent: Phishing from domains the attacker controls and has signed.

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

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails:

DMARC also requires “alignment” — the domain in the “From” header must match the domain verified by SPF or DKIM.

What DMARC prevents: Exact-domain spoofing. An attacker can’t send an email with a “From” of @bank.com that passes DMARC (assuming Bank of America has DMARC set to reject).

What DMARC doesn’t prevent: Lookalike domains (@bank-secure.com, @bankofamerica-support.com). These pass DMARC because the attacker controls the domain and has set up SPF and DKIM for it.

Email Encryption

S/MIME and PGP

Two encryption standards exist for email: S/MIME (built into Outlook and Apple Mail) and PGP/GPG (command-line and plugin-based).

Both work on the same principle: the sender encrypts the message with the recipient’s public key, and only the recipient’s private key can decrypt it.

Adoption is near zero. In practice, almost nobody uses email encryption because:

ProtonMail’s Model

ProtonMail offers “encrypted email” with a significant caveat: emails between ProtonMail accounts are end-to-end encrypted. Emails to/from non-ProtonMail addresses are encrypted at rest on ProtonMail’s servers but travel in plaintext over the internet like any other email.

ProtonMail can’t read your stored email (zero-access encryption), which is better than Gmail or Outlook. But the message itself isn’t protected in transit to non-ProtonMail recipients.

The Practical Reality

For the foreseeable future, email is not and will not be an end-to-end encrypted medium. If you need encrypted communication, use Signal, not email.

iOS Mail Privacy Protection

Apple’s Mail Privacy Protection (iOS 15+) addresses one specific email tracking vector: tracking pixels.

How tracking pixels work: Marketers embed a tiny invisible image in emails. When you open the email, your email client loads the image from the marketer’s server, revealing your IP address, location, device type, and the exact time you opened the email.

What Mail Privacy Protection does: It pre-loads all remote content (including tracking pixels) through Apple’s proxy servers. The marketer sees Apple’s proxy IP, not yours. They can’t determine when or if you opened the email.

What it doesn’t do: It doesn’t encrypt your email. It doesn’t prevent phishing. It doesn’t stop your email provider from reading your messages.

What You Can Do

Practical Email Security

Verifying a Suspicious Email

If you receive an email you’re not sure about:

  1. Check the actual sender address (not the display name)
  2. Hover over links to see the actual URL (don’t click)
  3. Look for urgency language (“Act now,” “Your account will be suspended”)
  4. When in doubt, contact the supposed sender through a different channel (call them, visit their website directly)

For Organizations

Sources & Further Reading