A cryptographic hash is one-way in the sense that you cannot invert the function. It is not one-way in the sense that matters here, because you do not need to invert anything. You need to guess the input, hash it, and compare. If the space of plausible inputs is small, a hash is a lookup key wearing a disguise.
Email addresses live in a very small space. The set of addresses that actually exist is finite, heavily concentrated in a handful of domains, and available in bulk: marketing lists, public directories, and a decade of breach dumps. Anyone holding a list of a billion addresses can hash all of them once and match forever. In July 2024, the U.S. Federal Trade Commission published a staff post making exactly this point, under the title "No, hashing still doesn't make your data anonymous."
A hash is deterministic. The same address always produces the same digest, for everyone, everywhere. That is precisely the property advertisers want: a stable identifier that two companies can compare without sending each other plaintext. Determinism is what makes it a join key, and being a join key is incompatible with being anonymous.
Compare that with a design where hashing genuinely does protect the input. Password breach checking uses k-anonymity: your client sends only the first five characters of a hash prefix and receives hundreds of candidate suffixes to compare locally. The server never learns which one you were asking about. That is a deliberate construction. Sending a full hash of a known-format identifier is the opposite of it.
Inside a modern email-based identifier
Unified ID 2.0 is the most widely deployed of the post-cookie identifiers, originally built by The Trade Desk and later moved under industry governance. Its published design is more careful than raw hashing, and it is worth reading precisely because the extra care shows what the plain version leaks.
- Normalization. The address is lowercased and trimmed. For some large providers, dots and plus-suffixes in the local part are stripped, so first.last+shopping@ and firstlast@ collapse to the same input.
- Hashing. The normalized address is hashed with SHA-256.
- Salting. An operator applies a secret, rotating salt and hashes again, producing the raw identifier. The salt is what stops any random party from computing your identifier from a leaked address list.
- Tokenization. The raw identifier is encrypted into short-lived tokens for transmission through the bidding pipeline.
Step 1 is the one people miss. Normalization is designed to defeat the plus-address trick, so site+name@ aliases at the large mailbox providers frequently do not create separate identities in this system. Steps 3 and 4 are real protections, but they protect against outsiders, not participants. Any company inside the ecosystem that already has your address can obtain your identifier through the normal flow. The salt raises the cost of an offline attack; it does not change who you are to the network.
The graph behind the identifier
An identifier is only valuable if it resolves to a person across contexts, and that resolution happens in identity graphs run by data companies. A graph maps many identifiers to one node: several email addresses, a postal address, phone numbers, mobile advertising IDs, cookie IDs, and household relationships. The output is a persistent pseudonymous ID that follows the node rather than the browser.
| Identifier | Lifetime | Survives |
|---|---|---|
| Third-party cookie | Days to months | Nothing much. Clearing storage kills it. |
| Device advertising ID | Until reset | Browser changes, but is per-device and resettable. |
| Hashed email | Years | New devices, new browsers, app installs, cleared storage, private windows once you log in. |
| Graph node ID | Effectively permanent | Changing your email, because the graph links the old one to the new one. |
This is why the email became the anchor. It is the one identifier users deliberately keep stable for years and re-enter voluntarily on every new device. Cross-device stitching that used to require statistical inference, described in our piece on cross-device tracking, becomes a database join instead.
Where the collection actually happens
The address enters the pipeline at ordinary, unremarkable moments:
- Login walls on content. "Sign in to keep reading" converts an anonymous reader into a resolvable one. The publisher gains an addressable audience segment and passes an identifier into the bid request.
- Checkout and receipts. Purchase data attached to an identity node is the highest-value input a graph can get, because it closes the loop between an ad and a sale.
- Newsletters and loyalty programs. Both hand over an address plus an interest signal in one step.
- Captive portals and in-store wifi. An address collected once at a physical location links online identity to a place.
- Email opens. A tracking pixel confirms the address is live and ties it to an IP and a client, which is why an address you never typed anywhere else can still gain a graph presence.
From there the identifier moves through the real-time bidding pipeline, where a bid request can be seen by hundreds of companies, and through data clean rooms, where two parties match their hashed lists to find overlap without exchanging raw files. Clean rooms are often presented as a privacy control. They constrain who sees the raw list; they do not stop individual-level matching, which is the point of running one.
What breaks the join
The vulnerability of this whole structure is that it depends on you supplying the same string in many places. Break that and the graph loses its anchor.
- A unique address per service. This is the measure that actually works, because it attacks the join rather than the collection. Each site still knows its own customer. No site can match that customer against another site's list. Our guide to email aliases covers the mechanics and the failure modes, including what happens when a relay provider becomes a single point of correlation itself.
- Distinct addresses, not plus-suffixes. Because of the normalization step above, plus-addressing is a filing convenience rather than a privacy measure at the large providers.
- Opt-out signals where they carry legal weight. Global Privacy Control is legally enforceable under some state laws and voluntary elsewhere. It is worth sending and worth not relying on.
- Deletion requests to the graph operators directly. Slow, partial, and repeatable, as covered in data broker opt-outs. The graph node persists even when a single identifier is removed.
The claim to watch for, in a policy or a vendor pitch, is any sentence that treats hashing as the privacy measure. Hashing is a transport format. The question worth asking is whether the recipient can already compute the same digest, and for an email address the answer is nearly always yes.