Protect Your Visitor Identities: Why you should always salt your hashed email

Last Updated on May 5, 2025
Salting your hashed email address is always a good idea!

In today’s digital marketing, personalisation is everything. One effective approach is using hashed email addresses (HEM) appended to email links, enabling marketers to track and personalize visitor interactions seamlessly. But if you’re adding unsalted hashed emails directly to your links, especially those pointing to third party sites, you might unknowingly be exposing your business to significant risks.

Are We Just Being Paranoid?

You might think that hashing email addresses makes them no longer considered as PII. Unfortunately (and this is very important) this is not the case.

Under the General Data Protection Regulation (GDPR), hashed email addresses are considered personal data, even when salted. This is because hashing is a form of pseudonymization, not anonymization. Pseudonymized data can still be attributed to an individual if additional information is available, whereas anonymized data cannot be reidentified.

Recital 26 of the GDPR clarifies that personal data which has undergone pseudonymization and can be attributed to a natural person using additional information should still be considered information on an identifiable natural person.

Therefore, even if you hash email addresses, they remain within the scope of GDPR. Organizations must ensure appropriate technical and organizational measures are in place to protect such data and comply with GDPR requirements. Here are few relevant articles for those of you, who want to dig more into background information:

Why Are We Even Using HEMs In First Place?

HEMs are invaluable for bridging the gap between known contacts in your Salesforce Marketing Cloud (SFMC) and anonymous visitors interacting with your website. When properly implemented, these hashed identifiers help you track website interactions at a personal level, transforming anonymous website behavior into actionable insights. For instance, leveraging HEMs allows marketers to precisely measure engagement, dynamically tailor content and experiences, and even build advanced behavioral segmentation.

My own implementation, detailed extensively in this article, outlines using Einstein Recommendations within Salesforce Marketing Cloud, which leverages these hashed email identifiers effectively. Einstein Email Recommendations track user behavior and dynamically surface personalized content. While these recommendations typically rely on cookie based identifiers for web implementations, appending a securely hashed email address ensures a deterministic linkage between email interactions and subsequent website visits. Specifically, when recipients engage with your email content, their unique hashed identifier can help track their on site behavior. This approach facilitates detailed segmentation, categorizing visitors based on their affinity for certain content, products, or other attributes, and delivering truly personalized experiences.

Another related use case is demonstrated by platforms such as SalesWings, which employs a similar concept of hashed identifiers to connect the dots between known CRM contacts and their online behavior. By embedding securely hashed identifiers into their communication links, SalesWings helps marketers score leads dynamically, prioritize sales efforts, and provide precise, timely follow ups based on real-time behavioral data.

However, the importance of salting your hashes can’t be overstated. Unsalted hashes exposed through third party URLs pose significant privacy risks, potentially enabling malicious actors to reverse engineer and identify your users. Salting your hashes ensures robust security by adding a secret string to the email before hashing, making it exponentially more difficult for anyone to compromise your users’ identities.

By securely implementing salted hashed identifiers and integrating them effectively with Salesforce Marketing Cloud, marketers can achieve unparalleled personalization without compromising privacy or security. Let’s dive more in what hashing is, why salting your hashes matters, the potential dangers of unsalted hashes, and clear examples of securely generating salted HEMs in Salesforce Marketing Cloud (SFMC).

Why Unsalted Hashes Pose a Risk

Hashing emails using algorithms like SHA-256 converts personal email addresses into seemingly random strings of characters, which you can safely pass around. However, without salting (adding a secret string to the email before hashing), even while there is no direct way to decode it, hashes remain vulnerable to brute force or dictionary attack.

Imagine you’re adding an unsalted hash to all your email links, even those pointing to third party websites. Anyone with access to this hash and a sufficiently large database of email addresses could potentially reverse engineer and identify individual users, compromising their privacy and risking no compliance with data protection regulations like GDPR.

Additionally, sharing unsalted hashes externally increases the exposure risk, as third-party sites may inadvertently or maliciously misuse the hashes.

The Power of Salting

