Minors and Email Marketing — COPPA, the UK Children's Code, and GDPR Article 8
When collecting a child's email address triggers US COPPA (under-13 rule, verifiable parental consent, the FTC six-step plan), the UK Age Appropriate Design Code's 15 standards, GDPR Article 8 age thresholds, and what all of this means for ESP signup forms and age gates.
An email address is, in every children's-privacy regime, personal information about the child — collecting one from a minor is the act that triggers the law, before a single message is sent. This article covers the three frameworks an ESP and its customers are most likely to hit: the US COPPA Rule (under 13), the UK Children's Code (under 18), and GDPR Article 8 consent ages (13–16 by member state). General consent mechanics are in Consent Methods; adult-marketing law is in CAN-SPAM, CASL, and UK PECR.
COPPA (United States) — the under-13 rule
The Children's Online Privacy Protection Act (1998) and the FTC's COPPA Rule (16 C.F.R. Part 312; effective April 21, 2000; amended effective July 1, 2013; amended again on April 22, 2025 — check the revised Rule for current text) put parents in control of what is collected online from children under 13. Enforcement is by the FTC (plus state AGs and sector regulators); civil penalties run up to $53,088 per violation, assessed on factors including egregiousness, prior violations, number of children, type of information, third-party sharing, and company size — some cases settle with no penalty, others in the millions.
COPPA applies if any of these is true:
- the site/service is directed to children under 13 and collects personal information from them;
- it is directed to children under 13 and lets others collect personal information from them (ad networks, plug-ins — the operator is liable for third-party collection on its property);
- it is a general-audience service with actual knowledge it is collecting personal information from a child under 13; or
- it runs an ad network/plug-in with actual knowledge it collects personal information directly from users of a child-directed service.
"Online service" is broad: mobile apps, gaming platforms, plug-ins, ad networks, VoIP, connected toys/IoT, smart speakers. Foreign services directed to US children (or knowingly collecting from them) are covered; US services collecting from foreign children are too. Nonprofits outside Section 5 of the FTC Act are generally exempt. Congress deliberately stopped at 13; teens are outside COPPA.
"Personal information" includes the email address
The Rule's list: first and last name; physical address (street + city/town); online contact information — an email address or any identifier permitting direct contact (IM/VoIP/video-chat identifiers, mobile numbers); a screen/user name that functions as online contact information; telephone number; government-issued identifiers (SSN, state ID, birth certificate, passport); persistent identifiers (cookie ID, IP address, device serial/unique device ID); photo/video/audio containing a child's image or voice; geolocation to street + city/town precision; biometric identifiers; and any child/parent information combined with one of these.
"Collect" includes requesting or prompting submission even if optional, allowing public posting, and passive tracking.
When collecting a child's email address triggers COPPA — and when it doesn't
The email-relevant FAQ points, condensed:
| Scenario | COPPA outcome |
|---|---|
| Newsletter or other repeated email contact the child requested | Allowed under the multiple-contact exception (§ 312.5(c)(4)): collect the child's and a parent's online contact information, give the parent direct notice and an opportunity to opt out before ongoing contact; use for no other purpose, no disclosure, no combining with other data. Notice that bounces = no "reasonable efforts" = no exception |
| One-time response to a child's specific request (answer a question, "Ask the Author") | One-time-contact exception (§ 312.5(c)(3)): respond once, then promptly delete the address; no re-contact, no disclosure, no other use. Choosing not to respond still requires immediate deletion |
| Contest entry | One-time exception works only if you collect only online contact information and contact the child once (win/lose), then delete. Expecting multiple contacts → multiple-contact exception (parent notice + opt-out). Collecting a mailing address for a prize → full parental notice + verifiable consent, or route the prize through the parent's contact information |
| Password reminder at registration | Multiple-contact exception (notice + parental opt-out) if the address is retained in retrievable form; no notice needed if you collect nothing else, the child can't disclose personal information on the service, and you immediately and permanently hash the address so it cannot be reconstructed or used to contact the child |
| Collecting the parent's online contact information to seek consent | Permitted (§ 312.5(c)(1)); if consent isn't obtained within a reasonable time, delete it. A mobile phone number is not "online contact information" and can't be collected from the child to initiate consent (though a Rule exception allows collecting a mobile number used solely to text the parent to seek consent) |
| E-cards / forward-to-a-friend on a child-directed service | One-time exception only if the system collects the recipient's email (plus at most first names), sends immediately, deletes immediately, and allows no free-text fields; delayed sending parallels the multiple-contact exception (parent notice + opt-out first). Any opportunity to reveal other personal information → full verifiable parental consent (email plus not permitted) |
| Push notifications from a child-directed app | The device token is online contact information; the multiple-contact exception can apply (parent notice + opt-out) if the child requested them and they relate to the app's content |
| Information collected from parents/adults about children | Not covered — COPPA reaches only collection online from children |
| General-audience service receives an email from a user who says he's under 13 | May reply once under the one-time exception, then delete; but the disclosure may create actual knowledge about previously collected data (e.g., a registration address), forcing consent or deletion |
Persistent identifiers used solely for support for internal operations (network communication, authentication, contextual ads, frequency capping, security, compliance, analytics, spam protection, debugging) need no notice or consent — but behavioral advertising and profile-building are explicitly outside that definition.
The FTC six-step compliance plan
- Determine coverage — apply the four triggers above; "directed to children" weighs subject matter, visual/audio content, animated characters, child-oriented activities and incentives, age of models, child celebrities, child-directed ads, and empirical audience evidence. A ToS clause banning under-13s does not prevent the service from being child-directed.
- Post a COPPA-compliant privacy policy — clear/prominent link on the homepage and at every collection point; list all operators collecting through the service (name + address/phone/email; one may answer inquiries but all must be listed); describe types of information collected, uses, and third-party disclosures; state a data retention policy with a deletion timeframe (indefinite retention is prohibited — a 2025-amendment emphasis); describe parental rights.
- Direct notice to parents before collection — must contain the key facts within the notice itself (a bare link to the privacy policy is non-compliant, though a link must also be included): that you collected the parent's contact information to seek consent, what you want to collect, how used/disclosed, how to consent, and that you'll delete the parent's contact information if consent doesn't come in a reasonable time. New notice + consent on any material change.
- Verifiable parental consent before collection, use, or disclosure. Approved methods: signed consent form (mail/fax/scan); credit/debit card or online payment with a transaction notification to the account holder; toll-free call or video conference with trained personnel; government-ID check against a database (delete the ID after verification); knowledge-based challenge questions; photo-ID plus facial-recognition match of a second submitted photo (delete after matching). If the data is used internally only (no disclosure, not public), "email plus" suffices: consent by return email plus a confirming step — a follow-up call/fax/letter, or a delayed confirmation message restating the notice and how to revoke. A bare app-store password entry is not sufficient assurance the parent is consenting. Separate consent is required for third-party disclosure unless integral to the service.
- Honor ongoing parental rights — on request: review the child's data, revoke consent/refuse further collection, delete. Verify you're dealing with the parent (a PIN/password issued at consent time helps); service may be terminated on revocation only if the data is reasonably necessary for participation.
- Security, retention, deletion — written information security program with safeguards proportionate to sensitivity and size; release data only to parties capable of protecting it, with written assurances; written retention/deletion policy; minimize collection; retain only as long as reasonably necessary, then securely dispose.
Age gates under COPPA
- A general-audience service is not required to ask ages, and may block under-13s entirely. If it age-screens, the screen must be neutral: free entry of month/year of birth; no drop-downs that only permit 13+ birth years; no "I am over 12" checkboxes; no warnings that under-13s can't participate or should ask a parent (that coaches lying); FTC staff recommends a cookie to prevent back-buttoning to a different age. Asking for age and then failing to screen out or get consent creates liability (FTC cases: Path, Playdom, Sony BMG, Yelp).
- A mixed-audience service (directed to children under the factors, but children are not the primary audience) may age-screen, but may not block under-13s — it must either not collect from them or get parental consent. It must collect no personal information before the age question. A math problem in place of an age question is inadequate (allowed only in addition to it).
- A child-directed service (children the primary audience) may not age-screen at all: every visitor gets COPPA protections.
- Operators may rely on age information users enter on a neutral screen even if false; actual knowledge arises later (e.g., a parent's complaint, a monitored post revealing age/grade) and then forces consent or deletion.
UK Children's Code (Age Appropriate Design Code)
The ICO's statutory code under the DPA 2018 applies to "information society services likely to be accessed by children" — children meaning under 18, a far wider net than COPPA's under-13. "Likely to be accessed" covers services children use even when they are not the target audience. It reaches apps, games, search engines, social platforms, marketplaces, streaming, news/educational sites, connected toys — and non-UK companies processing UK children's data. It does not apply to schools (though edtech providers serving schools can be in scope). Conformance is how the ICO judges UK GDPR/DPA 2018 compliance for children's data, so breaches are enforced with the normal UK GDPR toolkit.
The 15 standards (email/marketing-relevant ones bolded):
| # | Standard | One-line requirement |
|---|---|---|
| 1 | Best interests of the child | Primary consideration in design and development |
| 2 | DPIAs | Assess/mitigate risks to children, by age and development stage |
| 3 | Age appropriate application | Establish user age with certainty proportionate to the data-processing risk, or apply the code's standards to all users |
| 4 | Transparency | Concise, prominent, age-suited privacy information; "bite-sized" just-in-time explanations |
| 5 | Detrimental use of data | No uses shown to harm wellbeing or that breach industry codes/regulatory provisions/government advice |
| 6 | Policies and community standards | Actually uphold your published terms, age restrictions, and policies |
| 7 | Default settings | "High privacy" by default absent a compelling best-interests reason |
| 8 | Data minimisation | Collect/retain only the minimum needed for elements the child actively uses; separate choices per element |
| 9 | Data sharing | No disclosure of children's data without a compelling best-interests reason |
| 10 | Geolocation | Off by default; obvious sign when active; visibility-to-others reverts to off each session |
| 11 | Parental controls | Age-appropriate information; obvious sign to the child when monitored |
| 12 | Profiling | Off by default; only with measures protecting the child from harmful effects |
| 13 | Nudge techniques | No nudging children into providing unnecessary data or weakening privacy protections |
| 14 | Connected toys and devices | Include effective conformance tools |
| 15 | Online tools | Prominent tools for children to exercise rights and report concerns |
For email marketing this bites through standards 3, 7, 8, 12, and 13: a signup flow "likely to be accessed" by under-18s cannot pre-tick marketing options, nudge minors toward opting in, profile them for targeting by default, or hoover an email address beyond what the requested feature needs — and if the service will not do age assurance, it must run those child defaults for everyone.
GDPR Article 8 — consent ages for information society services
Where an information society service is offered directly to a child and relies on consent (Art. 6(1)(a)) — the lawful basis email marketing normally uses — Article 8 makes the child's own consent valid only from age 16; below that, "processing shall be lawful only if and to the extent that consent is given or authorised by the holder of parental responsibility over the child." Member states may lower the threshold by law, but not below 13 — so the digital consent age varies from 13 to 16 across the EU (the UK set 13 in the Data Protection Act 2018, which is why the ICO's marketing guidance treats 13 as the floor for a minor's own consent). The controller must make "reasonable efforts to verify" that consent was given or authorised by the parental-responsibility holder, "taking into consideration available technology." Practical consequence for a signup form serving Europe: below the applicable national age, a child's own opt-in is void as a consent basis; at or above it, a plain opt-in works, but the PECR/ePrivacy consent-quality rules still apply.
ESP policy implications
What the three regimes jointly imply for an ESP's own platform rules and its customers' forms:
- Age gates on signup forms. Hosted forms aimed at general audiences that want to exclude minors should use a neutral date-of-birth field (never a 13+/16+-only picker, never an "I am over N" checkbox, no discouraging text) and persist the answer (cookie) against back-button retries. Blocking under-age respondents is lawful for general-audience properties in every regime; the trap is asking and then ignoring the answer — that converts ignorance into actual knowledge.
- Child-directed customers are a distinct risk class. A customer whose audience is children needs the COPPA machinery (direct notice, verifiable parental consent, parent-facing opt-out for the multiple-contact/newsletter exception) that a standard subscribe→confirm flow does not provide. An ESP should either support parent-mediated consent capture (parent's address collected alongside the child's, notice sent to the parent, opt-out honored before ongoing sends) or prohibit child-directed lists in its AUP.
- Consent records must show whose consent it is. For minors the proof-of-consent record needs the parent's identity/contact and the verification method used — a timestamped opt-in from the child's own address proves nothing in any of these regimes.
- Deletion is part of the lifecycle. COPPA's one-time exceptions and the parent's revocation right, the Children's Code's data-minimisation/retention standards, and GDPR erasure all mean child addresses need prompt, provable deletion paths — not just suppression.
- Actual-knowledge hygiene. Support tickets, replies, and complaint content that reveal a subscriber is a child create actual knowledge for the sender (and arguably the ESP processing on its behalf). The compliant responses are parental consent or deletion — continuing to mail is the violation.
- Marketing law still applies on top. Nothing above replaces CAN-SPAM, CASL, or PECR — a parent-consented child newsletter still needs truthful headers, identification, and a working unsubscribe.
These summaries reflect regulator-published guidance (FTC as of its May 2026 six-step revision and the April 22, 2025 COPPA Rule amendment; ICO code text as published) and are not legal advice.
Sources
- https://www.ftc.gov/business-guidance/privacy-security/childrens-privacy
- https://www.ftc.gov/business-guidance/resources/childrens-online-privacy-protection-rule-six-step-compliance-plan-your-business
- https://www.ftc.gov/business-guidance/resources/complying-coppa-frequently-asked-questions
- https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/introduction-to-the-childrens-code
- https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/code-standards/
- https://gdpr-info.eu/art-8-gdpr/