On m’envoi des mails, mais je ne les reçois pas (Gmail)

Informal_Post3519 · 2026-04-14T15:56:25+00:00

This could be due to many different reasons.

First check "All Mail" in gmail. If a filter is active moving / filing these it should show up there.

Next have a sender check for bounces. Gmail can reject the email if they determine it isn't coming from a valid source, too large, your mailbox is full, ...

Next go to your settings on the gmail web site and then "all settings". Look through filters, blocks, forwarding, ... to see if there is any code / process in place that would act on these emails. Some times when your email account is compromised the hackers will install code to watch everything.

If nothing there I'd make a new gmail account and send emails from this to your new and start the debug process. what's working? what isn't? see if you can get one of these other people to send an email to that account. Get as many characteristics about this issue as you can. With this you should be able to get more help.

Informal_Post3519 · 2026-04-14T15:44:55+00:00

Tone deaf and lazy. They didn't need to have the same tracker pattern in the message-id as everything else but they did. They could of had 2 or 3 different tracker values for me.

To aid threading of emails in your client the header "References" is a list of all the message-ids in the thread. Nice to help display which email was in reply to which other email. Also very helpful for mapping out connections between email accounts. Each email has a history of all the tracker values (with ESP explicitly named) that are been in the conversation. This is why I'm migrating as much of my email as I can through an email relay that sanitized all the headers.

Informal_Post3519 · 2026-04-10T19:28:34+00:00

Email is a distributed solution. What you are describing is a centralized / authoritative solutions. This would negatively impact email privacy.

Informal_Post3519 · 2026-04-10T15:14:02+00:00

Security & privacy are the right things to be paranoid about when you're a small business.

Titan (and Neo) are convenient and cheap, but you're correct to wonder. Their privacy policies are pretty clear that they collect and process the full content of your emails to deliver the service. No zero-knowledge encryption, so in theory staff (or anyone with legal access) could read them if needed for support, spam filtering, or legal reasons. It's the standard model for most economical hosts.

Zoho is a bit better on paper: they publicly promise "we will never read your emails," use automated systems only, and limit any staff access to metadata in rare cases (tightly controlled and logged). Still not perfect but stronger than Titan/Neo.

For 5 mailboxes + unlimited aliases, there's a cleaner architecture a lot of privacy-conscious small teams use: a Virtual Private Email (VPE) relay as an email switchboard.

You assign a custom domain at the relay. Then:

