How Secure Email Works: Encryption, S/MIME, and Email Authentication

Why Email Was Never Designed to Be Secure

When engineers designed email in the early 1970s, security was not a concern. SMTP (Simple Mail Transfer Protocol), the protocol that still carries most email today, was created to move messages between academic and research computers in a trusted environment. It has no built-in encryption, no sender verification, and no mechanism to detect tampering. An email traveling from sender to recipient passes through multiple servers, and at each hop the message is readable in plain text by anyone with access to those servers.

This architectural reality created the foundation for nearly every email-based attack: phishing, business email compromise, email spoofing, and man-in-the-middle interception. Decades of security standards have been layered on top of SMTP to address these weaknesses, but understanding secure email requires understanding both what these standards protect against — and where they fall short.

Transport-Level Encryption: TLS and STARTTLS

The first layer of email security is transport encryption, which protects messages while they travel between mail servers. When two mail servers exchange messages using STARTTLS, they negotiate a TLS (Transport Layer Security) session and encrypt the communication channel. This prevents eavesdroppers from reading messages as they cross the network.

However, STARTTLS has important limitations:

• Opportunistic, not mandatory: Standard STARTTLS is opportunistic — if the receiving server does not support TLS, the message falls back to plain text. Attackers can exploit this by stripping the STARTTLS negotiation, forcing unencrypted delivery.
• Hop-by-hop, not end-to-end: TLS encrypts the connection between servers, but each mail server decrypts the message before re-encrypting it for the next hop. The server operator can read the message in plain text.
• No authentication of endpoints: Without certificate validation, a server cannot verify it is communicating with the legitimate destination server rather than an attacker's server.

MTA-STS (Mail Transfer Agent Strict Transport Security) addresses the downgrade attack problem by allowing domains to publish a policy requiring TLS for all inbound connections. SMTP TLS Reporting (TLS-RPT) provides a mechanism for receiving failure reports when TLS connections cannot be established.

End-to-End Encryption: PGP and S/MIME

True secure email requires end-to-end encryption (E2EE), where messages are encrypted by the sender and can only be decrypted by the intended recipient. Even the mail server operators cannot read the content. Two main standards provide this capability: PGP and S/MIME.

Both systems use asymmetric cryptography. Each user has a public key (shared openly) and a private key (kept secret). To send an encrypted message, the sender encrypts it with the recipient's public key. Only the recipient's private key can decrypt it. Digital signatures work in reverse: the sender signs the message with their private key, and the recipient verifies the signature using the sender's public key — confirming both authorship and that the message has not been tampered with.

The practical barrier to widespread E2EE email adoption is key management. Both sender and recipient must have compatible software and exchange keys before communicating. If a recipient loses their private key, all previously encrypted messages become permanently unreadable. These usability challenges explain why most consumer email remains unencrypted at the content level, even when transmitted over TLS connections.

Email Authentication: SPF, DKIM, and DMARC

While encryption addresses confidentiality and integrity, a separate set of standards addresses authentication — verifying that an email actually originated from the domain it claims to represent. These standards are critical for preventing spoofing and phishing.

SPF (Sender Policy Framework)

SPF allows domain owners to publish a list of authorized mail servers for their domain in DNS. When a receiving server gets an email claiming to be from example.com, it checks the SPF record to verify that the sending server is on the authorized list. If not, the message can be marked as spam or rejected.

SPF has a significant limitation: it checks the envelope sender (the technical return path address) rather than the From header that users see in their email client. Attackers can pass SPF while still displaying a spoofed From address.

DKIM (DomainKeys Identified Mail)

DKIM provides cryptographic proof that a message was sent by an authorized server for the claimed domain. The sending mail server signs outgoing messages with a private key, embedding the signature in a message header. Receiving servers retrieve the corresponding public key from DNS and verify the signature. This confirms both that the message originated from an authorized server and that specific headers and the message body have not been modified in transit.

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

DMARC ties SPF and DKIM together and adds policy enforcement. Domain owners publish a DMARC record specifying what receiving servers should do when a message fails authentication: nothing (p=none), quarantine to spam (p=quarantine), or reject outright (p=reject). DMARC also enables reporting, so domain owners receive aggregate reports showing authentication results for their domain — revealing phishing attempts and configuration problems.

Secure Email Gateways and Additional Protections

Beyond authentication standards, organizations deploy Secure Email Gateways (SEGs) that inspect inbound and outbound messages for threats. Modern SEGs use multiple detection layers:

• Anti-spam filtering: Machine learning models assess message characteristics, sender reputation, and content to classify messages as spam or legitimate.
• Anti-malware scanning: Attachments are scanned against malware signatures and detonated in sandboxes to detect malicious behavior.
• URL rewriting and sandboxing: Links in messages are rewritten to pass through a proxy that checks URLs at click time against threat intelligence feeds.
• Impersonation protection: Heuristics detect display name spoofing, lookalike domains, and other techniques used in business email compromise attacks.
• Data Loss Prevention (DLP): Outbound scanning prevents employees from accidentally or intentionally sending sensitive data like credit card numbers or source code via email.

Encrypted Email Services

Several email services have been built from the ground up with security and privacy as core principles. ProtonMail (now Proton Mail) and Tutanota offer end-to-end encryption for messages exchanged between users of the same platform, with zero-access encryption for stored messages — meaning the service provider cannot read user emails. When communicating with external recipients who do not use the same service, messages can be sent with password-based encryption or fall back to standard (unencrypted) delivery.

These services represent a significant improvement over mainstream providers for users with strong privacy requirements, but they require both parties to adopt compatible tools for full E2EE capability — the same usability challenge that has limited PGP adoption for decades.

Secure email is ultimately a layered discipline: transport encryption protects the connection, authentication standards prevent spoofing, end-to-end encryption protects content, and gateway security filters threats before they reach the inbox. No single technology solves the problem completely, which is why a defense-in-depth approach remains the standard for organizations serious about email security.