Email Compliance Infrastructure: CAN-SPAM and GDPR Side by Side

• October 2019
• Engineering Memo · External Release

Most email programmes that serve audiences in both the United States and Europe must comply with two fundamentally different regulatory frameworks simultaneously: CAN-SPAM (US, 2003) and GDPR (EU, 2018). These frameworks have different philosophical foundations — CAN-SPAM is an opt-out regime that permits email marketing unless the recipient has opted out; GDPR is an opt-in regime that requires a lawful basis (usually consent) before marketing email can be sent. The infrastructure and operational practices that support compliance with both simultaneously must accommodate these different requirements without creating separate sending programmes for each jurisdiction.

This note documents the specific requirements of each framework, where they create conflicting obligations, and how email infrastructure can be configured to support compliance with both.

CAN-SPAM: What It Actually Requires

The CAN-SPAM Act (Controlling the Assault of Non-Solicited Pornography And Marketing Act) sets the minimum requirements for commercial email in the United States. Despite its age (enacted 2003, amended minimally since), CAN-SPAM remains the primary federal email marketing law in the US. Its requirements:

Identification: The From:, To:, Reply-To:, and routing information must be accurate and not misleading. The From: display name and address must accurately identify the sender. Subject lines must not be misleading about the content of the message.

Physical address: Every commercial email must include a valid physical postal address — the sender's current street address, PO box, or private mailbox. This must appear in the message body, typically in the footer.

Opt-out mechanism: Every commercial email must include a clear and conspicuous mechanism by which recipients can opt out of future commercial email from the sender. The mechanism must be clearly explained in the message — a functional URL or reply address that the recipient can use to opt out. Opt-out requests must be honoured within 10 business days. The sender may not require a fee, provide personally identifying information beyond an email address, or take any other action as a condition of honouring an opt-out request.

No deceptive routing: Emails must not be sent through technically deceptive means — open relays, hijacked computers, spoofed headers, or false sender identification.

CAN-SPAM does not require affirmative consent (opt-in) to send marketing email. It permits email marketing to recipients who have not opted in, as long as the opt-out mechanism is available and honoured. This is fundamentally different from GDPR's consent requirement.

Where They Conflict: The Opt-In vs Opt-Out Tension

The fundamental tension between CAN-SPAM and GDPR is the opt-in vs opt-out philosophy. CAN-SPAM permits sending to anyone who hasn't explicitly opted out. GDPR requires affirmative consent (or another lawful basis) before sending to EU residents. A contact list acquired through a US approach — gathering email addresses from business cards, website visitors who provided email for a download, or other soft-opt-in methods — may be CAN-SPAM compliant but GDPR-non-compliant for EU resident contacts in that list.

Programmes that send to mixed US-EU lists must either: (a) apply the stricter GDPR standard globally (requiring documented consent for all contacts, regardless of jurisdiction); or (b) segment the list by jurisdiction and apply different lawful basis documentation to EU and non-EU contacts. Option (a) is simpler operationally and produces a cleaner compliance posture; option (b) requires reliable jurisdiction identification for each contact and separate compliance documentation for each segment.

The practical recommendation for most programmes: apply GDPR-compliant consent practices globally. Using consent as the lawful basis for all contacts — not just EU residents — eliminates the need to segment by jurisdiction and produces a simpler compliance documentation story. The overhead of GDPR-compliant consent practices (clear affirmative opt-in, consent date recording, easy withdrawal) is modest compared to the operational complexity of maintaining separate consent standards for different jurisdictions within a single list.

The Unsubscribe Requirement: CAN-SPAM vs GDPR

Both frameworks require an unsubscribe mechanism, but with different specifics. CAN-SPAM requires a "clear and conspicuous" opt-out that is "reasonably identifiable as an opt-out mechanism." It must function for at least 30 days after the commercial email is sent. The opt-out must be processed within 10 business days — CAN-SPAM has a legally defined processing deadline that GDPR does not replicate in the same way.

