By William Weiner July 15, 2026
The earlier posts on this blog – The Cookie That Never Expires and UID2: The Standard That Replaced the Cookie – made an argument about how the ad industry replaced the cookie with your email address. This post is not an argument. It is what happened when that argument got pointed at one person’s actual mail.
The corpus is two personal mailboxes, a handful of single-service aliases, and a script that never once touches the network – it only reads what senders already embedded in the message. What came back is a specific, traceable answer to the industry’s favorite defense, that tracking pixels are harmless aggregate telemetry counting opens. The mail says otherwise, and it says something stranger besides.
The experiment
Two personal email addresses, a Gmail account and a Yahoo account, both years old and both still in daily use, plus about twenty single-service aliases – one address handed to the pharmacy, one to a utility co-op, one to a retailer, and so on. Just over a month of incoming mail, a little more than 1,500 messages. A pair of small Python scripts, well under a thousand lines combined, using nothing outside the standard library. The scripts never fetch a URL. They only read what senders already put in the message: the invisible tracking images, the rewritten links, the query-string parameters riding along inside them. Every value that could identify a specific person was pseudonymized before anything left the mailbox – what follows is what the patterns showed, not any of the underlying identifiers.
Finding one: tracking is personal, not aggregate
The industry’s standard defense of the open-tracking pixel is that it is harmless aggregate telemetry – a count of opens, nothing more. The mail itself does not support that description. Of the tracking parameters seen often enough to classify, well over half reset to a new value in nearly every single message. That is not a campaign counter. A campaign counter is the same value across a thousand recipients. A value that changes almost every time it appears is a recipient identifier, and it is attached to a specific person’s inbox activity from the moment the message is opened.
The two addresses told slightly different stories, which is itself informative: the Yahoo address, the older and more heavily subscribed of the two, carried a tracking pixel on over 92 percent of its messages. The younger, more selectively used Gmail address sat at just over half. Age and exposure, not some inherent property of email, appear to drive how tracked an inbox becomes.
France’s consent deadline for sending an email tracking pixel without permission passed on July 14, 2026, and the CNIL’s recommendation behind it is now being contested before France’s Conseil d’Etat by industry associations arguing that a pixel is nothing more than benign aggregate telemetry. This finding is what that argument looks like next to a real inbox.
The same argument is playing out in American courtrooms under a different theory. A wave of lawsuits under California’s Invasion of Privacy Act, the state’s decades-old wiretap statute, argues that a tracking pixel firing without consent is the email-era equivalent of tapping a phone line – part of a broader run of CIPA tracking litigation numbering well into the thousands over the past two years. Forbes agreed to pay $10 million to settle a CIPA claim over website trackers rather than litigate the theory. A federal court reached the opposite conclusion in a case brought directly over email marketing pixels against Gap, dismissing it on the ground that a sender receiving its own tracking data is a party to the communication, not an eavesdropper on it. Courts on both continents are being asked, right now, what these pixels actually do. Here is a specimen from one real mailbox.
Finding two: the twist
Here is where the story should turn villainous, and does not. Take a sender’s newsletter that reaches both the Gmail and the Yahoo address – the same campaign, sent independently to two addresses that, as far as that sender’s own system is concerned, belong to two different people. Comparing the two copies directly, every time a sender used a genuinely per-recipient identifier, the value differed between the two copies. Not once, across six different senders exhibiting this behavior, did the same per-recipient token turn up on both addresses. An adventure-travel operator that hashed the reader’s email address for its own tracking produced two different hashes – one for each address – because the two addresses are, mechanically, different strings. The sender is not secretly aware that both inboxes belong to the same person. It is keeping two separate records, one per address, exactly as it appears to believe it is doing.
That is a real finding, and it cuts against the instinct to look for a villain at the sending end. Individual companies, at least the ones caught here, are not the ones merging your identities. The place to look is not the sender. It is what the sender does with the identifier once it has generated it.
Finding three: where the merge actually happens
Three unrelated senders – two airlines and a furniture retailer – each embedded a tracking parameter carrying the SHA-256 hash of the same email address. Nothing unusual there on its own; hashing an address for tracking is now routine, as the earlier UID2 post described. What stands out is where the identical hash went. One airline’s copy called Oracle’s BlueKai audience platform. The other airline’s copy called Salesforce’s Krux beacon, the tracking pixel behind its Audience Studio data platform. The furniture retailer’s copy sent the same hash directly to its own vendor’s tracking subdomain. Three unrelated companies, three different destinations, and one identical value arriving at two rival data-management platforms that otherwise have no reason to know about each other.
This is the mechanism worth sitting with. No sender merged anything. Each one independently did the ordinary, industry-standard thing: hash the address you were given, send the hash to your tracking vendor. But SHA-256 is deterministic – the same input always produces the same output, with no key, no secret, and no coordination required between the two airlines to arrive at it. Once that hash lands in two different databases, at Oracle and at Salesforce, anyone in a position to query both suddenly has a join key connecting a customer at one airline to the same customer at the other, and at a furniture retailer besides. The senders kept their own books straight. The join happens one layer up, in infrastructure none of the three senders individually control, out of sight of every party to the original message.
Weaker hashing has not gone away, either. Across every confirmed hashed-email match in this corpus, about a fifth still used MD5 – a cryptographic hash considered broken for security purposes for close to two decades – sitting right alongside SHA-256 in production identity-tracking code. And the hash is only the disguised version of the problem: more than 25,000 individual tracking links and images in this one mailbox carried the reader’s email address in plain text in the URL itself, no hashing involved at all.
The fair-balance part
Not every alias told a bad story. Roughly twenty single-service alias addresses were seeded into this experiment specifically as canaries – an address handed to exactly one company, watched for any sign it reached somewhere it was never given. In this window, none did. No alias addressed to one company showed up in mail from an unrelated one. That is worth saying plainly: the failure mode uncovered here is not senders selling your alias down the line. It is what the address you already handed over becomes, structurally, once it is hashed and handed to shared infrastructure. The problem is the architecture, not a cast of cartoon villains.
What EMail Parrot does with this
None of the three mechanisms above depend on tricking the sender. They depend on the reader’s address, in whatever form, reaching the sender at all. EMail Parrot’s default handling removes tracking pixels and remote content before a message is delivered, and strips or rewrites the tracking parameters riding inside links, on every list, by default. A hash generated from an address, or a plaintext address sitting in a URL, that never reaches a sender in the first place cannot be exported anywhere – not to Oracle, not to Salesforce, not to whichever platform picks up the next one. Removing the identifier before it leaves the message is a smaller claim than promising to police what every ad-tech platform does with it afterward, and it is the one a relay can actually keep.
Caveats, stated plainly
This is one recipient’s mail, over a bit more than a month, weighted toward senders operating in the United States. The mechanisms described here – per-recipient tracking identifiers, independent hashing of separate addresses, the same hash reaching more than one data platform – are demonstrated facts about this corpus, not inferences. The prevalence figures are not a claim about email in general; they describe what accumulates in one long-lived personal mailbox and should be read as exactly that. A methodological note for anyone checking the arithmetic: part of the older mailbox’s mail arrived as forwarded copies of earlier messages rather than fresh sends. Those forwarded copies were checked directly against pristine, unforwarded captures of the same underlying messages and carried identical identifier sets – the forwarding step did not add or remove anything a tracker would notice.
The industry did not build a system to merge your identities on purpose. It built a system where merging them is what happens automatically, as a side effect of every sender doing the same standard, unremarkable thing with the address you gave them.
Questions about migrating? Email us at info@emparrot.com.