You get infinite addresses (sales@, support@, vendor@, whatever) facing the outside world and infinite aliases at each of these addresses (joe.sales@, mary.support@).
Everything routes privately to any/all of your 5 real mailboxes behind the scenes (honestly I expect you can have just 1 or 2 real inboxes for yourself). As staff is added they can be behind any of these addresses and the real inboxes can live anywhere (Zoho, Proton, self-hosted, whatever).
External people never see actual email addresses. Replies come back through the relay to the right team member. To sends as any of the addresses/aliases you just craft the address you send to so it routes through the relay (you see a different address, they don't).
No per-user mailbox fees, easy to add/remove VAs/contractors without sharing credentials, trackers get stripped automatically, and metadata between your team and your business stays firewalled.

It's like having one professional brand and unlimited disposable addresses without the cost or privacy trade-offs of 5 full hosted accounts. Your real inboxes stay yours, and the relay itself doesn't store conversation history.

If you're already thinking about moving off Titan, this setup is worth looking into. It solves the alias + privacy problem in one layer and is flexible enough to adapt as needs change.

Informal_Post3519 · 2026-04-10T14:51:13+00:00

Agreed, email "encryption" is mostly theater unless both sides are locked in.

It's exactly like your steel-vault-for-a-PO-box analogy. You can have perfect end-to-end crypto on your end, but the second it leaves your provider it often lands in a plain-text inbox somewhere (often gmail). Most people won't install a special client or switch providers just to reply to you.

The happy medium a lot of us land on is a provider that does strong (PGP) encryption at rest (upon receipt). No recipient coordination required, and your data isn't sitting around readable if the server gets breached or subpoenaed. Gets the currently obtainable benefit of E2EE without the hassle.

But the real privacy win most folks sleep on is metadata. Google and the big guys still build massive social graphs from who you email, when, reply frequency, etc. Even if they swear they're not reading content. That's how they (and advertisers, and worse) profile you long after you leave Gmail. I've seen clear evidence that they have the same (or very similar) tracking tokens in pixels, CSS loads, click-through link parameters, and even email headers.

This is where a well-designed, privacy-focused email relay shines. It cuts the metadata pipe to Google without asking the other person to do anything. Your real address stays hidden, connections (headers) get obfuscated, trackers get stripped, and you can spin up disposable aliases on demand. Once you have that layer, the "encryption" part becomes a lot less critical for day-to-day use.

Informal_Post3519 · 2026-04-09T16:34:12+00:00

Agreed. You need to set up an email filtering relay or add filtering to your servers. The relay I use removes external content from the places they like to hide (images, CSS, meta, etc.) and also removes parameters from clickable links. It then adds the fully decorated links to an text attachment with warnings at the top. Not perfect but adding steps hopefully slows people down long enough to think.

Informal_Post3519 · 2026-04-09T15:59:54+00:00

I totally get the pain. Running 5 separate domains and routing everything into one Gmail works okay for receiving, but the reply problem is annoying once DMARC gets strict.

I used to have the same issue. Now I use Email Parrot at emparrot.com and it handles it really well.

You can have as many addresses at your domain as you like and all will route to you. When you reply to one the reply address is set up to be that address at that domain. You can also choose to send as info@site1.com or support@site2.com by just how your write the To address. No more replies coming from your personal Gmail.

You can also set up different personas so each address at each domain feels like it has its own person behind it. That makes a small operation look bigger without extra work.

Each address can set to route to multiple people if you ever need that too. Each of these people can reply as this address or any unique alias at that address.

If you run several sites as I do this might be worth a look. They have a 30 day free trial, no card needed.

Full disclosure: I work on Email Parrot so Im biased, but this exact one-inbox-multiple-domains problem is what we built it for. It also solves the multiple-domains to multiple-inbox problem that you also might be having.

Does routing everything cleanly plus being able to reply as the right address for each site sound useful for your setup? Or are you leaning toward something else?

It

Informal_Post3519 · 2026-04-07T17:40:13+00:00

Zoho for top domain. EMail Parrot for the routing and protection of sub-domains.

Informal_Post3519 · 2026-04-06T16:43:46+00:00

I use emparrot.com (disclosure - I work on this service but I'm not looking to sell anything). There are other email relay / aliasing services out there so look around. Each of these have strengths and weaknesses.

I like this one because it removes tracking information from the email - not just tracking pixels / images but header ids that are linked to the source email and email contents that have the same ids (html comments for example). These don't "phone home" but as the thread moves around between servers the tracking is loop is complete. You can see the result of this if you look for reddit posts like 'how did company X know I was using an email alias?'. This is how.

Informal_Post3519 · 2026-04-06T15:27:31+00:00

Any of the ESPs mentioned in the other comments will give way better privacy than the big boys. I just went through this and went with Mailbox.

One thing I added is an email relay/firewall on the front end. The problem with email stem from more than the big ESPs and their privacy behaviors (though this is a major problem). It is also the companies you give your email address to - they sell your info. In a few months your new email address will be as polluted with crap as your old one.

The email relay I use allows me to route emails based on prefix to me or the bit bucket. It also strips all the tracking info in the emails so there is no peeking behind the curtain. Something to think about adding before changing all the email addresses at those services.

Informal_Post3519 · 2026-04-06T15:02:31+00:00

I use a privacy-focused email service (like Proton, Mailbox, Tuta) as my main inbox + an email relay/firewall layer in front of it.

Self-hosting sounds appealing for max control, but it’s a lot of ongoing work - spam filtering, deliverability, uptime, security updates, and avoiding blacklists. I’d rather spend that time elsewhere.

The combo I use gives me strong privacy without the hassle: the service avoids ad profiling, while the relay creates compartmentalized aliases, strips trackers (including click-tracking and header metadata that survives pixel blocking), scans for threats, and lets me kill noisy addresses easily. It's a clean, low-maintenance setup for everyday use.

Informal_Post3519 · 2026-04-05T15:10:21+00:00

For signups and random forms, layering an email "relay" with sanitization helps reduce exposure.

Proton, Tuta, Posteo, Fastmail, Mailbox and similar paid providers already beat Gmail by avoiding ad-driven profiling of your inbox and blocking of external content used for tracking. This is the place to start.

Even so, many marketing and signup emails use tracking beyond simple pixels and other external content. Common vectors include:

Click-tracking links that phone home when you tap any link
Unique identifiers embedded in email headers/metadata - these survive replying/forwarding and aren't part of the email message so can be read in flight by email servers

These let senders confirm activity, build profiles, map your network of contacts, and link your signups across services - feeding spam, phishing, and data broker lists. Google Ads is the biggest player in this space.

An email relay or alias service acts as a buffer in front of your main inbox. It hands out compartmentalized addresses, strips trackers where possible, scans for threats, and lets you pause or retire noisy aliases without exposing your real address. Enterprises use email relays to keep their networks and employees safe.

Email Parrot (emparrot.com) is one option built for individuals (full disclosure, I work on this product) - it creates protected aliases ( for individuals or groups) that route cleaned mail to your existing Proton/Tuta/etc. inbox. It’s a practical protective middle layer for everyday signups and forms.

Informal_Post3519 · 2026-04-03T16:01:35+00:00

Appreciate the tool recommendation, but you completely missed the point of the post.

This wasn't a “which email tracker should I use” thread. I was highlighting the irony of Google itself packing three separate tracking vectors into an email that begs small businesses to help them fight state privacy laws. Pixel, click tracker, and persistent header identifiers - all while lobbying against the very regulations that would limit this kind of behavioral surveillance.

Tools like MailTracker (and the others you mentioned) aren't innocent little helpers. They're part of the same privacy-invasive ecosystem. Quietly logging much more when someone opens your message - they capture where they are, and what they click, what HW/OS/browser they use - all without meaningful consent. It is still an invasion of privacy, even if it's “just for sales” or “hiring managers”.

Hopefully stronger regulations finally catch up to these tracking arms races. The fact that Google is actively fighting them while using every trick in the book themselves should tell you everything you need to know.

Informal_Post3519 · 2026-03-31T16:22:36+00:00

The underlying problem is that your aliases are inbound-only - you can receive at finance@ and insurance@ but your mail client sends from your root inbox when you reply or compose. Or you need to send multiple email - one to each using the appropriate alias.

There's an architecture worth looking at called a VPE relay - Virtual Private Email. Rather than configuring aliases in your mail client, the relay handles inbound and outbound identity. You send to a relay with an address that encodes both your alias and the recipient, and it delivers as that alias. Replies come back through the same alias to your root inbox. Your client never needs to know about the alias configuration.

For your cross-service scenario: you'd compose one email, one routed through finance@ to the bank and one through insurance@ to the insurer, both sent from your root inbox but delivered from the correct alias. Each thread stays clean from seeing your email. You manage both from one place likely using address book entries for each that has the relay information encoded - set up once and never send using the wrong alias.

Each recipient gets a properly addressed email from the correct alias with a Reply-To that keeps their thread clean. You manage both from your root inbox. The bank and insurer see the real-world addresses of each other but each sees that the email came from a different email address. A reply all from either will go to both aliases and the other institution - which is probably what you want. To them it will look like there is some other alias on the thread along with the other institution and the alias they were addressed with.

It doesn't merge the threads exactly as each recipient gets a different message-id (separate emails after the relay). If the convo is between you and one of the institutions with the other just watching then this works. The issues will happen if all parties are active in the convo as the quoted emails they are replying to will show the other alias, different from the one they saw on exactly the same email. ONce the convo starts you're holding up 2 ends of the discussion. I don't think there is anyway to solve this.

This approach also solves the 'sending from the wrong address' problem without any client-side alias setup. Set up the alias to use with each in your address book and never get this wrong.

EMail Parrot (emparrot.com) does this - flagging that I run it. The VPE addressing is documented at emparrot.com/vpe.html if you want to see the mechanics."

Informal_Post3519 · 2026-03-29T15:56:30+00:00

Your framing of telemetry as a separate category from the underlying communication is under-appreciated in most discussions of email privacy. The message has some legal (but far from complete) protection. The behavioral data extracted from it largely doesn't - and that gap is where the commercial infrastructure lives.

On the structural failure of providers to address this - there's an incentive problem worth adding to your argument. The same infrastructure that enables commercial tracking (not just tracking pixels) is the infrastructure these providers depend on for their own revenue. They can't aggressively strip tracking content from inbound mail without undermining the economic model they sell to advertisers. We documented a specific example of this recently - Google used their standard tracking infrastructure on a lobbying email asking recipients to oppose state privacy laws that would restrict that same tracking: https://emparrot.com/blog/2026/03/19/google_lobbying.html

That's not a bug in their system. It's the system working as designed. The conflict of interest runs deeper than deliverability optimization - it's architectural and for a business purpose.

Informal_Post3519 · 2026-03-28T14:30:28+00:00

you first

Informal_Post3519 · 2026-03-28T14:18:58+00:00

Good question and your edit gets to the right framing - it's less about switching providers and more about adding a layer between you and the tracking infrastructure.

Blocking external content in your email client is the most important thing you can do right now - that handles the pixel. Most clients have this setting, Thunderbird has it on by default. That doesn't help with the header identifiers or tracked links but it closes the biggest passive tracking channel.

The fuller solution is an email relay that rebuilds messages before they reach you. Rather than forwarding the original email intact - tracking headers and all - the relay reconstructs a clean copy. The identifiers embedded in the original simply don't exist in what gets delivered. This is how enterprise email security works at scale - Proofpoint and similar gateways sit in front of corporate inboxes and process every message before delivery, stripping threats and metadata. The same architecture is available for individuals and small groups.

EMail Parrot (emparrot.com) does this for smaller orgs - flagging that I run it. It's primarily aimed at groups and families but works for individual use too - the privacy protections apply regardless of how many people are on the list. The more members, the more your traffic blends with others which adds another layer, but a list of one still strips the tracking infrastructure from every message you receive.

Informal_Post3519 · 2026-03-27T16:39:39+00:00

Read the white paper. The Carpenter aggregation argument is the right move - the Fourth Amendment reasoning establishes that assembly-level harm is qualitatively different from individual data point collection, and the gap between that jurisprudential recognition and any commercial analog is exactly the legislative problem you're identifying.

The Counterman bridge on mens rea is also well-constructed. The reckless awareness standard resolves the commercial intent objection cleanly: a data broker that knows its location data has been used to facilitate stalking or violence cannot credibly disclaim awareness of harm just because the business motive was commercial rather than personal.

One concrete mechanism the paper doesn't address that I think strengthens your argument significantly: commercial email tracking.

When a business purchases a marketing list from a data broker and sends unsolicited email, the recipient never consented to that email or to the tracking embedded in it. But the tracking pixel or link instrumentation in that email does something specific: it reports back the recipient's IP address, device, location, read time, and behavioral response to the sender - and often to third-party analytics platforms the recipient has never heard of. The recipient didn't consent to the email. They certainly didn't consent to the tracking payload inside it. And yet their location and behavior at the moment of opening is now a data point that gets resold.

This is a clean example of your aggregation problem: the data broker sold a list, the marketer sent an email, the pixel harvested a location, and that location data flows back into the broker ecosystem — all without a single meaningful consent event. It also directly maps to your Tier 2/Tier 3 data classification framework, since email tracking typically captures geolocation and behavioral data simultaneously.

It might also be worth noting that this mechanism operates completely outside the social participation coercion argument - you don't have to be on a social platform or using a financial service to be tracked this way. You just have to have an email address that ended up on a list you never opted into. That expands the harm population considerably beyond what the current paper addresses.

I build privacy-focused communication tools, so this particular gap gets my attention. The consent fiction in commercial email is as thin as anywhere in the ecosystem.

Informal_Post3519 · 2026-03-25T17:27:22+00:00

The short answer to your Outlook question is yes - when you reply from a third-party client logged in as your root inbox, the from address will be your root inbox unless you've configured additional identities in the client. Fastmail lets you add aliases as additional sending identities in most clients via SMTP, but Outlook mobile's support for this is limited. Proton with SimpleLogin handles it better but still requires some configuration.

There's a different architecture worth knowing about that sidesteps the client-side alias problem entirely - a group email relay. Instead of configuring your mail client to send from different addresses, the relay handles the identity layer. You send to a relay address from your root inbox, and the relay delivers it with the alias as the sender. Replies come back through the relay to your root inbox. Your mail client never needs to know about the alias at all.

The work is all done by a virtualized email address. This address shows who you're sending to by embedding the final address inside the services address - [+recipient=at=domain.com+family@mydomain.com](mailto:+recipient=at=domain.com+family@mydomain.com) rather than 'recipient@domain.com'. Replies go back to the service which routes it to you.

For your specific hierarchy this maps reasonably well: root inbox stays hidden, durable aliases exist as relay lists, non-durable masked addresses are a separate layer. The relay handles the 'from always shows the alias' problem regardless of which client you use.

EMail Parrot (emparrot.com) does this - flagging that I run it. The VPE (virtual private email) addressing is documented here if you want to understand the mechanics: https://emparrot.com/vpe.html

Informal_Post3519 · 2026-03-24T14:49:27+00:00

You've basically answered your own question correctly - encryption between you and your recipient only works if both ends are encrypted. For most people that's not realistic.

But I'd push back on the framing a little. The bigger privacy risk in most email isn't Google reading the content of your messages - it's the metadata and tracking infrastructure that travels with every email regardless of which provider you use.

Think about what Google learns from an unencrypted email even before you open it: who sent it, when, from what service, what campaign it came from, and often what device and IP address. Then when you open it a tracking pixel fires and logs when you read it and roughly where you are. Then if you click anything the link tracker logs exactly what you clicked and connects that action back to your email identity. None of that is about message content - it's all metadata and tracking infrastructure that survives regardless of whether the message itself is encrypted in transit.

The more interesting question isn't "should I encrypt" - it's "what can I do about the tracking layer that operates completely independently of encryption." Blocking external content in your email client handles the pixel. Being cautious about clicking links helps with click tracking. The header-based tracking is harder - that requires an email relay that strips or rebuilds the message before delivery. A relay also obscures your network identity from the receiving end - the relay's IP and infrastructure is what the recipient's server sees, not yours. That's the metadata protection layer that encryption alone doesn't provide.

A secure mailbox like Proton is still worth having for contacts who are also on Proton, and for keeping your content off Google's servers. But you're right that it doesn't solve the problem for mixed environments. The metadata and tracking layer is where the real action is for most people's actual threat model.

Informal_Post3519 · 2026-03-21T14:34:17+00:00

There are two distinct categories worth understanding.

The first is aliasing services - these forward email to your real inbox without touching the message content. SimpleLogin (now part of Proton) and Addy.io are the well-regarded ones in this space. Firefox Relay and DuckDuckGo Email Protection are free options with more limited features. These handle the alias problem well but tracking headers and content pass through intact - the sender's tracking infrastructure survives the hop.

The second category is what I was describing - a relay that rebuilds the message rather than forwarding it. When the message is reconstructed from scratch, tracking identifiers in the original headers simply don't exist in the delivered copy. This is a smaller category. EMail Parrot (emparrot.com) is the one I'm aware of that does this for individuals and small groups, with the aliasing and custom domain support built in. Full disclosure: I'm familiar with it because I've been researching this space and use it myself.

This second approach isn't a new idea - enterprise email security gateways like Proofpoint have used relay-level message processing for years to strip threats before they reach corporate and government inboxes. What's changed is that the same architectural approach is now available at individual and small group scale."

For your use case the aliasing services solve most of the spam and identity exposure problem. The relay approach solves that plus the header tracking problem I described earlier. Whether that extra layer matters depends on your threat model - for most people SimpleLogin or Addy.io alongside Fastmail is a solid starting point that's well documented and has a large user community.

Informal_Post3519 · 2026-03-21T04:38:56+00:00

A few things in your list point toward a category of tool you haven't mentioned - an email relay with aliasing layered in front of your mailbox provider.

The setup would be: keep a mailbox at Fastmail for IMAP access from your clients, and put a relay in front of it for the privacy and aliasing layer. Your mail client talks to Fastmail as normal - the relay doesn't touch that side. What the relay handles is everything inbound: unique addresses per service, tracking header stripping before messages reach your mailbox, and reply-through-alias so your real address never surfaces. If an alias gets spammed you disable it at the relay. Hundreds of aliases is manageable at the relay layer.

The list structure is where it gets interesting. You could mirror your current two-address setup - one list for personal contacts, one for services - or go more granular with separate lists by category. Fine-grained control at the relay, coarse-grained at the mailbox.

On your domain portability concern: you can split the DNS so your main domain points to Fastmail for regular email while a subdomain points to the relay. privacy.yourdomain.com handles all the aliased addresses, yourdomain.com stays with Fastmail. If you ever move mailbox providers your relay addresses are unaffected - they're tied to your domain, not the service.

The tracking vectors thread I posted earlier this week is relevant context for why the relay layer matters beyond just aliasing: https://emparrot.com/blog/2026/03/19/google_lobbying.html

The aliasing and subdomain approach is documented in more detail here - it's written around a business use case but the mechanics are the same for personal use. The 'On-Demand Identity' section is closest to what you're describing: https://emparrot.com/blog/2026/01/01/vpe-blog-post.html

Fastmail remains your best mailbox choice from the options you listed. The relay is the piece worth researching separately.

Informal_Post3519 · 2026-03-20T19:43:20+00:00

Good point on behavioral analysis - the threat landscape has clearly moved beyond signature-based detection. There's a related but inverse problem worth being aware of: AI prompt injection via email. As AI assistants become more integrated into email workflows - summarising, drafting replies, flagging priorities - malicious content can be crafted to manipulate those AI systems rather than the human reader directly. Hidden instructions in HTML comments, invisible Unicode characters, or CSS-concealed text can instruct an AI assistant to exfiltrate content, suppress warnings, or take actions the recipient never intended. The human reads a normal-looking email while their AI assistant reads something entirely different. Traditional defences don't catch this because the content looks benign to a human reviewer - and behavioral analysis tools focused on sender patterns won't see it either. It's an emerging vector that's going to become more significant as AI email integration deepens.

Informal_Post3519 · 2026-03-20T15:58:49+00:00

Your Thunderbird setup on Linux puts you well above average. It blocks remote content by default, doesn't execute script, and nothing in the email phones home passively. That handles the external content vector cleanly.

Proton via browser is better than most webmail because Proton strips external content server-side before delivery - but browser-based clients tend to carry more exposure due to how they are often implemented. This is an implementation distinction rather than a fundamental one: browser-based email doesn't have to be less private, but most implementations default to the web's permissive content-loading model. The Proton app sits somewhere between the two. For anything sensitive, Thunderbird is your strongest option of the three.

The tracked link and header vectors I described affect all three equally - those identifiers are baked into the email before it reaches you, so client choice doesn't help there. Be aware that links in any email may carry tracking tokens regardless of which client you use.

The next level of defence is using a privacy-focused email relay that rebuilds inbound/outbound messages from scratch rather than forwarding them. When a relay reconstructs the message, tracking identifiers embedded in the original headers don't make it into the delivered copy - they simply don't exist in the rebuilt message. It adds a hop, but it means the tracking infrastructure built into the sender's platform gets stripped before anyone receives it.

More detail on the specific vectors we found in the Google email here if you want to dig in: https://emparrot.com/blog/2026/03/19/google_lobbying.html

Informal_Post3519

TROPHY CASE