Stored mail sits on provider servers, and on most mainstream services the provider can read it, because the provider holds the keys that encrypt that stored mail. The main facts are short: transport encryption covers mail in transit only, storage encryption with provider-held keys leaves the provider able to decrypt, and zero-access encryption is the one design where the provider cannot decrypt because it never holds the private key.
Transport encryption
A message is protected in transit by transport encryption while it moves between mail servers. Transport Layer Security, or TLS, is the standard mechanism: the sending server and the receiving server agree a TLS session, and the message travels inside that session, hidden from anyone watching the network path between the two servers.
That protection covers one hop only, not the journey as a whole. A message moves from the sender device to the sender provider, then to the recipient provider, then to the recipient device, with each leg a separate connection. RFC 3207, the standard that defines the STARTTLS extension for SMTP, states that SMTP is not an end-to-end mechanism and that TLS privacy between one pair of servers does not make the whole SMTP chain private. The standard also states that a publicly referenced SMTP server must not demand STARTTLS before delivering mail locally.
Both ends of a connection must support TLS for it to apply. Where the receiving server lacks TLS support, the message may travel with no transport encryption, as described in the IETF standard for STARTTLS. A background explainer on email encryption methods makes the same distinction and notes that TLS alone leaves stored mail readable by the provider.
Storage encryption
Once a message reaches a server, storage encryption is what protects it. Encryption at rest is the usual form: the provider encrypts stored data using keys it generates and manages. Stored mail is protected against a stolen drive and against some infrastructure attacks by encryption at rest, because disk data is not plain text. It gives no protection against the provider itself, because the provider keeps the keys and decrypts mail whenever search, indexing, filtering or display requires it.
Content features depend on readable mail. Spam filtering, search, smart replies and inbox categories all need the provider system to work with mail in readable form. A provider with the keys can run those features. A provider without the keys cannot run server-side content features in the same way, because readable mail never reaches its server.
Provider-managed encryption: the provider keeps the keys and can read stored mail. Zero-access encryption: only encrypted data is stored by the provider, which lacks the private key and cannot read stored mail. Client-side encryption, a paid enterprise feature on some services, places the key with the organisation rather than the provider.
Gmail
Google operates Gmail as a mailbox provider. Standard Gmail pairs TLS in transit with encryption at rest, using keys generated and managed by Google, and that pairing leaves Google with technical access to stored mail. Proton makes this point in its analysis of Gmail security and privacy, which treats TLS, encryption at rest, hosted S/MIME and client-side encryption as separate tiers and records that only client-side encryption keeps a message unreadable by Google.
The collection side is set out in Google policy. The Google Privacy Policy states that content created, uploaded or received through its services, including email written and received, is collected by Google, and that content is analysed to detect abuse such as spam, malware and illegal content. Personalised ads based on content from Drive, Gmail or Google Photos are excluded by the same policy, unless the user chooses to make data from those services available to other Google services that support personalised ads.
Inside the Google system, Gmail client-side encryption is the exception, and it is not a consumer default. Supported editions listed in Google Workspace documentation on external access to client-side encrypted content are Frontline Plus, Enterprise Plus, Education Standard and Education Plus. S/MIME is the format used by Gmail client-side encryption, according to a separate Google Workspace page on migration to client-side encrypted mail. Consumer Gmail accounts do not get that setup by default, so the standard consumer position is unchanged: TLS in transit, Google-managed keys at rest, and technical access for Google.
Gmail confidential mode leaves that position unchanged: an expiry date is set, access can be revoked, a passcode is required in some cases, and forwarding, copying, printing and downloading by the recipient are limited. The message still passes through Google systems in readable form, so it is not kept private from Google.
Outlook and Microsoft 365
Microsoft operates Outlook as its consumer mailbox service, and Microsoft 365 as the business and enterprise service that includes Exchange Online mailboxes. Service-side technologies encrypt customer data at rest and in transit for Microsoft 365, with volume-level and file-level encryption for data at rest and TLS and IPsec for data in transit, as set out in the Microsoft 365 data residency documentation, which also notes customer-managed encryption features.
Customer-managed keys add a separate layer rather than changing the default. The Microsoft Purview Customer Key overview states that Microsoft 365 data is always encrypted at rest using BitLocker and Distributed Key Manager, and that Customer Key adds a layer of encryption with keys provided and managed by the customer organisation. Service encryption is not designed to block Microsoft personnel from accessing data, according to the same page, and Customer Key helps an organisation meet compliance or regulatory requirements. Value-added services such as eDiscovery, anti-malware, anti-spam and search indexing are also authorised by a customer organisation that authorises Microsoft 365 to use its keys, and all of those services require readable content.
The advertising position is separate. The Microsoft privacy FAQs state that Microsoft does not use what a user says in email, chat, video calls or voicemail, or documents, photos or other personal files to target ads. Contents of mail, email or text messages appear as a category of personal data in the Microsoft US state data privacy laws notice, with purposes including providing products, improving the product experience, safety, and help, secure and troubleshoot. Connected experiences that can download or analyse content are noted in Microsoft support documentation on Outlook privacy settings, which also notes that those experiences can be disabled for some account types.
The Outlook default is encryption in transit and at rest under provider-managed keys, while stronger key control sits behind an enterprise feature with its own limits. No consumer Outlook default gives the mailbox the zero-access property.
Proton Mail
Proton operates Proton Mail as an encrypted email hosting service. Proton documentation states that every message and attachment in a Proton Mail inbox is secured with zero-access encryption, and that body content and attachments are stored with end-to-end encryption, including messages sent from non-Proton Mail addresses, as stated in the Proton Mail encryption explainer. Messages between Proton Mail addresses are always end-to-end encrypted in transit, according to the same page, while messages to other providers travel with TLS and are not end-to-end encrypted by default at the recipient, and inbound messages from other providers travel with TLS before being stored with zero-access encryption.
Public key cryptography is the mechanism behind zero-access encryption. Proton explains in its zero-access encryption explainer that data is encrypted with the user public key and decrypted only with the private key, which the user alone controls, so the service provider cannot read stored data because the server lacks the private key. Decryption happens locally on the user device when mail is accessed. The same page separates zero-access encryption from end-to-end encryption: zero-access encryption protects data after it reaches the service, even though the service may briefly access the data before encryption, whereas end-to-end encryption protects data before it reaches the service, because encryption happens on the sender device.
Stated limits apply inside that design. Proton documentation states that subject lines in Proton Mail messages are not end-to-end encrypted, because the subject line forms part of the OpenPGP header packet, which is not end-to-end encrypted under that standard. A second limit comes from the transit rule: a message from Proton Mail to a mainstream provider travels under TLS in transit, but the recipient provider can read its stored copy under its own rules, so zero-access storage protects the Proton Mail copy only.
Tuta Mail
Tuta, formerly Tutanota, operates Tuta Mail as an encrypted email service based in Germany. Tuta documentation states that the whole mailbox, including emails, calendar and address book, is stored end-to-end encrypted in Tuta, and that the private key is encrypted with the user password before transmission to Tuta servers, as set out in the Tuta encryption explainer. Mail addresses of users and senders and recipients are the only unencrypted data, according to the same page, because mail servers need delivery addresses to route mail, and decryption takes place locally on the user device after authentication.
Scope is where Tuta differs from Proton Mail: subject lines are encrypted along with message content, because Tuta does not use PGP, which leaves subject lines outside end-to-end encryption. Mail sent to external recipients can also be protected with a password under Tuta, so the external recipient decrypts it with a shared password instead of receiving plain mail. The central claim is repeated on the Tuta secure email page: Tuta does not scan or track emails, and not even Tuta can decrypt and read stored emails. Those claims are provider statements, reported here as such, as with Proton.
Yahoo Mail
Yahoo operates Yahoo Mail as a mailbox service. Yahoo policy material, quoted in a comparison of Gmail and Yahoo Mail, states that Yahoo may analyse content and other information, including email content, posts, photos and attachments, and that analysis to create advertising interest profiles relies on emails from retailers and other organisations, not on personal emails between individuals, subject to opt-out controls. That summary appears in the Gmail versus Yahoo Mail comparison, which quotes the Yahoo policy wording and contrasts it with Google statements that Gmail messages are not scanned or read to show ads. The Yahoo position is reported here as attributed and secondary, because the Yahoo policy page itself was not opened in this research pass. Yahoo Mail is a mainstream provider with provider-managed storage, not a zero-access service.
Metadata and subject lines
Metadata means data about a message rather than the message body: sender and recipient addresses, dates, and routing information. Routing addresses stay visible even with zero-access providers, because a mail server cannot deliver a message without knowing where it goes. Subject lines form a middle category: Tuta encrypts subject lines, while Proton does not under OpenPGP. A reader that treats a subject line as private content needs to check the provider position on subject lines separately.
The same split governs internal access and legal requests. Readable mail can be produced by a provider that holds the keys in response to a lawful request. Readable mail cannot be produced from stored encrypted data by a provider that lacks the keys, because decryption needs a key the provider does not hold. That difference explains why zero-access providers describe their systems as unable to hand over content rather than unwilling to hand over content.
Email aliases and provider access
AliasFleet is an email alias and forwarding service. An alias is a separate address that forwards mail to a destination inbox run by a provider chosen by the alias owner, and the mail then sits in that inbox under the destination provider rules. The address exposed to a sender, a broker or a breached database changes with an alias, because each service gets a different alias and a leaked alias can be disabled without changing the destination inbox. The destination provider access position does not change with an alias, because the destination provider still stores the forwarded mail and holds the keys for that storage under its own rules. Aliases as separate addresses per website, with a kill switch for a leaked alias and reply handling that keeps the destination address out of the recipient view, are described on the AliasFleet homepage. Those features concern address exposure and forwarding control, not provider storage encryption. A destination inbox with zero-access storage is the part of the setup that addresses provider access, and that choice sits with the destination provider, not with the alias service.
Account protection measures
The storage comparison covers storage models, not account protection. Whether an unauthorised person can open a mailbox still depends on a strong password, two-factor authentication and careful handling of account recovery, whatever the provider storage model. Encryption at rest still matters against infrastructure attacks, and TLS still matters against network observers, even though neither property stops the provider itself from reading stored mail. Mainstream providers can read stored mail by design, zero-access providers cannot read stored mail by design, and the destination inbox choice decides which of those two positions applies to a given mailbox.
Top comments (0)