E-mail Security and Privacy
“Secure email” can mean four different things in the same meeting. One person means the From domain is authenticated. Another means SMTP used TLS. A third expects the message body to be encrypted. The security team may be worried about a stolen mailbox rather than the message path. Those are different problems, and each needs its own evidence.
Start by naming what is at risk
| Risk | Useful control | What to verify |
|---|---|---|
| Unauthorized use of a sending domain | SPF, DKIM, DMARC, controlled sender inventory | Received header, aligned identity, DNS, DMARC reports |
| Message changed after signing | DKIM, S/MIME signature, OpenPGP signature | Signature result, signed fields, signing identity |
| SMTP interception or downgrade | TLS, MTA-STS, DANE, TLS reporting, REQUIRETLS where supported | Negotiation log, peer name, certificate, policy result |
| Intermediary reads message content | S/MIME or OpenPGP content encryption | Recipient key, decryption result, key ownership |
| Mailbox takeover | Phishing-resistant MFA, least privilege, session and token control | Login, token, forwarding rule, delegate, and device events |
| Unnecessary data exposure | Data minimization, retention, DLP, archive and export controls | Access logs, retention state, DLP event, deletion result |
Authentication stops one kind of forgery
SPF authorizes systems to use an SMTP domain. DKIM signs selected message fields and the body for a signing domain. DMARC checks whether a passing SPF or DKIM domain aligns with the domain visible in From and lets the domain owner publish a handling preference for failures.
A DMARC pass says the visible domain was used through an aligned authenticated path. It does not verify the human sender, display name, address local part, links, attachment, or business request. Lookalike domains and compromised legitimate mailboxes can pass their own authentication.
Read results from a trusted receiver-added Authentication-Results field. A sender can insert a fake copy before delivery. Keep the authentication service identifier, source IP, envelope sender, DKIM domain and selector, visible From domain, and final verdict.
BIMI comes after authentication
BIMI gives supporting providers a way to consider a domain-published brand indicator after authentication and local policy checks. A logo is a display signal, not proof that the content is safe. No logo is not proof of fraud. Protect the DMARC, DNS, logo, certificate, and selector workflow behind it.
TLS protects a hop, not the whole message
STARTTLS can encrypt the connection between two mail servers. Without authenticated policy, opportunistic SMTP may still fall back when TLS is unavailable. MTA-STS lets a domain require certificate-validated TLS to approved MX hosts, and TLS reporting surfaces negotiation and policy failures. DANE SMTP uses DNSSEC-validated TLSA records. REQUIRETLS can request protected transport for a message when the path supports it.
These controls protect transport. Mail systems on the route can normally read the message. Log the negotiated protocol, peer, certificate result, policy decision, and fallback instead of recording only “TLS used.”
Use content encryption when the mail systems must not read it
S/MIME and OpenPGP-capable clients can sign and encrypt MIME content for selected recipients. GNU Privacy Guard, or GPG, is an OpenPGP implementation rather than a separate email protocol. RFC 9787 gives current guidance for end-to-end email security.
The difficult part is rarely the Encrypt button. It is certificate or key discovery, identity validation, private-key protection, renewal, revocation, recovery, mobile support, offboarding, and access to older mail. Encryption can also limit server-side search, malware inspection, DLP, journaling, delegated access, and eDiscovery. Routing metadata and message size can remain visible.
The mailbox is often the richer target
A mailbox contains history, contacts, password resets, invoices, and active conversations. A compromised account can also send fully authenticated mail. Protect it as an application platform, not only as storage.
- Require phishing-resistant MFA where supported and control recovery paths just as tightly.
- Disable legacy authentication and review any remaining application-password exception.
- Inventory OAuth grants, sessions, devices, delegates, shared mailboxes, SMTP credentials, and API keys.
- Alert on forwarding rules, transport rules, new delegates, recovery changes, and unfamiliar administrative actions.
- Separate application senders from human accounts and use the least privilege each path needs.
- Keep audit logs outside the same administrative path used to operate the mailbox service.
Filtering is a stack of imperfect decisions
Phishing and spam controls combine connection behavior, reputation, authentication, domain age, display-name patterns, message structure, language, URLs, attachments, recipient context, and user reports. One signal should not make every decision.
Inspect the real file type rather than only the extension or declared MIME type. Follow redirect chains. Account for delayed payloads and encrypted archives. Keep a quarantine and release path for uncertain business mail, then measure false positives by rule and source. Silent deletion makes both incident review and filter tuning harder.
Privacy failures are often ordinary mistakes
Wrong recipients, broad shared-mailbox access, old exports, remote images, tracked links, unlimited retention, and third-party applications can expose data without an attacker breaking SMTP. Minimize sensitive content in email and use a controlled portal when forwarding, previews, backups, or recipient error would create unacceptable exposure.
Document mailbox owners, archive scope, deletion rules, legal holds, privileged access, exports, and exceptions. Remote content and link tracking should collect no more than the stated purpose requires. Privacy and employee-monitoring rules vary by jurisdiction, so policy decisions need appropriate legal review.
Certified delivery solves a narrower problem
Jurisdiction-specific certified email can provide evidence of submission, delivery, registered identity, or timestamps within its legal framework. It does not automatically provide end-to-end confidentiality, safe content, uncompromised endpoints, or universal legal effect. Review the service rules and evidence separately.
A rollout order that avoids self-inflicted outages
- Inventory sending domains, platforms, MTAs, gateways, mailbox providers, archives, and third-party applications.
- Protect administrative and sending accounts before increasing domain-policy enforcement.
- Align SPF and DKIM for each real production source, then use DMARC reports to find what is missing.
- Move DMARC policy in controlled stages with rollback and owner approval.
- Measure SMTP TLS behavior before enforcing MTA-STS or DANE.
- Choose end-to-end encryption only after key ownership, recovery, revocation, client support, and inspection needs are defined.
- Tune inbound filtering with quarantine ownership and false-positive review.
- Set retention, archive, DLP, export, and privacy controls with named owners.
Keep this evidence during an incident
Preserve the raw message and attachments, SMTP envelope and responses, queue or delivery events, trusted authentication results, DNS answers, policy versions, login and token events, forwarding rules, link destinations, attachment hashes, affected recipients, and every containment action. Record timestamps and time zones. If the message is evidence, hash the collected copy and document any decoding or extraction.
Do not treat these as proof
- A DMARC pass is not proof that the request or sender is honest.
- STARTTLS is not end-to-end encryption.
- A BIMI logo is not a guarantee of safe content.
- A clean attachment scan is not a permanent verdict.
- An encrypted message is not safe if the endpoint or recipient is wrong.
- A retention policy is not working until deletion and legal-hold behavior have been tested.
Email security gets easier to reason about when each claim is tied to one layer and one piece of evidence. Ask which identity, connection, message, mailbox, device, archive, or data flow is at risk, then test the control that actually owns it.
