If your mail sits in a mainstream inbox, the honest answer is yes. Your provider's servers hold your messages in a form the provider can read. That is not a scandal and it is not hidden. It is how the system was built. Mail arrives as text, it is indexed so you can search it, it is filtered so the worst of it never reaches you, and all of that requires the message to be legible to the machine doing the work.
The question worth asking is narrower than the one people usually ask. There are three separate things here: what a provider is technically capable of doing, what it promises in writing, and what it actually does day to day. Most of the bad advice on this subject comes from collapsing those three into one. A provider can be entirely honest and entirely well behaved and still hold the key to your mailbox.
What follows is what the large providers say on their own documentation pages, read against those pages rather than against summaries of them, plus a plain account of where a forwarding service sits in the same picture.
Three things all called encryption
Marketing pages use one word for three different mechanisms, and they protect you from three different things. Once you can tell them apart, most claims about email privacy sort themselves out in about ten seconds.
Encryption in transit is TLS between two servers. Gmail's help page says all Gmail messages use TLS automatically, and the same page shows the limit of that: a red open padlock means the message was not encrypted, because TLS only applies when the provider at the other end supports it. It protects the wire, one hop at a time, and RFC 3207, the specification that defined STARTTLS for SMTP, is blunt about the limit: "It should be noted that SMTP is not an end-to-end mechanism." The same document describes the downgrade problem, where an attacker deletes the server's STARTTLS response so the client never tries to negotiate a session at all. Transit encryption is genuinely worth having. It is not a promise about what happens once the message lands.
Encryption at rest protects the disk. Microsoft's cloud encryption overview says Microsoft 365 uses BitLocker along with other service-side technologies for customer data at rest, and Apple states that iCloud data is "encrypted in transit and stored in an encrypted format at rest." The part that matters is key custody. Apple's own page explains that encryption keys from your trusted devices "are secured in Apple data centers, so Apple can decrypt your data on your behalf." At-rest encryption defends against a stolen drive or a mislaid backup. It does not defend against the provider itself.
End-to-end encryption is the only one of the three that removes the provider from the picture, because the keys never leave the endpoints. Almost no mainstream mail is end-to-end by default, for the ordinary reason that mail has to interoperate with every other mail system in the world. Where it does exist, it is usually optional, usually limited to correspondents on the same platform, and usually narrower in scope than the phrase suggests.
| Kind of encryption | What it protects | Who holds the key | What it does not stop |
|---|---|---|---|
| In transit (TLS) | One server-to-server hop | The two servers, per session | Anyone with access at either end |
| At rest | Disks, storage, backups | Usually the provider | The provider reading your mailbox |
| End-to-end | The message body itself | You and your correspondent | Subject lines, addresses, timing |
What the providers say on their own pages
Gmail's consumer documentation describes TLS as the default and offers stronger options above it. For Workspace customers using client-side encryption, Google writes that "your organization holds the only copy of the key" and that not even Google can open it. That is a real distinction, and it is worth noticing that it is scoped to an enabled organisational feature rather than to ordinary consumer Gmail.
Microsoft is unusually clear in its Outlook.com help page, which states that Outlook.com uses opportunistic TLS to encrypt the connection with a recipient's provider, that the message "might not stay encrypted after the message reaches the recipient's email provider," and then puts the whole point in one sentence: "TLS encrypts the connection, not the message." That sentence is a better summary of email security than most articles about it.
Apple says the quiet part on its iCloud data security page, and deserves credit for it:
iCloud Mail does not use end-to-end encryption because of the need to interoperate with the global email system.
Proton is the counterexample, and reading its own documentation carefully is instructive. Proton describes messages between Proton addresses as end-to-end encrypted and stored inboxes as protected with zero-access encryption. It also states plainly that subject lines and sender and recipient addresses "are encrypted, but not end-to-end encrypted." Even in the strongest mainstream case, the envelope leaks. Who wrote to whom, and about what, in the subject line, is a great deal of information.
A filter is not a person
Automated processing is universal and it is not the same thing as a human opening your mail. Google's privacy policy states that it analyses content "to help us detect abuse such as spam, malware, and illegal content." Every provider of any size does some version of this, because a mail service that did not would be unusable within a week. Machine inspection for spam and malware is the price of the inbox working at all.
Advertising is where stale claims cluster, so it is worth checking rather than repeating. Google's current safety page says "we don't use data from Drive, Gmail, and Photos for ads," and Microsoft's privacy statement says Microsoft "does not use what you say in emails, human-to-human chat, video calls or voice mail, or your personal files, photos, or documents to target ads to you." Both statements are recent, both are on the companies' own pages, and both contradict a widely repeated claim that Google itself retired in June 2017, when it announced that consumer Gmail content would no longer be used or scanned for ads personalisation. Correcting it does not make either company a charity. It makes the rest of the criticism more credible.
Between the filter and the human sits a middle category. Gmail's smart features setting uses your Gmail, Chat and Meet content to personalise those products, and it is a setting you can turn off. Microsoft's privacy statement acknowledges that it uses "both automated and manual (human) methods" when processing personal data, with manual review used to check automated results. That is a narrow and specific admission, not a claim that staff browse your inbox, and it is the sort of sentence worth reading in the original rather than in a headline.
When someone outside asks
If a provider can read your mail, so can anyone who can lawfully compel the provider. This is the least mysterious part of the whole subject and the part most often described with invented numbers, so take the mechanism and leave the figures alone. Google's information requests page states that authorities must "get a search warrant to compel disclosure of the content of communications, such as email messages, documents, and photos." Microsoft's law enforcement requests report says that "a warrant or its local equivalent is required for content data." Both companies publish periodic transparency reports; so do most providers of comparable size.
Notification varies and is often the more important detail. Google says that when it receives a government request it emails the user account before disclosing information, with exceptions where an order forbids notice or where there is an emergency. We are not lawyers and none of this is legal advice, but the structural point survives any jurisdiction: retention is what determines how much there is to hand over. A provider cannot produce what it never kept.
Where a forwarder sits, ours included
An alias or forwarding service accepts a message and relays it to your real inbox. To do that it must process the message, which means it can technically see the body while the message is in flight. There is no clever architecture that avoids this and still forwards mail to an ordinary address. Any forwarder that implies otherwise is describing something it is not doing. If you want the mechanics of the addressing side, email masking explained covers how the rewriting works.
YeyMail is in exactly that position, so here is our stance without spin. We process the message in order to forward it, and we do not store it: the body is discarded on delivery, so there is no archive of message content to search, breach, or hand over. Delivery metadata is kept for 30 days and activity events for 90 days. That is a claim about retention and about what we choose to do, not a claim that we are technically incapable of reading a message as it passes through. The security and privacy pages state the same thing in more detail.
If you supply a public key, we can re-wrap the forwarded body in PGP/MIME, which means the body arrives encrypted to you. Subject lines and addresses stay readable, for the same reason they stay readable at Proton. This is worth having and it is not end-to-end encryption, and we will not call it that.
What actually reduces exposure
Nothing on this list is exotic. All of it is more effective than choosing a provider on the strength of a marketing page.
- Keep fewer copies. Every archived mailbox, every export, every backup on a laptop is another place the message exists and another party who can be compelled.
- Prefer shorter retention where you can choose it, and check what the default actually is rather than what you assume it is.
- Use PGP for the small number of things that genuinely need it, and accept that the subject line and the addresses are still visible.
- Do not send secrets by email at all. Passwords, recovery codes, scans of documents and account numbers all belong somewhere else, because email was never designed to carry them.
- Separate identities so that one leak does not map your whole life. Who has your email address walks through how far a single address usually spreads, and how to request data deletion covers shrinking the copies that already exist.
The useful mental model is not a locked box. It is a chain of custody. Your provider holds the mail, your correspondent's provider holds a copy, and both are subject to law and to their own retention policies. Reading a provider's own documentation, rather than an article about it, tells you which links you have any say over. Most people find they have more say than they expected, and less encryption than they were sold.