How Email Encryption Works: SPF, DKIM, TLS, and End-to-End

The Starting Point: Email Without Encryption

When SMTP was designed in 1982, messages were sent as plain text across the network. Anyone with access to a network hop between sender and recipient could read the content. There was no way to verify who actually sent a message — the "From" field could contain anything. This was acceptable in a network of trusted academic institutions, but it became a massive problem as the internet grew to billions of users.

Today, email security relies on several independent but complementary technologies, each addressing a different vulnerability. Think of them as layers of armor, each protecting against a specific type of attack.

SPF: Who Is Allowed to Send?

Sender Policy Framework (SPF) addresses a simple question: is this server actually authorized to send email for this domain? Without SPF, anyone can send an email claiming to be from your-bank.com — the protocol has no built-in way to verify the claim.

SPF works through DNS records. A domain owner publishes a TXT record listing the IP addresses and servers authorized to send email on their behalf. When a receiving server gets an email from "user@example.com," it looks up example.com's SPF record and checks whether the sending server's IP is on the authorized list. If not, the email can be flagged or rejected.

SPF has limitations. It only checks the "envelope from" address (used during SMTP transmission), not the "header from" address (displayed to the user). It also breaks when emails are forwarded, because the forwarding server is not on the original domain's SPF list.

DKIM: Is This Message Authentic?

DomainKeys Identified Mail (DKIM) takes a different approach. Instead of verifying the server, it verifies the message itself. The sending server adds a cryptographic signature to each outgoing email, using a private key that only it possesses. The corresponding public key is published in the domain's DNS records.

When the receiving server gets the email, it retrieves the public key from DNS and uses it to verify the signature. If the signature checks out, it means: (1) the email was sent by a server holding the private key for that domain, and (2) the message content has not been altered since it was signed.

DKIM survives forwarding (unlike SPF) because the signature travels with the message. However, mailing lists that modify the message body or headers will break the signature.

TLS: Encryption in Transit

Transport Layer Security (TLS), applied to SMTP via the STARTTLS extension, encrypts the connection between mail servers. When two SMTP servers communicate, the sending server can issue a STARTTLS command to upgrade the connection from plain text to encrypted. This prevents eavesdroppers from reading the message content as it travels between servers.

However, STARTTLS is typically "opportunistic" — if the receiving server does not support it, the message is sent unencrypted. A network attacker can also perform a downgrade attack, stripping the STARTTLS offer from the server response. MTA-STS and DANE are newer standards designed to enforce TLS and prevent such downgrades, but adoption is still growing.

It is crucial to understand that TLS only protects data in transit. Once the email reaches the destination server, it is stored in whatever format the server uses — often unencrypted. TempoMail addresses this by encrypting all stored emails with AES-256-GCM, ensuring that even if the storage is compromised, the contents remain protected.

End-to-End Encryption: The Gold Standard

End-to-end encryption (E2EE) is the only approach that protects email content from everyone except the sender and the intended recipient — including the email providers themselves. The two main standards are PGP (Pretty Good Privacy) and S/MIME.

With PGP, each user generates a public-private key pair. To send an encrypted email, you encrypt the message with the recipient's public key. Only their private key can decrypt it. S/MIME works similarly but uses certificates issued by certificate authorities instead of a web of trust.

Despite being available for decades, E2EE adoption in email remains low. The key management problem — distributing, verifying, and storing keys — creates friction that most users are unwilling to accept. Services like ProtonMail have simplified this by handling key management transparently, but they only work between ProtonMail users by default.

Putting It All Together

In practice, these technologies work together: SPF and DKIM verify the sender's identity, DMARC provides policy enforcement, TLS protects the message in transit, and E2EE (when used) protects the content itself. No single technology solves every problem, but together they have made email significantly more secure than its unprotected origins.

For everyday privacy, using a disposable email address for untrusted services is one of the most practical steps you can take — it sidesteps the entire question of whether a service properly implements encryption by ensuring your real address is never exposed in the first place.