GDPR requires that consent withdrawal (unsubscribe) be "as easy as giving consent." If the consent was collected through a single checkbox on a web form, the unsubscribe process must be similarly simple — a single click, not a multi-step preference centre with confirmation emails. GDPR does not specify a processing deadline for consent withdrawal, but the general principle that processing should stop when the lawful basis is withdrawn implies immediacy rather than the 10-day window CAN-SPAM permits.

The infrastructure implication: real-time unsubscribe processing — where the global suppression list is updated within seconds of an unsubscribe event — satisfies both CAN-SPAM's 10-day requirement (well within it) and GDPR's implied immediacy standard. This is another case where applying the stricter standard (GDPR's effective immediacy) eliminates the compliance risk from the less strict framework (CAN-SPAM's 10-day window) simultaneously.

Suppression List Architecture for Dual Compliance

Both CAN-SPAM and GDPR require maintaining records of unsubscribe/opt-out events and honouring them. The suppression list architecture for dual compliance: a single global suppression database that stores the email address, the date of the opt-out, the mechanism (unsubscribe link, preference centre, GDPR erasure request, FBL complaint), and the programme from which the opt-out was received. This single database is checked before every send, across all sending infrastructure, ensuring that opted-out contacts receive no further marketing email regardless of which system they opted out through.

The suppression record retention question differs between frameworks. CAN-SPAM implicitly requires retaining the opt-out record — a sender who does not retain the record cannot demonstrate CAN-SPAM compliance if challenged. GDPR's right to erasure requires deleting personal data on request, which creates tension with the CAN-SPAM implicit retention requirement. The resolution: retain a minimal record on the suppression list (email address, opt-out date, reason — no other personal data) under the legitimate interest of preventing re-sending to someone who has opted out. This minimal record satisfies CAN-SPAM's implicit compliance documentation requirement while complying with GDPR's data minimisation principle by limiting the retained data to the minimum necessary for the suppression purpose.

The suppression list must be persistent across infrastructure changes. When migrating to a new sending platform, the suppression list transfers to the new infrastructure before any sends commence. Suppression data is as important to transfer in an infrastructure migration as the active contact list itself — a new platform that does not have the suppression list will send to opted-out contacts from the first campaign, creating immediate CAN-SPAM and GDPR violations.

CAN-SPAM's Physical Address Requirement

CAN-SPAM requires that every commercial email include a valid physical postal address of the sender. This must be in the message body — typically in the footer — not just in the email headers. The address must be a current address at which postal mail can be received: a street address, a registered PO box, or a private mailbox registered under applicable postal regulations.

GDPR requires that the privacy notice identify the data controller's identity and contact details, which typically includes an address. The physical address in the email footer can satisfy both requirements if it is included consistently and correctly. The footer should identify the legal entity operating the email programme (not just a brand name), the physical address, and optionally the data protection officer's contact information if one is required under GDPR.

For international senders without a US physical address, a registered agent address in the US can satisfy CAN-SPAM's requirement. For EU-based companies sending to US recipients, the company's EU address satisfies the CAN-SPAM physical address requirement — CAN-SPAM does not require a US address, only a valid, accurate physical address. Including the address in the email template's footer HTML, rather than in individual campaign content, ensures consistency across all campaigns without requiring operators to remember to include it manually in each send.

Practical Compliance Architecture for Global Senders

The practical compliance architecture that satisfies both CAN-SPAM and GDPR for a programme sending to US and EU audiences: (1) collect affirmative consent at signup with a clear, unchecked opt-in checkbox and record the consent date, mechanism, and IP address; (2) maintain a global suppression database checked before every send; (3) process unsubscribes in real time and retain a minimal suppression record; (4) include a visible unsubscribe link and physical address in every commercial email; (5) document the lawful basis for each contact's processing; (6) maintain a data processing agreement with every system that processes contact data; (7) respond to data subject rights requests within one month.

These seven elements produce a compliance architecture that satisfies GDPR (the stricter framework) and inherently satisfies CAN-SPAM (the less strict framework) simultaneously. The incremental cost of GDPR compliance over CAN-SPAM-only compliance for a programme that implements this architecture from the outset is modest — primarily the consent documentation and data subject rights response capability. Programmes that implement only CAN-SPAM requirements and later need to add GDPR compliance for European audiences face a more significant retroactive compliance effort: auditing the consent basis for all existing EU-resident contacts, implementing the data subject rights infrastructure, and establishing DPAs with all processors.

