Suped

Is base64 encoding required by Google for plain text email unsubscribe links to protect PII?

Matthew Whittaker profile picture
Matthew Whittaker
Co-founder & CTO, Suped
Published 5 Jul 2025
Updated 19 Aug 2025
6 min read
The question of whether Base64 encoding is a requirement from Google for plain text email unsubscribe links, particularly for the protection of Personally Identifiable Information (PII), is a common point of confusion for many senders. A client recently shared that their Email Service Provider (ESP) asserted this was a Google mandate, which prompted me to investigate the claim.
My immediate thought was that this wasn't quite right. While there are certainly best practices around protecting PII and adhering to unsubscribe standards, a specific requirement from Google for Base64 encoding in this context didn't align with my understanding of their guidelines. Google (and Yahoo) are primarily concerned with ensuring users have an easy, one-click way to unsubscribe from unwanted emails, and they have strict policies against exposing sensitive user data.
The core issue isn't whether encoding is used, but whether the method adequately protects PII and if the unsubscribe mechanism functions correctly without unnecessary hurdles. Let's delve into Google's guidelines, the nature of Base64 encoding, and the most effective strategies for managing unsubscribe links while safeguarding user data.

Understanding Base64 encoding and PII

Base64 encoding is a common method for converting binary data into an ASCII string format. It's often used in email to transmit data that might otherwise be corrupted or misinterpreted by various email systems, as email was originally designed for 7-bit ASCII text. This is why you frequently see it employed for attachments or complex characters in email bodies. However, it's crucial to understand what Base64 encoding actually does.

What Base64 is

Base64 is an encoding scheme, not an encryption method. Its purpose is to represent binary data in an ASCII string format, making it safe for transmission over systems that are not designed to handle raw binary, like older email protocols. It simply translates data from one format to another.

Security implications

Because it's an encoding, Base64 is easily reversible. Anyone with the encoded string can quickly decode it back to its original form using widely available tools. This means that if PII, such as an email address, is encoded using Base64 and included in a URL, it is still effectively exposed. It offers no meaningful protection against data exposure.
Therefore, stating that Base64 encoding is required by Google to protect PII in unsubscribe links is a misunderstanding. While it might be used by an ESP as a method to pass unique identifiers, it does not provide the security needed to genuinely protect sensitive data from being deciphered. If an ESP uses Base64 to encode an email address directly in an unsubscribe link, that email address remains easily discoverable, defeating the purpose of PII protection.
The primary objective should be to use methods that truly obscure or, ideally, avoid including PII in plain text (or easily reversible encoded text) within URLs. This is where the real security and privacy considerations lie, not in the use of a simple encoding scheme like Base64.
Google's policies on Personally Identifiable Information (PII) are quite clear. Their platform policies explicitly prohibit passing PII to Google Analytics, Google Ads, or other Google systems via URLs. This is primarily to prevent inadvertent collection and indexing of sensitive user data in their systems.
While this policy is most directly concerned with tracking data in web analytics or advertising platforms, the spirit of it extends to any scenario where PII might be unintentionally exposed. An email unsubscribe link, especially if it contains the recipient's email address (even Base64 encoded) in the URL parameter, could potentially fall under this umbrella. If a user clicks such a link and it's then captured by an analytics tool, it could be flagged as a policy violation.

The risk of PII in URLs

Including PII like email addresses directly in unsubscribe URLs, even when Base64 encoded, creates a vulnerability. These URLs can be logged by web servers, proxies, analytics tools, and even browser histories. If such logs are compromised or improperly handled, the PII can be easily extracted, leading to privacy breaches. This is why it is generally advised to avoid putting any easily identifiable user data directly into URL parameters.

Impact on email deliverability

While Google does not explicitly state that Base64 encoding of unsubscribe links is a requirement, using methods that compromise privacy can indirectly affect your sender reputation. ISPs, including Gmail and Yahoo, prioritize user safety and privacy. Practices that disregard PII protection could lead to increased spam complaints, lower inbox placement rates, and potential listing on email blocklists (or blacklists).
The focus should always be on securely identifying the recipient for unsubscribe purposes without exposing their email address or other sensitive information in a readily decipherable format within the URL.

One-click unsubscribe and privacy

Instead of focusing on Base64, Google and Yahoo's new sender requirements emphasize the implementation of a one-click unsubscribe mechanism, primarily through the List-Unsubscribe header. This is a standard defined by RFC 8058, which allows email clients to display an automated unsubscribe button, simplifying the process for users.
Example of List-Unsubscribe Header for One-Click UnsubscribeHTTP
List-Unsubscribe: <https://example.com/unsubscribe?id=hasheduser123>, <mailto:unsubscribe@example.com?subject=unsubscribe> List-Unsubscribe-Post: List-Unsubscribe=One-Click
The key here is that the unsubscribe link (or mailto address) must contain a unique value that allows the sender to identify the subscriber without requiring them to log in or take multiple steps. This unique value does not need to be the actual email address, nor does it need to be Base64 encoded. Most ESPs use a unique, often hashed or tokenized, ID associated with the subscriber record in their database.

