Email Security

• Email Security
  • Securing a protocol that was built with no security
  • How email actually flows
  • Transport security: encrypting the hops
    • TLS on each hop, and its gap
  • Authentication: proving who really sent it
    • SPF — which servers may send for a domain
    • DKIM — a cryptographic signature on the message
    • DMARC — alignment and a policy
    • What the trio does — and does not — stop
  • End-to-end content encryption
  • Worked example: auditing a domain’s email security
  • Key takeaways
  • References

Securing a protocol that was built with no security

Email predates almost everything else on the modern Internet, and SMTP — the Simple Mail Transfer Protocol — was standardized in 1982 with no authentication, no encryption, and no integrity protection. It was designed for a small, trusting research network where anyone could relay mail for anyone and the From: line was taken at face value. That trust assumption is why your inbox is full of spam and why Business Email Compromise costs billions a year.

Crucially, the From: header is just text the sender types — there is nothing in base SMTP stopping anyone from claiming to be ceo@yourcompany.com. Everything on this page is a layer bolted on afterward to retrofit security onto that 1982 design.

It helps to separate two completely different problems, because they use different mechanisms and solve different threats:

1. Transport confidentiality — stopping someone from reading or tampering with mail as it crosses the network (eavesdroppers on the wire). Solved by TLS on each hop.
2. Authenticity / anti-spoofing — proving a message actually came from the domain it claims, and was not forged. Solved by SPF, DKIM, and DMARC.

A message can have perfect transport encryption and still be a forgery; it can be perfectly authenticated and still be sent in cleartext. You need both.

How email actually flows

Understanding where the security controls attach requires knowing the path a message takes. There are two distinct legs, with different protocols and ports:

  ┌──────────┐  submission   ┌───────────┐   relay (SMTP)   ┌───────────┐   access    ┌──────────┐
  │  Sender  │──────────────▶│  Sender   │─────────────────▶│ Recipient │────────────▶│ Recipient│
  │  (MUA)   │  port 587/465 │  mail svr │     port 25      │  mail svr │ IMAP/POP    │  (MUA)   │
  └──────────┘   SMTP+auth   │  (MSA/MTA)│   MTA-to-MTA     │   (MTA)   │ 993 / 995   └──────────┘
                             └───────────┘                  └───────────┘

Two ways to add TLS, and the difference matters:

• STARTTLS (opportunistic / explicit TLS) — the connection starts in cleartext and then issues a STARTTLS command to upgrade to encryption. The weakness: an active attacker can strip the STARTTLS offer out of the unencrypted opening exchange, and the connection silently falls back to plaintext (a downgrade attack).
• Implicit TLS — the whole connection is TLS from the first byte, on a dedicated port (465/993/995). Nothing happens in cleartext, so there is nothing to strip. RFC 8314 (2018) recommends implicit TLS for submission and access for exactly this reason — the “use 587 with STARTTLS” advice you’ll still see online is now dated for client submission.

Transport security: encrypting the hops

TLS on each hop, and its gap

When two mail servers talk over SMTP (port 25), modern servers negotiate opportunistic TLS. The problem: relay TLS is opportunistic — if the far end doesn’t offer it, or an attacker strips it, mail is delivered in cleartext rather than not at all (mail’s “deliver no matter what” culture). Two mechanisms close that gap by letting a domain demand TLS:

• MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) — a domain publishes a policy, fetched over HTTPS at a well-known URL, saying “always use TLS with a valid certificate to reach my mail servers; refuse to deliver otherwise.” It does not require DNSSEC, but the very first contact is trust-on-first-use (cached thereafter).
• DANE for SMTP (RFC 7672) — the domain pins its mail server’s TLS certificate directly in DNS via a TLSA record, protected by DNSSEC (covered in network-security). Stronger than MTA-STS (no first-use gap) but requires DNSSEC deployment.

Both prevent the silent downgrade-to-cleartext that plain opportunistic TLS allows.

⚠️ Transport TLS protects mail in transit between servers, not at rest and not end to end. Every relay decrypts the message, can read it, and re-encrypts it for the next hop. Your provider, and every intermediary, sees the plaintext. True end-to-end confidentiality requires content encryption (S/MIME or PGP — see below).

Authentication: proving who really sent it

This is the anti-spoofing trio, and it is what the phishing dissection on the social-engineering page actually checks. The three work together: SPF and DKIM each authenticate something, and DMARC ties them to the visible From: and tells receivers what to do on failure.

SPF — which servers may send for a domain

Sender Policy Framework (RFC 7208) is a DNS TXT record listing the IP addresses/hosts authorized to send mail for a domain. The receiving server checks whether the connecting IP is on the list.

$ dig +short TXT example.com | grep spf
"v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all"
                                                     │
                                                     └ -all = HARD FAIL: reject
                                                       anything not listed above
                                                       (~all = soft fail / mark)

SPF’s blind spot: it authenticates the envelope sender (MAIL FROM / Return-Path), not the From: header the user sees — and it breaks on forwarding, because the forwarder becomes the new sending IP. SPF alone cannot stop From: spoofing.

DKIM — a cryptographic signature on the message

DomainKeys Identified Mail (RFC 6376) has the sending server sign selected headers and the body with the domain’s private key. The matching public key is published in DNS, so any receiver can verify the signature — proving the message genuinely came from that domain and was not altered in transit. This is the digital-signature primitive applied to email.

$ dig +short TXT selector1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
        (the domain's public key; the message carries the selector + signature
         in its DKIM-Signature: header)

Unlike SPF, DKIM survives forwarding (the signature travels with the message) and proves integrity, not just origin IP.

DMARC — alignment and a policy

SPF and DKIM each have gaps, and neither, by itself, protects the visible From: domain. DMARC (RFC 7489) closes the loop:

1. Alignment — it requires that the domain validated by SPF or DKIM matches the From: header domain. This is what finally protects the address the human reads.
2. Policy — the domain publishes what receivers should do when alignment fails: p=none (monitor only), p=quarantine (spam folder), or p=reject (bounce outright).
3. Reporting — receivers send aggregate (rua) reports back, so a domain owner can see who is sending — and spoofing — as them.

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
            │                                       └ strict alignment
            └ tell the world: reject mail that fails DMARC for example.com

• ARC (Authenticated Received Chain, RFC 8617) repairs the forwarding case by letting intermediaries vouch for authentication results that would otherwise break.
• BIMI displays a verified brand logo in the inbox, but only for domains already at DMARC p=quarantine/reject — an incentive to deploy DMARC.

What the trio does — and does not — stop

That right-hand column is precisely why Business Email Compromise and phishing still succeed in a world of near-universal DMARC: the attacker simply doesn’t forge a protected domain — they use a convincing look-alike or a real, stolen account. Email authentication is necessary, not sufficient.

End-to-end content encryption

Transport TLS, as noted, leaves the plaintext readable at every relay. For genuine end-to-end confidentiality and integrity — where only the intended recipient can read the message — you encrypt the content itself:

• S/MIME — uses X.509 certificates (the same PKI as TLS); common in enterprise/government, built into most mail clients.
• OpenPGP / GPG — uses a web-of-trust or manually exchanged keys; common among technologists and journalists.

Both provide confidentiality (encryption) and authenticity (signatures) that hold all the way to the recipient, independent of how many servers the message passes through. The cost is key management — the hard problem cryptography keeps running into — which is why content encryption remains far less widely deployed than transport TLS.

Worked example: auditing a domain’s email security

You can assess any domain’s posture from the command line with dig, reading the four records that matter:

# 1. SPF — who may send?
$ dig +short TXT pdx.edu | grep spf
"v=spf1 include:spf.protection.outlook.com -all"

# 2. DMARC — is spoofing rejected, and are reports collected?
$ dig +short TXT _dmarc.pdx.edu
"v=DMARC1; p=reject; rua=mailto:..."         # p=reject is the strong answer

# 3. MTA-STS — is TLS enforced for inbound mail?
$ dig +short TXT _mta-sts.pdx.edu
"v=STSv1; id=20240101000000Z"                 # policy exists; fetch it over HTTPS

# 4. DANE — is the MX certificate pinned in DNSSEC?
$ dig +short TLSA _25._tcp.mail.pdx.edu
# (a TLSA record here, with a DNSSEC-validated zone, means DANE is in use)

A well-secured domain shows: an SPF record ending in -all, DMARC at p=reject, and MTA-STS and/or DANE for inbound TLS enforcement. A domain with p=none and no MTA-STS is trivially spoofable and downgradeable — exactly what an attacker looks for.

And on a received message, the receiving server’s verdict is summarized in one header (this is the header dissected on the social-engineering page):

Authentication-Results: mx.pdx.edu;
       spf=pass    smtp.mailfrom=example.com;
       dkim=pass   header.d=example.com;
       dmarc=pass  (p=reject) header.from=example.com

Three pass results with aligned domains is a message that is who it says it is — though, per the table above, still not necessarily trustworthy.

Key takeaways

• SMTP was built in 1982 with no security; the From: header is free text. Everything here is retrofitted on top.
• Separate the two problems: transport confidentiality (TLS per hop) and authenticity (SPF/DKIM/DMARC). You need both, and neither implies the other.
• Prefer implicit TLS (ports 465/993/995, RFC 8314) over STARTTLS, which is strippable; enforce server-to-server TLS with MTA-STS and/or DANE to block silent downgrade.
• The anti-spoofing trio: SPF authenticates the sending IP (breaks on forwarding), DKIM cryptographically signs the message (survives forwarding, proves integrity), and DMARC enforces alignment with the visible From: plus a published policy (p=reject is the goal).
• Authentication stops domain forgery, not look-alike domains, display-name spoofing, or compromised accounts — which is why phishing/BEC still works.
• Transport TLS is not end-to-end; only S/MIME or PGP encrypt content all the way to the recipient.

References

• RFC 5321 — Simple Mail Transfer Protocol (SMTP). https://datatracker.ietf.org/doc/html/rfc5321
• RFC 8314 — Cleartext Considered Obsolete: implicit TLS for email submission and access. https://datatracker.ietf.org/doc/html/rfc8314
• RFC 7208 — Sender Policy Framework (SPF). https://datatracker.ietf.org/doc/html/rfc7208
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures. https://datatracker.ietf.org/doc/html/rfc6376
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://datatracker.ietf.org/doc/html/rfc7489
• RFC 8617 — Authenticated Received Chain (ARC). https://datatracker.ietf.org/doc/html/rfc8617
• RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS). https://datatracker.ietf.org/doc/html/rfc8461
• RFC 7672 — SMTP Security via Opportunistic DANE TLS. https://datatracker.ietf.org/doc/html/rfc7672
• NIST SP 800-177 Rev. 1 — Trustworthy Email. https://csrc.nist.gov/pubs/sp/800/177/r1/final
• M3AAWG — Email Authentication best practices. https://www.m3aawg.org/published-documents

Related course pages: Social Engineering · Cryptography · Introduction to Networking · Network Security · Identity and Access Management

🛠️ Maintenance note: RFC 8314’s implicit-TLS recommendation (465/993/995 over 587+STARTTLS) is current as of 2018 and still widely mis-stated online — re-check before each term. BIMI and DMARC alignment defaults continue to evolve at the major mailbox providers (Google/Yahoo/Microsoft bulk-sender requirements changed in 2024); refresh that detail yearly.