Most email programs start clean. A signup form collects an address. A welcome series goes out. A newsletter follows on a schedule everyone agrees on. Someone writes “we have consent” in a project doc, and for a while that sentence is true.
Then the company adds SMS to catch people who don’t open email. Marketing buys a list from a trade show. A support tool starts sending transactional texts that quietly carry promotional lines. An acquisition brings in a contact database built under a different country’s rules. Someone in growth starts A/B testing subject lines that never mention what list the recipient is actually on. The “we have consent” sentence stops being true for a growing share of the list, and nobody can confidently say which contacts were opted in, under which law, for which channel.
Email compliance doesn’t run out of contacts to send to. It runs out of people who can explain why each contact is on the list in the first place. This guide works through CAN-SPAM, GDPR, and SMS law as a decision sequence: what actually requires consent, what just requires disclosure, how the three regimes interact without contradicting each other, and how the program stays defensible after launch, not just on day one.
TL;DR
| • CAN-SPAM (US email) runs on opt-out: identify ads, give a real address, honor unsubscribes within 10 business days. GDPR (EU/UK) generally requires opt-in consent, documented at the point of capture. The TCPA (US SMS) requires prior express written consent and carries statutory damages of $500 to $1,500 per violation.• Consent doesn’t transfer across channels. An email opt-in doesn’t cover SMS, and vice versa.• Keep 3 records separate: consent (the legal basis), preference (what a contact actually wants), and suppression (who must not be contacted). Collapsing them into one field is what breaks a program during an audit.• Not every new send needs fresh consent. Transactional messages, footer updates, and sends to an already-consented list usually don’t. A new channel, a new jurisdiction, or a purchased list usually does.• Purchased lists, CRM integrations, contests, and chatbots generate contacts nobody explicitly reviewed. Their consent status traces back to how they entered the list, not where they currently sit.• Automation and AI personalization send based on whatever consent and suppression data they’re given. They don’t create new consent, so a stale record still creates exposure at higher volume.• Review consent records on a regular cadence, often quarterly or after any list merge or acquisition, rather than treating consent as a one-time setup step. |
Why the Old “One Consent Checkbox” Model Breaks as the List Grows
Early-stage email programs often run on a single assumption: if someone gave an email address once, that covers everything sent to it afterward. It works at launch. It breaks as the list grows across channels, countries, and acquisition sources, because a single checkbox can’t carry the weight of 3 different legal standards at once.
CAN-SPAM in the US runs on an opt-out model: you can email someone without prior consent as long as you identify the message as an ad, give a working physical address, and honor an unsubscribe request within 10 business days. GDPR in the EU runs on an opt-in model for most marketing: you generally need a clear, affirmative action before you send anything promotional, and you have to be able to show when and how that consent was collected. SMS marketing in the US falls under the TCPA, which requires prior express written consent before an autodialed or pre-recorded marketing text goes out, a stricter bar than either CAN-SPAM or most GDPR-based email consent.
Old blanket consent model vs modern layered consent model
| Blanket model | Layered model |
| One checkbox covers every channel | Consent recorded per channel |
| One consent record per contact | Consent record tied to jurisdiction and source |
| Unsubscribe removes from everything | Preferences can be topic- and channel-specific |
| Legal basis assumed, not documented | Legal basis documented at capture |
| Hard to defend in an audit | Each send traceable to a specific consent event |
Layered doesn’t mean complicated
This distinction gets misread often: “layered consent” sounds like it means more paperwork for every signup form. It doesn’t. A tenant, sorry, a contact list, where every signup captures channel, source, and timestamp isn’t complicated. It’s just recorded properly. What actually creates complexity is the opposite: a list where consent was never documented cleanly, so every audit becomes an exercise in reconstructing what probably happened 2 years ago from partial data.
The practical benefit shows up the first time a regulator, a platform, or a customer asks for proof. A blanket model has no record to point to beyond “they’re on the list.” A layered model can show the exact form, the exact date, and the exact language a contact agreed to. That difference is what holds up when a complaint escalates instead of getting resolved with an apology and an unsubscribe.
Understand the Four Layers of Email and SMS Compliance Before Building a Program
Before deciding what needs a new consent flow, it helps to separate 4 layers that make up a working compliance model. Treating every new requirement as “another consent form” is one of the most common planning mistakes.
• Legal basis layer. Why you’re allowed to contact someone at all: opt-in consent, an existing business relationship, or a legitimate-interest basis under GDPR. This is the foundation everything else sits on.
• Channel layer. Email, SMS, and push each carry different rules. Consent for one doesn’t transfer to another, even for the same contact.
• List and segment layer. The specific list or segment a contact sits in, often tied to a jurisdiction, product line, or acquisition source with its own rules.
• Message layer. The individual send: subject line, footer, opt-out mechanics, and required disclosures for that specific message.
Not every new requirement needs a new consent flow. A new campaign to an existing, properly consented list usually just needs the message layer handled correctly: a working unsubscribe link, an accurate sender identity, honest subject lines. A new legal basis, like starting to text a list that only ever consented to email, needs the channel layer addressed from scratch.
Decide What Genuinely Requires Explicit Opt-in Consent
Not everything you send needs a fresh opt-in. A working compliance model treats explicit consent as justified when the message is promotional, the channel demands it, or the jurisdiction requires it.
Does this message need explicit opt-in consent?
1. Is the message promotional or marketing content, not a transaction confirmation?
2. Is the channel SMS, where the TCPA requires prior express written consent?
3. Is any recipient in the EU or UK, where GDPR generally requires opt-in for marketing?
4. Would a reasonable recipient be surprised to receive this message?
5. Is there no existing, documented consent record that already covers this exact use?
If most of these are true, treat the send as requiring fresh, documented opt-in before it goes out.
When requiring fresh opt-in creates unnecessary friction
A password reset email, a shipping confirmation, or a single receipt doesn’t need marketing consent. These are transactional messages triggered by an action the recipient just took, and CAN-SPAM, GDPR, and the TCPA all treat transactional content differently from promotional content. Forcing every automated message through a marketing opt-in flow adds friction without adding legal protection, and it usually just means real transactional emails get missed because they’re buried in a consent queue built for a different purpose.
The common failure here runs the other way, though: a receipt email with a promotional banner at the bottom stops being purely transactional the moment that banner exists. If the primary purpose of the message shifts toward marketing, the marketing rules apply to the whole message, not just the banner.
Do Not Rely on One Magic Rule Across CAN-SPAM, GDPR, and the TCPA
CAN-SPAM’s guidance is specific about mechanics: honor opt-outs within 10 business days, don’t use deceptive subject lines, include a valid postal address. GDPR is specific about legal basis and documentation, not about counting business days. The TCPA is specific about SMS consent language and carries statutory damages per violation that make it the costliest regime to get wrong per message, even though it governs the smallest share of most companies’ total send volume. None of these numbers substitutes for the others. Treat each as a design input specific to its own regime, not a template you can apply everywhere once and forget.
Decide Whether the Next Requirement Needs a New Consent Flow, a Disclosure Update, or Just a Footer Change
This is the most consequential decision in an email and SMS compliance program, and the one most often skipped. A sound compliance model starts with a simple test: a new consent flow is justified when the legal basis, channel, or jurisdiction genuinely changes. If only the message content differs, a footer update or a disclosure line is usually the right answer.
Requirement decision matrix
| Requirement | Footer or disclosure update | Consent record update | New consent flow |
| New promotional subject line | Usually sufficient | No | Unnecessary |
| Adding a new product to an existing newsletter | Sometimes | Sometimes | Usually unnecessary |
| Starting to text an email-only list | No | No | Required |
| Expanding a US list to include EU contacts | No | Required | Often required |
| Contact acquired through a purchased list | No | No | Required before first send |
| Changing the sender name or address | Required | No | Unnecessary |
Signs your consent model is too loose
A single “marketing opt-in” flag covering email, SMS, and every product line at once, purchased lists merged in without a fresh consent event, unsubscribes that only suppress one channel while others keep sending, and a legal team that can’t answer “when did this contact consent, and to what” are all signs the model was drawn too wide. Tightening it isn’t bureaucracy. It’s restoring a record you can actually defend.
Signs your consent model is too strict
A separate opt-in form for every product variant, re-consenting existing customers who already have a clear legal basis, blocking transactional messages behind a marketing gate, and a support team fielding constant complaints about being unable to receive a receipt they clearly requested are signs of the opposite failure. Each of those usually just needs a cleaner legal-basis record, not another form.
Give Email and SMS Different Compliance Jobs
Email and SMS aren’t interchangeable channels wearing different formats. They solve different problems, and treating their consent requirements as equivalent is a common source of TCPA exposure.
Broad reach, lower per-message risk
Opt-out model viable under CAN-SPAM
Transactional and marketing can share infrastructure with clear separation
Statutory penalties tied to specific violations, not blanket damages
SMS
Higher per-message legal exposure
Opt-in model required under the TCPA
Transactional and marketing need clearer separation, including separate short codes where volume justifies it
Statutory damages of $500 to $1,500 per violation under the TCPA, regardless of actual harm
A newsletter is a useful example. A weekly product newsletter sent to an email list with documented opt-in, or a valid opt-out-model basis under CAN-SPAM, is low-risk if the footer and sender identity are handled correctly. The same content sent as an SMS blast to a list that only ever gave an email address is a TCPA violation waiting to surface, even though it’s the identical message.
The mistake to avoid is picking a consent standard based on which one feels more convenient to implement. SMS isn’t automatically fine just because a phone number was collected somewhere in the funnel, and email isn’t automatically low-risk just because CAN-SPAM’s bar is lower than GDPR’s. The standard should follow the channel and the jurisdiction, not the path of least implementation effort.
Choose the Primary Compliance Model From Where Your Customers Are, Not Your Product Roadmap
There’s no single framework that fits every company’s contact base. Regulatory guidance from the FTC, the ICO, and the FCC consistently points toward building compliance around where the recipient actually is and what they actually agreed to, not a template borrowed from a company in a different market.
Four compliance models compared
| Model | Best when | Main risk |
| Jurisdiction-based | Contacts span the US, EU, and other regions with different baseline rules | Duplicated logic per region |
| Channel-based | Email and SMS run through genuinely separate teams or tools | Inconsistent contact-level view |
| Consent-type based | Transactional and promotional content are cleanly separated already | Cross-functional coordination overhead |
| Hybrid | No single axis covers the whole contact base | Over-engineering the relationships |
A contact can have one primary consent record but multiple channel permissions layered on top of it. Because a single customer might be opted into email marketing but not SMS, or opted into transactional SMS but not promotional SMS, the program has to track the primary legal basis separately from each channel’s specific permission. Not every contact can be assumed to carry the same permission across every channel just because they’re a known customer.
Keep Consent, Preference, and Suppression as Three Separate Decisions
This is the single most common misconception in email and SMS compliance programs, and it’s worth stating plainly: capturing consent changes less than most teams assume. Three records operate independently, and collapsing them into one field is what breaks a program during an audit.
Consent
The legal basis record: what a contact agreed to, when, through what mechanism, and under which regime. This answers “were we allowed to send this.”
Preference
What channels and topics a contact actually wants, separate from whether they’re legally reachable at all. A contact can be legally opted in and still prefer email over SMS, or weekly over daily.
Suppression
The record of who must not be contacted, regardless of any other field. An unsubscribe, a bounce, or a complaint creates a suppression entry that overrides consent and preference every time.
A worked example: the newsletter program
Picture a weekly newsletter with three related lists: a general marketing list, a product-updates list, and a webinar-invite list. A contact can hold a single consent record covering promotional email generally, while their preference record limits them to product updates only, skipping the general newsletter. If that same contact unsubscribes from the webinar list specifically, the suppression record blocks webinar invites while consent and preference for the other two lists stay untouched. Consent is broad. Preference and suppression are specific, and they don’t always move together.
The reverse pattern shows up just as often. A contact might have a valid consent record for SMS but a preference set to “email only,” meaning the legal basis to text them exists but the send shouldn’t happen anyway. Legal permission and actual practice are answering different questions.
Use Metadata to Make the Compliance Model Work Across Regimes
Consent records answer whether you can contact someone. They don’t answer how consistently that record gets applied across every list, form, and integration feeding the program. That’s a metadata problem, and skipping it means a technically valid consent model can still produce inconsistent, unauditable sends underneath it.
A company can have a legally sound consent policy and still end up with 5 different date formats, 3 different ways of recording “how consent was collected,” and no consistent field for jurisdiction across its signup forms, its CRM, and its SMS platform. An audit becomes a data-reconciliation project instead of a records lookup, regardless of how sound the underlying policy is.
Shared consent record fields
| Field | Purpose |
| Consent source | Records the specific form, event, or integration where consent was captured |
| Consent date and timestamp | Establishes when the legal basis began |
| Consent language version | Ties the record to the exact disclosure text shown at the time |
| Jurisdiction | Determines which regime’s rules apply to this contact |
| Channel | Distinguishes email, SMS, and any other contact method |
| Opt-out date | Marks when suppression began, if applicable |
| IP address or device signal | Supports proof of the consent event itself |
Standardize what must travel across every list
Not every field needs to be identical across every list and integration. Only the fields that matter for defensibility, like consent source, date, and jurisdiction, need to be standardized centrally. Everything else, like which specific product a contact clicked on, can stay list-specific without weakening the compliance record.
Bring Third-party and Automatically Generated Contacts Into the Same Compliance Model
Most compliance documentation describes the contacts a company deliberately collected through its own forms. It rarely describes the contacts that entered the database through integrations, contests, chatbots, or purchased lists. According to FTC guidance on CAN-SPAM and general GDPR consent principles, the actual contact base is almost always broader and messier than the signup-form diagram suggests.
A CRM integration pulling contacts from a sales tool, a contest entry form run by a marketing agency, a chatbot that captures a phone number mid-conversation, and a list purchased from a trade show can all generate contacts nobody on the compliance team explicitly reviewed. Governance built only around the primary signup form misses most of the actual risk sitting in the database.
Consent decisions should trace back to how a contact actually entered the list, not just where they currently sit. A contact pulled in through a sales CRM integration inherits whatever consent, or lack of it, was actually captured at that original point of entry, not a blanket assumption that anything in the marketing database is fair game. Reviewing new integration sources needs to account for that inherited history, not just the contacts added directly through the primary opt-in form.
The practical implication is that a compliance inventory built only from the main signup form’s records will always undercount the real exposure. A complete compliance model requires cross-referencing every integration, every purchased or transferred list, and every automatically generated contact against the same consent and jurisdiction rules applied to contacts collected directly.
Standardize Consent Capture Before the List Grows Faster Than the Program
A well-designed consent model degrades quickly without a repeatable capture process behind it. A good process covers more than the signup form itself: source, jurisdiction, channel, disclosure language, and record ownership all need answers before a new list goes live.
Contact request to activation flow
6. Request. A team identifies a new list or integration need and submits a request rather than adding a data source directly.
7. Validate need. Confirm whether the new contacts require fresh consent or already carry a valid basis from their origin.
8. Select channel and jurisdiction. Determine which regime applies based on where the contacts actually are.
9. Assign record owner. Require a named owner accountable for that list’s consent records.
10. Apply disclosure language. Match the consent language to the channel and jurisdiction, not a generic template.
11. Select legal basis. Determine consent, legitimate interest, or opt-out eligibility using the earlier decision tree, not convenience.
12. Apply suppression rules. Confirm the list checks against the existing global suppression record before any first send.
13.Configure lifecycle. Set a review cadence and record the expected retention period before the list goes active.
Treat new integration sources as a compliance review event
Attaching a review step to every new data integration, not just every new form, turns list growth into a deliberate governance step instead of a background process nobody tracks. A new CRM sync or purchased list should trigger the same review a new signup form would, not skip it because the contacts arrived through a side door.
Control who may add contacts to sensitive lists
List-creation rights and consent-record rights are separate permissions. Restricting which teams may merge new sources into regulated lists, particularly SMS lists given the TCPA’s per-violation damages, keeps a well-meaning integration from quietly creating legal exposure nobody reviewed.
Design the Exit Path Before You Design Another New List
Most compliance documentation describes how contacts get added. It rarely describes what happens when a product sunsets, a list goes stale, or a contact’s consent ages out. A model that only adds contacts and never retires them doesn’t hold up, no matter how clean the intake process looks on day one.
This gap is easy to overlook because nobody notices it during setup. It becomes visible years later, when a third of the list hasn’t engaged in 2 years, consent language on record predates the current disclosure standard, and nobody remaining on the team has the context to decide what should happen to those contacts.
Consent record lifecycle
• Proposed. A new list or integration request is submitted and validated against the consent decision matrix.
• Active. The list is live, consented, and receiving regular sends.
• Review. A scheduled or triggered review checks engagement, consent age, and continued business purpose.
• Keep, refresh, suppress, or delete. Based on the review, the list continues as-is, gets a re-permission campaign, moves to suppression, or is deleted entirely.
Business and Regulatory Changes Should Update Records, Not Force a Rebuild
One real advantage of a well-structured consent record shows up here. When a regulation changes, like an update to TCPA rules on revocation language, or a company expands into a new country, the existing records can usually be updated in place rather than rebuilt from scratch. The legal basis field changes; the contact and its history don’t have to be recreated.
Ownership Capacity Is a Real Scale Limit
A contact list doesn’t genuinely scale to millions of records unless the organization can keep those records meaningfully owned and reviewed. This is where compliance program design and actual governance capacity meet directly. Regulatory enforcement patterns from the FTC and state attorneys general consistently target companies where nobody could produce a clear consent record on request, not companies that made an occasional honest mistake. Lists without an accountable owner are the most common failure mode in large contact databases.
Design for Automation and Deliverability at the Same Time
If sends are automated and personalized by a marketing platform, does manual compliance review still matter? Yes, and arguably more than before. Automation compensates for some manual effort. It doesn’t fix a missing consent record, a stale suppression list, or a mismatched jurisdiction field. It just sends whatever the underlying data says to send, faster and to more people at once.
How compliance gaps typically surface
| Signal | What it usually means |
| Rising unsubscribe rate on a specific list | Consent or preference mismatch at signup |
| Spam complaints clustered by source | A specific integration or list source lacks proper consent |
| Deliverability drop after a list merge | Suppression records weren’t applied before the merge |
| Legal inquiry naming a specific message | A record-keeping gap, not necessarily a policy gap |
| SMS opt-out volume spike | Consent language or frequency doesn’t match what was disclosed |
Automated platforms respect the suppression and consent flags they’re given. They don’t create new consent on their own. The real risk isn’t that automation sends to people who were never on a list, it’s that a stale or mismatched record makes an otherwise-consented contact look compliant when the underlying documentation wouldn’t hold up. Programs that treat automation as a reason to skip periodic record review usually find the opposite happens: once volume increases, gaps in consent, jurisdiction, and suppression data surface as complaints and penalties instead of staying invisible in a rarely audited list.
This is also where AI-driven personalization tools deserve a specific mention. A platform that dynamically selects subject lines, send times, or content blocks based on engagement data is still bound by whatever consent and channel permissions sit behind each contact. Personalization can make a message more relevant. It can’t make a message legal if the underlying consent record wasn’t valid to begin with, and teams evaluating a new AI send tool should ask exactly which consent and suppression fields it reads before connecting it to a live list.
Turn the Compliance Policy Into an Operating Program
A policy document describes the rules. An operating compliance program keeps those rules true 2 years and 3 regulatory updates later. The difference is a repeatable review cycle, not a one-time project.
Every step in this guide already appeared earlier in isolation. What changes here is treating them as one continuous cycle rather than a sequence of decisions made once during a single compliance project.
Eight-step operating model
14. Inventory. Catalog every list, integration, consent source, and suppression record across the actual contact base, not just the primary signup form.
15. Identify jurisdictions. Determine which regimes actually apply based on where contacts are, not where the company is headquartered.
16. Define consent boundaries. Apply the requirement decision matrix to decide what genuinely needs fresh opt-in.
17. Design channel relationships. Separate email and SMS consent and suppression logic clearly.
18.Standardize information. Define shared consent fields, disclosure language, and record formats.
19. Standardize capture. Control what data sources feed the list, and under what review.
20. Operate lifecycle. Review consent age, engagement, and continued business need on a schedule.
21. Measure deliverability and complaints. Track unsubscribe rates, spam complaints, and opt-out volume to catch gaps before they become penalties.
The goal isn’t a perfect policy document. It’s a program the company can still explain and defend after the next regulatory update, the next acquisition, and the next list merge.
Email and SMS Compliance Faqs
FAQ 1: What is the difference between CAN-SPAM and GDPR for email marketing?
CAN-SPAM runs on an opt-out model: you can email someone without prior consent as long as you identify the message as an ad, provide a valid address, and honor opt-outs promptly. GDPR generally requires opt-in consent before sending marketing email to anyone in the EU or UK, along with a documented record of that consent.
FAQ 2: Do I need separate consent for email and SMS?
Yes. Consent for one channel doesn’t transfer to another. SMS marketing in the US falls under the TCPA, which requires prior express written consent, a stricter standard than CAN-SPAM’s opt-out model for email.
FAQ 3: What counts as a transactional message versus a marketing message?
A transactional message is triggered by an action the recipient just took, like a purchase or a password reset, and generally isn’t subject to marketing consent rules. If a transactional message includes substantial promotional content, regulators may treat the whole message as marketing.
FAQ 4: How long do I have to honor an unsubscribe request under CAN-SPAM?
CAN-SPAM requires honoring an opt-out request within 10 business days, and you can’t charge a fee, require additional personal information beyond an email address, or make the process unnecessarily difficult.
FAQ 5: What are the penalties for TCPA violations?
Statutory damages range from $500 to $1,500 per violation, and violations are typically counted per message, not per campaign, which makes SMS the highest per-message risk channel in most compliance programs.
FAQ 6: Does GDPR apply to companies outside the EU?
Yes, if the company processes personal data of individuals located in the EU or UK, regardless of where the company itself is based. Jurisdiction follows the recipient’s location, not the sender’s.
FAQ 7: Can I use a purchased or third-party list for email marketing?
It depends on how the list was built and what consent, if any, was captured at the point of collection. A purchased list rarely carries valid consent for GDPR purposes, and using one for SMS without prior express written consent creates direct TCPA exposure.
FAQ 8: Should marketing and transactional messages use separate infrastructure?
Not always, but the consent and suppression logic behind them should be clearly separated even when the sending infrastructure is shared. Mixing the two without a clear boundary is a common source of compliance gaps.
FAQ 9: Does automation reduce compliance risk?
No. Automated platforms send based on whatever consent and suppression data they’re given. They don’t create new consent, verify jurisdiction, or catch a stale record on their own. Manual review of the underlying data still matters.
FAQ 10: How often should a company review its consent records?
There’s no universal number, but a regular review cadence, often quarterly or after any major list merge or acquisition, catches consent-age issues, jurisdiction mismatches, and suppression gaps before they surface as complaints or regulatory inquiries.