ESP’s approach (using Base64)

  1. Identification method: The ESP might Base64 encode the recipient's email address and append it as a parameter in the unsubscribe URL (e.g., unsubscribe?email=base64encodedemail). This allows them to identify the user upon click.
  2. Privacy implications: While it's not plain text, Base64 is easily reversible, meaning the email address can be quickly decoded by anyone who intercepts the URL or views the source code. This directly conflicts with best practices for PII protection in public-facing URLs.
  3. Compliance: It might technically satisfy the 'unique identifier' aspect for one-click unsubscribe, but it falls short on robust privacy protection as per Google's broader PII policies.

Recommended secure approach

  1. Identification method: Use a unique, non-PII identifier, such as a randomly generated token or a securely hashed ID, that maps back to the subscriber in the ESP's database. This value is then passed in the URL (e.g., unsubscribe?token=uniqueid123).
  2. Privacy implications: Since the identifier itself is not PII, even if intercepted, it doesn't directly expose user data. Only the ESP's system can link it back to the specific subscriber.
  3. Compliance: This method fully complies with the spirit and letter of Google's PII policies and the one-click unsubscribe requirements, offering both functionality and strong privacy protection.
ESPs choosing to Base64 encode email addresses in unsubscribe links are likely taking an easy route, satisfying the technical need for a unique identifier without truly addressing the underlying privacy concern of exposing PII, even in an encoded form. It fulfills the functional requirement of identifying the user, but not the security expectation.
For optimal email deliverability and to maintain a good sender reputation, it's essential to follow best practices that prioritize user experience and privacy. While Base64 encoding for unsubscribe links isn't explicitly forbidden, it's not the most secure or recommended approach for handling PII. The key is to balance the need for a unique unsubscribe identifier with robust data protection.

Requirement

Best practice for PII in unsubscribe links

Why it matters

Unique ID for unsubscribe
Use a hashed or tokenized ID that maps to the subscriber's record, not their actual email address.
Ensures the unsubscribe request can be processed accurately without directly exposing subscriber PII in the URL.
List-Unsubscribe header
Implement both List-Unsubscribe-Post (one-click) and a URL-based unsubscribe option.
This is a key requirement for Google and Yahoo for bulk senders, improving user experience and reducing spam complaints.
Avoid PII in URLs
Never include plain text PII in unsubscribe link parameters. Even Base64 encoding is not enough.
Protects against accidental PII logging and potential policy violations, which can negatively impact email deliverability.
Adopting these practices ensures that you meet compliance requirements, protect your subscribers' privacy, and maintain a healthy sender reputation, reducing the likelihood of your emails ending up in the spam folder or on an email blocklist (or blacklist).

Views from the trenches

Best practices
Ensure your unsubscribe links use unique, non-identifiable tokens instead of email addresses.
Always implement the List-Unsubscribe header for one-click unsubscribe functionality.
Regularly monitor your email logs and analytics to confirm no PII is being unintentionally exposed in URLs.
Common pitfalls
Relying solely on Base64 encoding for PII in unsubscribe links, assuming it provides security.
Failing to implement the List-Unsubscribe header, leading to user frustration and compliance issues.
Requiring users to log in or take multiple steps to unsubscribe, which increases spam complaints.
Expert tips
Use a robust hashing algorithm or an opaque token unique to each subscriber for unsubscribe URLs.
Verify that your ESP's unsubscribe mechanism adheres to RFC 8058 standards, including the List-Unsubscribe-Post header.
Conduct regular audits of your unsubscribe process to ensure it's seamless and privacy-compliant.
Expert view
Expert from Email Geeks says that Base64 encoding of email addresses is not required, but a unique value in the List-Unsubscribe header is necessary.
2018-04-26 - Email Geeks
Expert view
Expert from Email Geeks says that while Base64 encoding may seem like a quick fix, it's easily reversible and not a robust solution for PII. It's better to use unique, meaningless identifiers that map back to the subscriber without exposing their email directly.
2018-04-27 - Email Geeks

Final thoughts

To summarize, Google does not require Base64 encoding for plain text email unsubscribe links to protect PII. Their primary concern is the proper implementation of one-click unsubscribe, typically via the List-Unsubscribe header, and the protection of PII from being exposed in easily discoverable formats within URLs. While Base64 can be part of an ESP's internal process for unique identification, it's insufficient as a standalone security measure for sensitive data. Senders should prioritize using truly secure, non-reversible methods like hashed or tokenized IDs to identify subscribers for unsubscribe purposes, ensuring compliance and maintaining strong email deliverability.

Frequently asked questions

DMARC monitoring

Start monitoring your DMARC reports today

Suped DMARC platform dashboard

What you'll get with Suped

Real-time DMARC report monitoring and analysis
Automated alerts for authentication failures
Clear recommendations to improve email deliverability
Protection against phishing and domain spoofing