# Email tracking pixels under UK PECR: a practical guide > Understand the UK rules for email tracking pixels: PECR Regulation 6, B2B email, consent, exceptions, UK GDPR, vendors, and a practical implementation checklist. - **Category:** Email compliance - **Published:** August 5, 2026 - **Reading time:** 18 min read - **Author:** Maya Chen, Email infrastructure - **Canonical page:** [https://emailbump.com/blog/email-tracking-pixels-uk-pecr](https://emailbump.com/blog/email-tracking-pixels-uk-pecr) In the UK, an email tracking pixel is not governed only by the rules for sending marketing email. The Information Commissioner’s Office says the email itself falls under PECR’s electronic-mail marketing provisions, while a pixel that stores information on or accesses information from a recipient’s device falls under the separate storage-and-access rules in Regulation 6. Unless an exception applies, those rules require clear information and prior consent to the UK GDPR standard. That distinction matters most in B2B marketing. A business may be allowed to send unsolicited marketing email to a corporate subscriber without consent, but that does not automatically authorize an open-tracking pixel. The ICO expressly says the storage-and-access rules apply to tracking pixels in B2B email and to all subscriber types. > **This is a technical compliance guide, not legal advice** > > PECR, the UK GDPR, and the Data (Use and Access) Act interact in ways that depend on your audience, purpose, technology, contracts, and current commencement rules. Ask qualified UK privacy counsel to confirm scope, exemptions, consent design, and enforcement exposure for your organization. ## UK email pixel rules at a glance ### Two-question PECR test ```text QUESTION 1 — MAY WE SEND THIS EMAIL? Solicited marketing generally permitted Unsolicited email to an individual consent or a complete soft opt-in Unsolicited email to a corporate subscriber may be sent without consent Sole trader or some partnerships treated as individual subscribers Every marketing message identify sender and provide an opt-out QUESTION 2 — MAY WE LOAD THIS PIXEL? Non-exempt storage or access prior consent + clear information Strictly necessary requested-service use may qualify for a narrow exception Sole-purpose aggregate service statistics may qualify with information + objection Individual campaign opens or profiling consent generally required B2B corporate recipient no blanket pixel exemption Passing the send test does not answer the tracking test. ``` Run both questions for every template and purpose. A lawful marketing send can contain an unlawful tracker. A transactional email can also contain a nonessential marketing pixel. Conversely, disabling a pixel does not cure a message sent without the consent, soft opt-in, identification, or unsubscribe controls required for the message itself. ## Why Regulation 6 applies to an email image A typical tracking pixel is a remotely hosted image with a unique URL. When the message is rendered, a mail client or intermediary requests that URL. The server can receive the URL identifier and request metadata, potentially including the time, IP-derived location, operating system, client, and repeat activity. The ICO’s storage-and-access guidance specifically identifies pixels embedded in email and says Regulation 6 applies when they store information or gain access to information stored on the device. ### What an open-like event represents ```text HTML email contains remote image URL -> reader, client, proxy, cache, or security scanner requests image -> image server receives identifier and available request metadata -> event pipeline records an open-like request -> campaign, contact, profile, or automation may be updated The request is not proof that a human saw or read the message. PECR analysis turns on the storage or access operation and its purpose—not on whether the resulting marketing metric is perfectly accurate. ``` Regulation 6 is technology-neutral. It is not limited to browser cookies or websites. The ICO lists tracking pixels, link decoration, navigational tracking, fingerprinting, web storage, scripts, and tags as technologies that can fall within the rules when they store or access information on terminal equipment. ## The B2B consent trap PECR distinguishes individual subscribers from corporate subscribers for electronic-mail marketing. Companies, limited liability partnerships, Scottish partnerships, and certain other legal bodies are generally corporate subscribers. Sole traders and many ordinary partnerships are treated as individual subscribers. The sender can ordinarily email a corporate subscriber without prior marketing consent, although it must identify itself and provide a valid opt-out address. That corporate-subscriber rule is about sending the message. The ICO separately states that the cookie and similar-technology rules apply when a B2B email pixel stores or accesses device information, and that these rules apply to all subscriber types. A work address at a limited company therefore does not make individualized open tracking automatically consent-free. ### LIMITED COMPANY **Marketing send may not need PECR consent** A non-exempt individual open pixel still needs its own Regulation 6 analysis. ### SOLE TRADER **Marketing send needs consent or a valid soft opt-in** Pixel consent or an applicable storage-and-access exception is a separate requirement. ### NAMED WORK EMAIL **UK GDPR can apply to the contact record** A person remains identifiable even when acting in a professional capacity. ### ROLE ADDRESS **The email address may not identify a person** Regulation 6 can still apply because it protects terminal information, not only personal data. > **When subscriber type is uncertain, do not guess** > > The ICO recommends treating uncertain business details as belonging to an individual subscriber. Build a conservative default rather than trying to infer legal form from an email domain or job title. ## What valid pixel consent requires PECR takes its consent standard from the UK GDPR. Consent must be freely given, specific, informed, unambiguous, and expressed through a clear affirmative action. It must exist before a non-exempt pixel stores or accesses information; a notice shown only after the tracked email has loaded is too late for that request. - Explain that email contains a remote tracking pixel and what it does before the choice. - State each purpose, such as individual campaign measurement, frequency decisions, personalization, or profiling. - Describe relevant data, duration, and any third parties that store, access, or receive information. - Use an affirmative action; silence, continued use, inactivity, and pre-ticked boxes are not valid consent. - Keep the request clearly distinguishable from unrelated terms and avoid making nonessential tracking a condition of service. - Make refusal as easy as acceptance and do not insert non-exempt pixels before acceptance. - Keep evidence showing who chose what, when, how, and against which notice and purpose version. - Make withdrawal as easy as consent and propagate it before any later tracked message is rendered. ### Consent evidence model ```text recipient_id internal contact identity email_address_scope exact address covered by the choice tracking_purpose measurement / personalization / profiling purpose_version stable version of purposes requested notice_version immutable copy of the information shown decision accepted / refused / withdrawn decided_at timestamp and collection context third_parties named providers included in the request withdrawn_at effective withdrawal time render_policy pixel_allowed / exception_only / no_pixel sync_status ESP, automation, CRM, warehouse, and cache state ``` Do not assume that consent to receive marketing email also covers its pixel. If one interface asks for both, the language and controls must make both operations specific and informed. The Italian Garante has issued express guidance about a possible combined choice; the UK ICO pages do not create an equivalent automatic shortcut. Have the combined design reviewed against the UK consent standard. ## The five Schedule A1 exceptions ### PECR storage and access exceptions ```text EXCEPTION CORE CONDITION EMAIL PIXEL RELEVANCE Communication sole purpose is transmitting communication pixel rarely makes delivery possible Strictly necessary essential for a service the user requested narrow security/authentication uses Statistical purposes sole purpose is aggregate service improvement possible only within strict boundaries Appearance adapts service to the user’s chosen preference rarely a conventional open pixel Emergency assistance sole purpose is emergency device location not ordinary email analytics Statistical and appearance uses also require clear information and a simple, free means to object. Going beyond an exception requires consent. ``` ## Why the communication exception is narrow The communication exception applies only when the technology’s sole purpose is transmitting a communication and transmission is impossible without it. A remote image used to learn whether a message opened does not ordinarily route the email, preserve the order of its data, or detect transmission loss. Calling an open pixel “delivery infrastructure” does not make it necessary to transmit the message. ## Strictly necessary security and authentication The strictly necessary exception is assessed from the user’s perspective: without the technology, the requested service cannot be provided technically, or the technology is the only reasonable and proportionate way to meet another legal requirement. The ICO lists terminal security, fraud prevention or detection, fault detection, and authentication as activities that can qualify depending on the service. - Tie the operation to a service the recipient actually requested. - Document why the pixel is essential and why a less intrusive mechanism will not work. - Use the event only for the necessary security, authentication, or fault purpose. - Do not reuse it for engagement scores, campaign reports, personalization, sales alerts, or advertising. - Do not treat an image request as a standalone authentication factor because proxies, caches, forwarding, and scanners can trigger it. ## Can the statistical purposes exception cover open rates? Potentially in a narrowly designed system, but the exception is not a general permission for email analytics. It applies when an information-society service provider uses the technology solely to produce aggregate statistics about how its service is used, with a view to improving that service. The provider must give clear information and a simple, free way to object. ### Statistical exception boundary ```text MORE LIKELY TO FIT DOES NOT FIT aggregate output that cannot identify people named or pseudonymous open history sole purpose is improving the requested service lead scoring or campaign retargeting simple, free objection is available tracking hidden from the recipient individual data kept only as briefly as necessary raw recipient events retained after aggregation third party uses data only to improve the service provider benchmarks, ads, or separate product use no decisions or inferences about people or groups cadence or content changed per recipient The ICO’s published examples focus mainly on website and online-service analytics. Document why a specific email use meets every element before relying on it. ``` The exception concerns how a service is used, not who uses it. The ICO says it does not cover identifying, tracking, profiling, or monitoring individual people or groups; retaining individual-level information after aggregation; or advertising purposes. A dashboard showing a percentage does not qualify if unique recipient events remain available underneath it. ## PECR and the UK GDPR apply in layers Regulation 6 protects information on terminal equipment whether or not that information is personal data. When the identifier, IP address, contact record, or linked event relates to an identifiable person, the UK GDPR also applies. The organization then needs a lawful basis, fair and transparent processing, data minimization, retention limits, security, processor arrangements, and support for individual rights. ### Layered compliance test ```text LAYER 1 — PECR STORAGE OR ACCESS Is information stored on or accessed from terminal equipment? Is there valid prior consent or a complete Schedule A1 exception? LAYER 2 — UK GDPR PERSONAL DATA Is the event linked or linkable to an identifiable person? What lawful basis, transparency, minimization, retention, and rights apply? LAYER 3 — PECR MARKETING MESSAGE Is the message solicited or unsolicited? Is the subscriber individual or corporate? Does consent or a complete soft opt-in exist where required? Are identity and unsubscribe requirements met? ``` Legitimate interests can sometimes support B2B contact processing or a soft-opt-in marketing database under the UK GDPR. It does not by itself disapply Regulation 6 or authorize a non-exempt tracking pixel. Keep the lawful-basis record separate from the pixel consent or exemption record. ## Sender and email provider responsibilities For electronic-mail marketing, the sender and any organization instigating the message can be responsible. A bulk-email platform providing technical delivery does not normally take over the sender’s marketing compliance. For storage and access technologies, the online service provider making decisions about the feature, technology, and purposes ordinarily has primary responsibility and must put appropriate arrangements in place with vendors. - Inventory which party chooses pixel insertion, identifier format, purposes, fields, retention, and downstream destinations. - Configure the ESP so non-exempt pixels are off until the correct address-level consent state exists. - Contract for documented instructions, security, deletion, sub-processors, international transfers, and prohibited reuse. - Name third parties where required by the consent information rather than saying only “trusted partners.” - Audit image hosts, CDNs, proxy endpoints, logs, warehouses, CRM events, and exports—not merely the visible analytics page. - Provide a pixel-free render path and a reliable way to suppress requests from identifiers in messages already delivered after withdrawal. ## A UK implementation pattern ### Policy-aware email rendering ```text INPUT recipient address + subscriber classification message purpose + requested-service context pixel purpose + applicable exception assessment consent evidence + objection + withdrawal state RENDER valid tracking consent -> permitted purpose-specific pixel complete exception -> minimized exception-only implementation statistical exception -> aggregate-only design + notice + objection anything else -> pixel-free message AFTER SEND preserve delivery evidence separately from open-like events prevent purpose expansion in CRM, automations, and warehouse apply withdrawal to future renders and outstanding identifiers re-audit after provider, template, purpose, or legal-guidance changes ``` Treat the result as a policy decision, not a campaign-editor toggle. Templates are reused across recipients, but the lawful render can depend on subscriber type, consent, objection, requested service, purpose, and provider behavior. When reliable classification or evidence is missing, the safer output is a message without the nonessential pixel. ## Audit the full email path ### UK pixel compliance audit ```text 1 RENDER generate every marketing, lifecycle, sales, and service template 2 DISCOVER locate remote images, unique URLs, redirects, and vendor defaults 3 TRACE follow identifiers through CDN, logs, ESP, CRM, warehouse, and exports 4 CLASSIFY separate message permission from every pixel purpose 5 EXEMPT document each exception element from the user’s perspective 6 CONSENT verify information, affirmative choice, evidence, refusal, and withdrawal 7 MINIMIZE reduce fields, precision, identifiers, access, and retention 8 SEPARATE stop exempt or operational data feeding marketing and advertising 9 TEST cover B2B, sole traders, proxies, scanners, old messages, and vendor failure 10 REVIEW repeat when ICO guidance, the service, or the technology changes ``` ## Proxies and scanners do not remove the compliance problem Apple Mail Privacy Protection, security scanners, image proxies, caches, forwarding, and background loading can inflate, hide, delay, or relocate pixel requests. This makes open rate a noisy metric and complicates what information is actually accessed from which equipment. It does not create a blanket exemption. Document the real request path and data received for each major client instead of assuming every event has the same legal or analytical meaning. ## Click tracking is a separate review Turning off an open pixel does not automatically make unique redirect links a consent-free replacement. The ICO expressly includes link decoration and navigational tracking when they involve storage or access. A campaign-level source parameter is different from a stable recipient ID that connects browsing, purchases, and advertising profiles. Inventory redirects, query strings, cookies set at landing, and partner disclosures separately. ## What changed after the Data (Use and Access) Act The ICO’s current storage-and-access guidance reflects five Schedule A1 exceptions, including statistical purposes and appearance. Its enforcement page also says the Data (Use and Access) Act, which became law on June 19, 2025, is changing the PECR enforcement regime to align it with the UK GDPR and DPA 2018 framework. As of this article’s publication, the ICO says that section will be updated as the new regime comes into force, so avoid relying on an old penalty figure or a static compliance memo. > **Build for the current rule and an updateable policy** > > Keep purposes, exceptions, notices, consent versions, and render behavior configurable. A hard-coded global pixel is difficult to change when ICO guidance, commencement dates, vendor behavior, or audience scope changes. ## Measure useful outcomes without individual opens A pixel-free or aggregate-only program can still measure receiver acceptance, bounces, deferrals, complaints, unsubscribes, replies, and first-party product or purchase outcomes under the appropriate rules. These signals are often closer to the actual customer and deliverability result than a remote image request. ### DELIVERY **Receiver accepted or rejected the message** Useful operational evidence, not proof of inbox placement or reading. ### AGGREGATE **Service statistics that cannot identify recipients** Use only within the statistical exception’s purpose, notice, objection, and retention boundaries. ### REPLY **Recipient started an expected conversation** A meaningful signal when replies are monitored and handled appropriately. ### OUTCOME **Customer completed the intended first-party action** Measure the product, account, or purchase goal rather than treating an open as success. ### NEGATIVE **Bounce, complaint, objection, or unsubscribe occurred** Suppress promptly and investigate source, expectations, and targeting. ## Separate delivery, tracking, and customer outcomes Email Bump keeps message activity, contacts, consent, replies, events, and suppressions distinguishable so teams can reduce dependence on noisy individual open pixels. - Message-level delivery activity - Consent and suppression state - First-party outcome context [Learn more](https://emailbump.com/features/analytics) ## Frequently asked questions ## Are email tracking pixels legal in the UK? They are not universally prohibited, but a pixel that stores or accesses device information must meet Regulation 6. Non-exempt uses require clear information and prior UK GDPR-standard consent. Narrow exceptions can apply only when every purpose and condition is satisfied. Personal-data processing must also comply with the UK GDPR. ## Do B2B email tracking pixels require consent? Do not assume they are exempt. The electronic-mail rule may allow unsolicited marketing to a corporate subscriber without consent, but the ICO says the storage-and-access rules for tracking pixels apply to all subscriber types. The pixel still needs valid consent or a complete exception. ## Can legitimate interests authorize an email pixel? Legitimate interests may be relevant to subsequent UK GDPR processing, including some B2B contact uses. It does not replace the separate PECR requirement for consent or an exception before non-exempt storage or access on terminal equipment. ## Can we use the statistical purposes exception for campaign opens? Only if the design satisfies every condition. The sole purpose must be aggregate statistics about use of the service to improve it; recipients must receive clear information and a simple free objection; individual-level information cannot remain available after it is needed; and the data cannot support identification, profiling, advertising, or decisions about people or groups. The ICO’s examples focus on websites and online services, so document and review the specific email use carefully. ## Does a tracking blocker or privacy proxy solve PECR compliance? No. Those technologies can change which requests arrive and what they reveal, but the sender remains responsible for understanding the pixel it inserted, its purposes, and the actual processing path. They also make open-like events less reliable as evidence of a human read. ## Continue the email tracking compliance series - [Email link tracking and privacy](https://emailbump.com/blog/email-link-tracking-privacy) — Apply the link-decoration rules to campaign UTMs, unique redirects, action tokens, scanners, and landing pages. - [Email analytics without tracking pixels](https://emailbump.com/blog/email-analytics-without-tracking-pixels) — Measure delivery, replies, first-party outcomes, aggregate statistics, and incremental lift without individual opens. - [Italy email pixel rules](https://emailbump.com/blog/italy-email-tracking-pixel-rules) — Compare Italy’s consent, anonymous-statistics, granular-withdrawal, vendor, and transition guidance. - [CNIL email pixel rules](https://emailbump.com/blog/cnil-email-tracking-pixels) — Apply France’s 2026 purposes, narrow exemptions, transition, proof, and withdrawal requirements. - [Email tracking pixels](https://emailbump.com/blog/email-tracking-pixel) — Understand image requests, proxies, caching, accuracy limits, minimization, and safer design. - [Transactional vs marketing](https://emailbump.com/blog/transactional-vs-marketing-email) — Classify the message separately from each tracking operation inside it. ## Sources - [ICO: tracking pixels and electronic-mail marketing](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/what-else-do-we-need-to-consider/) - [ICO: what storage and access technologies include](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-storage-and-access-technologies/) - [ICO: Regulation 6 rules and consent standard](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-the-pecr-rules/) - [ICO: Schedule A1 exceptions](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-the-exceptions/) - [ICO: business-to-business marketing](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/business-to-business-marketing/) - [ICO: storage and access compliance responsibilities](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/how-do-we-comply-with-the-pecr-rules/) - [ICO: current PECR enforcement update](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-happens-if-we-don-t-comply/)