Salting means adding a unique, secret value to the email before hashing. Even identical emails hashed with different salts produce entirely different results, significantly reducing vulnerability to reverse-engineering:

Unsalted hash example:

SHA256("john.doe@example.com") = 836f82db99121b3481011f16b49dfa5fbc714a0d1b1b9f784a1ebbbf5b39577f

Salted hash example:

SHA256("john.doe@example.com|SuperSecretSalt") = 9358076a31e37b78fb7daef67fa77bbe7236e33d03cb232912c71bc121581e1f

Notice how the salted hash is entirely different, even though the email is the same!

How to Implement Salted HEM in SFMC

Below are clear examples of generating a securely salted hashed email (HEM) in SFMC using SQL, Server-Side JavaScript (SSJS), and AMPscript.

SQL Example (Automation Studio Query Activity)
SELECT
  SubscriberKey,
  CONVERT(VARCHAR(64), HASHBYTES('SHA2_256', LOWER(EmailAddress) + '|SuperSecretSalt'), 2) AS SaltedHEM
FROM
  YourDataExtension

Replace YourDataExtension with your actual data extension name and ensure the salt (SuperSecretSalt) is securely stored and not exposed publicly.

Server-Side JavaScript (SSJS) Example
<script runat="server">
  Platform.Load("Core", "1.1.1");
  var email = "john.doe@example.com";
  var salt = "SuperSecretSalt";
  var saltedEmail = email.toLowerCase() + "|" + salt;
  var saltedHEM = Platform.Function.SHA256(saltedEmail);

  Write("Salted HEM: " + saltedHEM);
</script>

AMPscript Example
%%[
var @Email, @Salt, @SaltedEmail, @SaltedHEM
set @Email = lowercase(AttributeValue("EmailAddress"))
set @Salt = "SuperSecretSalt"
set @SaltedEmail = Concat(@Email, "|", @Salt)
set @SaltedHEM = SHA256(@SaltedEmail)
]%%

Salted HEM: %%=v(@SaltedHEM)=%%

Ensure SuperSecretSalt is securely managed and not publicly exposed.

Always Lowercase Before Hashing

To ensure consistent and accurate identity matching, you should always convert email addresses to lowercase before hashing them. While the local part of an email (before the @) is technically case sensitive, almost all email providers treat them as case insensitive in practice. Without this standardization, you risk generating different hashes for what is essentially the same user (e.g. Lukas@example.com vs. lukas@example.com).

Failing to lowercase can result in fragmented identity profiles, misattributed behaviors, and broken personalisation. Whether you hash emails with or without a salt, always normalize them to lowercase first, this ensures unified tracking, cleaner data, and a more coherent customer journey.

SHA256("john.doe@example.com|SuperSecretSalt") ≠ SHA256("John.Doe@example.com|SuperSecretSalt")

Let’s compare the output of these two examples above, so you can see for yourself:

SHA256("john.doe@example.com|SuperSecretSalt") = 9358076a31e37b78fb7daef67fa77bbe7236e33d03cb232912c71bc121581e1f
SHA256("John.Doe@example.com|SuperSecretSalt") = 6299ab168fedb62bdeef743ef327750374d582e9ec5775e6f07bbf14dc5d9685

Make lowercasing part of your default preprocessing step before salting and hashing, regardless of the channel or language (SQL, AMPscript, SSJS) you’re working in.

Key Takeaways

  • Hashed PII is still PII: Treat your HEMs as they were email addresses
  • Always Salt Your Hashes: Prevent the risk of brute-force or dictionary attacks.
  • Avoid Unsalted Hashes in Third-party URLs: Protect visitor privacy by never exposing unsalted hashes externally.
  • Securely Store Your Salts: Maintain salts securely, rotate them periodically, and never expose them publicly.

Implementing salted hashes may seem like an extra step, but it’s crucial for robust privacy protection and compliance in your digital marketing activities. With the above examples, you can easily and securely integrate this best practice into your Salesforce Marketing Cloud implementation.

Scroll to Top