The infrastructure operator's role in compliance is enabling the technical capabilities that compliance requires — not determining the legal compliance posture, which is the legal team's responsibility. The infrastructure must be capable of: real-time unsubscribe processing to the global suppression list, consent date and mechanism recording per contact, data export for right-of-access requests, data deletion for right-to-erasure requests, and DPA compliance with the infrastructure provider. These technical capabilities are the infrastructure operator's contribution to the organisation's compliance programme.

ePrivacy Directive: The Third Framework

EU senders must also consider the ePrivacy Directive (2002/58/EC, amended 2009), which governs electronic communications privacy and includes specific rules for unsolicited commercial communications — the "spam" provisions of EU law. The ePrivacy Directive is implemented at the national level, meaning each EU member state has its own national law implementing it, with some variation in scope and enforcement between countries.

The ePrivacy Directive's email marketing rule: commercial email to natural persons requires prior consent (opt-in). The "soft opt-in" exception allows marketing to existing customers about similar products or services, using the email address provided in the course of the prior transaction, provided the customer is given a clear opportunity to opt out. This soft opt-in exception aligns with GDPR's legitimate interest basis for existing customer email marketing, though it is technically a separate legal basis under ePrivacy that predates GDPR.

The ePrivacy Directive is expected to be replaced by the ePrivacy Regulation, which has been under negotiation since 2017 and has not yet been finalised. When the ePrivacy Regulation is eventually adopted, it will become directly applicable EU law (like GDPR) rather than a directive that member states implement nationally. For now, the ePrivacy Directive remains in force, and senders must comply with the national law implementing it in each EU country they send to, in addition to GDPR.

In practice, for most email programmes that have already implemented GDPR-compliant consent practices, the ePrivacy Directive requirements are simultaneously satisfied — consent for electronic marketing communications is the requirement of both frameworks. The ePrivacy layer adds potential national-level variation that is worth reviewing for major EU markets (UK, Germany, France, Netherlands), but generally does not require separate consent collection practices from GDPR-compliant programmes.

Tracking Pixels and Cookie-Like Technologies Under GDPR and ePrivacy

Open tracking pixels — the 1×1 pixel images embedded in marketing emails that record when a recipient opens the message — are processing activities that require consideration under both GDPR and the ePrivacy Directive. The pixel retrieval reveals that the recipient has opened the message, and records the time, approximate location (from IP address), email client, and device type. This is personal data processing that requires a lawful basis under GDPR.

For email open tracking, the most commonly relied-upon lawful basis is legitimate interest — the sender has a legitimate interest in understanding whether their communications are reaching and being read by recipients, and this interest outweighs the privacy impact of the tracking in most cases. However, this legitimate interest must be disclosed in the privacy policy, and recipients must be given information about the tracking and the means to object to it.

For a programme that is providing appropriate transparency about tracking in its privacy policy and giving recipients the means to opt out of tracking (typically through the preference centre), the tracking practice is likely compliant under the legitimate interest basis. Programmes that have not disclosed tracking in their privacy policy or that have not provided any means to object to tracking have a compliance gap that should be addressed as part of a full privacy review.

Click tracking — recording when a recipient clicks a link in an email — is a more intentional action than an open and is generally considered to carry a stronger legitimate interest justification, since it directly reflects the recipient's deliberate interaction with the email content. The same transparency and opt-out considerations apply, but the consent bar for click tracking is generally considered lower than for open tracking because the tracking is directly tied to an action the recipient has chosen to take.

The UK Post-Brexit Regulatory Landscape

Following the UK's departure from the European Union, the UK has implemented its own version of GDPR — the UK GDPR — which is substantively similar to the EU GDPR but is enforced by the UK's Information Commissioner's Office (ICO) rather than EU member state data protection authorities. UK residents' personal data is subject to UK GDPR, not EU GDPR, though the requirements are almost identical in practice.

