Email & Cryptography Glossary

In a zero-knowledge system, encryption and decryption occur exclusively on the user's client device (browser or mobile app) using keys derived locally from their master password. When data is transmitted to the provider's servers, it arrives as ciphertext. Even if the server infrastructure is compromised, subpoenaed, or subjected to regulatory inspection, no plaintext data can ever be extracted because the provider never receives or stores the decryption keys.

End-to-End Encryption ensures that data is encrypted on the sender's device and can only be decrypted by the intended recipient. Unlike standard Transport Layer Security (TLS), which only protects messages during transit between servers (allowing the email provider to read messages at rest), E2EE keeps the message sealed across the entire transmission path and server storage.

The Master Identity Key acts as the root of trust in modern zero-knowledge architectures. Using high-iteration key derivation functions like Argon2id or PBKDF2 with SHA-256, the MIK is computed locally in the browser. It proves the user's identity to the authentication gateway without revealing the password itself, and unlocks the secondary symmetric keys that encrypt individual mailbox folders and messages.

Key Derivation Functions make brute-force attacks computationally impractical by requiring massive amounts of memory and CPU cycles to test passwords. Algorithms like Argon2id and PBKDF2 protect users by ensuring that even weak passwords take billions of computations to crack if an encrypted blob is intercepted.

DKIM works through asymmetric public-key cryptography. The sender's email server signs outgoing messages with a private key. The receiving mail server retrieves the public key published in the sender's DNS records to verify that the message genuinely originated from the declared domain and that no content was tampered with in transit.

Domain owners publish SPF records in their DNS TXT records listing the IP addresses and mail exchangers authorized to dispatch emails under their domain name. When receiving servers inspect incoming mail, they check whether the sender's IP address matches the domain's SPF record. If it doesn't, the email is flagged as suspicious or rejected.

DMARC ties together SPF and DKIM authentication results and defines explicit handling policies (`p=none`, `p=quarantine`, or `p=reject`). It also enables receiving servers to send XML aggregate reports back to domain owners, giving complete visibility into unauthorized spoofing attempts against their corporate brand.

Without MX records, internet mail servers have no way of knowing where to deliver emails sent to `@yourdomain.com`. MX records include priority numbers (lower numbers have higher priority) to establish failover mail servers and redundancy.

Standard email clients like Apple Mail, Outlook, and Thunderbird do not natively understand custom client-side encryption algorithms. An IMAP Bridge runs locally on the user's computer, decrypts emails using the local key, and serves them locally over loopback (`127.0.0.1`) so standard clients can display them without exposing keys to the cloud.

Marketing platforms and surveillance tech companies embed invisible image URLs in marketing and personal emails. When your email client renders the image, it makes a request to the sender's server, leaking your IP address, physical location, operating system, and exact read timestamp. This data is fed into behavioral advertising networks.

Custom domain email builds brand authority, guarantees portability, and ensures that an organization owns its communications independently of any single tech provider. If you ever switch providers, your email address remains unchanged.

Aliases allow users to generate unique handles (e.g., `newsletter@domain.com` or `user+banking@domain.com`). If an alias receives spam or is exposed in a data breach, the user can disable or filter that specific handle without changing their primary email address.

Traditional PGP requires both sender and receiver to exchange public keys. Password-Protected Delivery solves this friction: the sender sets a one-time passphrase, and the external recipient receives a secure link that decrypts the payload client-side in their browser without requiring any software installation.

Under laws like the US CLOUD Act, traditional providers (Google, Microsoft) can be compelled to decrypt user data. A subpoena-proof architecture removes the provider's ability to comply because the provider does not hold the keys. The only data available to authorities is scrambled ciphertext.

Passed in 2018, the CLOUD Act bypasses mutual legal assistance treaties (MLAT). If you use a provider that holds your encryption keys (like Google Workspace or Microsoft 365), that provider can be legally ordered to decrypt and turn over your corporate emails without notifying you.

TLS protects emails from eavesdropping and man-in-the-middle attacks while traveling between your browser and the server, or between two mail servers (SMTP STARTTLS). However, once the message arrives on the destination server, it is decrypted into plaintext unless an application-layer E2EE system is used.

Originally designed in 1982 with zero security, modern SMTP relies on extensions like STARTTLS, SPF, DKIM, and DMARC to secure message dispatch and combat spam.

Unlike POP3 (which downloads and removes emails from the server), IMAP maintains state across laptops, phones, and webmail clients, synchronizing folders, unread flags, and drafts.

If an adversary records encrypted network traffic over years and eventually steals a long-term private key, Forward Secrecy prevents them from decrypting the historical recordings because each communication session used an ephemeral, independently generated key.

Created in 1991, PGP uses asymmetric public-key cryptography. While mathematically sound, PGP has struggled with mainstream adoption due to complex public key exchanges, lack of native mobile support, and metadata leakage (subject lines are left in plaintext).