Hashing an email address does not anonymise it. Anyone holding a list of candidate emails can hash each one and compare, so the hash still singles out a person. Under GDPR that makes it pseudonymised at best, which is still personal data, with all the obligations that follow.
Myth: a hash cannot be reversed, so it is anonymous
True, a good hash function cannot be run backwards. But nobody needs to. Email addresses are low entropy and guessable. An attacker, a partner or even your own analytics vendor can take a list of known addresses, hash each with the same function, and look for matches.
Recital 26 of GDPR tells you how to judge this. Data is anonymous only if the person is not identifiable by "all the means reasonably likely to be used", including singling out. A lookup against a known list is a reasonable means.
Fact: a hash works as a stable identifier
That stability is often exactly why teams hash: to join records across systems without sharing the raw value. The same property makes the hash a persistent identifier for one person. If two datasets both carry the hash, they can be linked, and a linked profile is personal data.
Salts and keyed hashes
Adding a secret key, using an HMAC, changes who can reverse the mapping. Only holders of the key can test guesses. That is a real improvement and matches the GDPR idea of pseudonymisation, where attribution needs "additional information" kept separately.
Even so, the result is pseudonymised, not anonymous. You, the key holder, can still re-identify, so the data stays in scope.
A plain salt stored next to the hashes adds little. Anyone with the data has the salt.
What to use depending on the goal
- Join across your own systems: use an internal pseudonymous ID, not a hash of the email. It can be rotated and deleted.
- Share with a partner for matching: treat it as personal data transfer. Sign the right contracts, limit fields, and use a keyed method with an agreed scope.
- Publish or release statistics: aggregate, remove identifiers and test re-identification risk. See k-anonymity explained for developers and differential privacy basics for approaches.
- Logs: log an internal ID instead of any form of the email.
A quick way to test your claim
Ask: if someone had a list of one million emails, could they find my record? If yes, the data is not anonymous. Ask the same question about every other attribute, since combinations like date of birth, postcode and gender also single people out.
Quick check
Is SHA-256 of an email personal data?
Yes, in most real settings. It can be matched against candidate addresses, so the person remains identifiable.
Does an HMAC make it anonymous?
No. It is stronger pseudonymisation, but whoever holds the key can re-identify, so it stays personal data.
Sources
Last reviewed: 19 October 2026.