For email programmes that include UK recipients, the compliance architecture that satisfies EU GDPR simultaneously satisfies UK GDPR with no material changes required. The ICO has published detailed guidance on email marketing compliance that is closely aligned with EU GDPR guidance and the ePrivacy Directive's UK equivalent (the Privacy and Electronic Communications Regulations, PECR). The practical compliance requirements for UK recipients are the same as for EU recipients: consent-based marketing email, easy unsubscribe, data subject rights support, and processing within the UK or an adequate country.

The data transfer question for UK recipients differs from EU recipients post-Brexit. The EU has issued an adequacy decision for the UK, meaning data transfers from the EU to the UK are permitted without additional safeguards. Transfers from the UK to the EU are permitted under UK GDPR's adequacy framework. For email programmes with EU-based infrastructure sending to UK recipients, or UK-based infrastructure sending to EU recipients, these adequacy decisions mean that no additional transfer mechanisms are required in most cases as of 2019.

Documentation as the Foundation of Compliance

Both CAN-SPAM and GDPR operate differently in terms of documentation requirements. CAN-SPAM does not explicitly require documentation of compliance — it is an enforcement-based framework where violations are actionable by regulators if they occur. GDPR requires affirmative documentation of compliance — the Record of Processing Activities, the consent records, the DPAs, and the legitimate interest balancing tests must exist and be available to regulators on request.

The GDPR documentation requirement is the compliance work that many organisations underestimate. Being compliant in practice is not enough — demonstrating compliance with evidence is the legal standard. An organisation that maintains appropriate consent practices but has no consent records cannot demonstrate compliance when a data subject or regulator challenges a specific processing activity. Building the documentation alongside the technical compliance measures — creating the ROPA when implementing consent collection, creating the DPA when engaging a new processor, creating the legitimate interest assessment when relying on it — ensures that the compliance posture is documentable, not just operational.

For email infrastructure operators, the documentation contribution is: providing clients with accurate descriptions of the technical processing activities (where data is stored, what security measures are applied, what sub-processors are used) that clients need to complete their own compliance documentation. A managed infrastructure provider that can supply this information clearly and promptly when clients need it for their ROPA, privacy policy, or DPA completion is providing compliance-supporting value beyond the technical infrastructure service itself.

The dual compliance architecture described in this note — applying GDPR-compliant consent practices globally, maintaining a real-time-processed global suppression list, retaining minimal suppression records under legitimate interest, and disclosing all processing activities in an accessible privacy policy — satisfies both CAN-SPAM and GDPR simultaneously without requiring separate systems for each jurisdiction. This "build to the stricter standard" approach is more operationally efficient than maintaining jurisdiction-specific compliance programmes and produces a more defensible compliance posture when regulators inquire. The infrastructure investment required is the real-time suppression processing, consent record storage, and data subject rights tooling — each of which also provides operational deliverability benefits (real-time suppression improves bounce rates and complaint management; consent documentation supports dispute resolution; rights request tooling demonstrates professional data governance). Compliance and deliverability infrastructure, built correctly, reinforce rather than conflict with each other.

Email compliance is not a static achievement — both CAN-SPAM and GDPR continue to evolve through regulatory guidance, court decisions, and enforcement actions that refine the interpretation of existing requirements. Staying current with regulatory developments in the jurisdictions where an email programme operates is the ongoing compliance responsibility that supplements the technical infrastructure implementation described here. The infrastructure enables compliance; the operational discipline and legal awareness maintain it over time.

Regulatory compliance in email marketing, handled correctly, is less burdensome than it appears to organisations encountering it for the first time. The requirements of both frameworks — consent documentation, unsubscribe processing, data subject rights, processor agreements — align with the operational practices that well-run email programmes implement for deliverability reasons regardless of regulatory requirements. The organisation that runs a clean, consent-based email programme with real-time unsubscribe processing and careful list management is largely compliant with both frameworks by virtue of good operational practice, requiring only the documentation layer to make the compliance formally demonstrable.