Email Tracking Pixels Guide: What Senders Learn When You Open a Message and How to Block It

Opening an HTML email can quietly tell the sender that you read it, when, roughly where you are and which device you used, through an image you never see. Marketers use these tracking pixels for open rates, but attackers use the same mechanism to confirm live addresses and profile targets before a phishing campaign, which makes remote content a security setting as well as a privacy one. This guide explains how email tracking pixels work, what each major mail client does about them, how organisations can block or neutralise them centrally, and where European and UK regulators now draw the line for senders. It is written for email and endpoint administrators, security awareness teams and anyone who sends marketing or transactional email.

Source note: the regulatory positions below summarise the EDPB Guidelines 2/2023 (version 2.0), the CNIL recommendation (deliberation 2026-042, adopted 12 March 2026, published 14 April 2026) and ICO guidance as read on 11 November 2026, and are not legal advice. Confirm against the official text before relying on it.

Key takeaways

• A pixel is a remote image with your identity in the URL. When the client fetches it, the sender's server logs the open, the time, the IP address and the client software, tied to a per-recipient identifier.
• Attackers use pixels for reconnaissance. MITRE ATT&CK notes that adversaries embed tracking pixels, web bugs or web beacons in phishing messages to verify receipt and profile information such as IP address (T1598.003).
• Blocking remote content by default is the strongest control. Classic Outlook and Thunderbird block remote images by default; Apple Mail Privacy Protection and Gmail's image proxy change what the sender learns rather than stopping the fetch.
• Proxying protects location, not necessarily the open. Hiding the IP address removes location and network data, but whether an open still registers depends on how and when the proxy fetches images.
• Regulators treat email pixels like cookies. The EDPB says Article 5(3) of the ePrivacy Directive applies to email tracking pixels, and the French CNIL's 2026 recommendation makes consent the general rule with narrow exemptions.

How a tracking pixel works

An HTML email can reference images hosted elsewhere instead of carrying them as attachments. A tracking pixel is one of these remote images, usually a transparent 1 by 1 pixel, whose URL contains a value unique to the recipient, such as https://track.example.net/o/8f3a2c.gif. When the recipient's mail client renders the message and fetches the image, the request reaches the sender's (or their email service provider's) server, which records it against that identifier.

The EDPB's Guidelines 2/2023 (version 2.0, adopted 7 October 2024) describe this precisely: a pixel is a link to a resource whose main purpose is to trigger a request that would not otherwise happen; distributing it counts as storage at least through the client's caching; adding tracking information is an instruction to the recipient's device to send back an identifier; and collecting it is "gaining access" under Article 5(3). Pixels are often combined with tracked links, where every link in the message passes through a redirect URL carrying the same identifier, so clicks are recorded even when images are blocked.

What a sender can learn

Mozilla's Thunderbird documentation summarises the privacy problem well: remote content can reveal when a message was opened, roughly what app and platform the reader uses, approximate location from the IP address, and that the address is active, and because it is aimed at a known recipient it is more linkable to that person than ordinary web browsing. Research published at PETS 2018 found that about 30% of commercial mailing-list emails leaked the recipient's email address to one or more third parties when viewed, across a network of hundreds of third-party trackers.

How to tell whether a message contains a tracker

Analysts triaging a suspicious message, and senders auditing their own templates, can spot pixels without loading them:

1. View the raw source: open the original message (in a viewer that does not render HTML) and search for <img tags whose src points to an external host.
2. Look for the tell-tale shape: width and height of 1 or 0, display:none or zero-opacity styles, an image placed after the footer, or an image URL ending in a long random path or query string.
3. Compare two copies: if the same campaign sent to two addresses has different image URLs, the URL carries a per-recipient identifier.
4. Check link URLs: redirect links with long per-recipient tokens provide click tracking even when images stay blocked.
5. Record, do not fetch: during phishing analysis, never request the pixel from a corporate address; it confirms to the attacker that the target is live. Use an isolated sandbox if the content must be retrieved.

Why it is a security issue, not only a privacy one

• Address validation: spammers and phishers send probe messages with pixels to find live, read addresses worth targeting. Thunderbird's documentation names this use of web bugs directly.
• Target profiling: the IP address and client details reveal whether a target uses a corporate network, a VPN, a mobile device or a particular mail client, which helps an attacker choose a lure and a payload. ATT&CK lists this under T1598.003 Spearphishing Link (Phishing for Information) and the related reconnaissance techniques T1590.005 IP Addresses and T1592 Gather Victim Host Information.
• Timing: knowing when a target reads mail helps time follow-up calls or messages in callback and business email compromise attacks. See the Callback Phishing (TOAD) Guide.
• Executive exposure: pixels in messages to senior staff can disclose travel and home locations. See the Executive Protection and Digital Footprint Guide.
• Remote content as an attack surface: Microsoft lists protection from malicious code alongside tracking pixels as reasons classic Outlook blocks automatic picture downloads.

Mail client defences compared

Check other clients and webmail services individually: defaults change between releases, and mobile apps from the same vendor do not always match the desktop client.

Organisational controls

For organisations receiving email

• Enforce remote content blocking centrally: set the Outlook automatic download setting through Office administrative templates or your device management tool rather than relying on each user, and keep Safe Senders exceptions to internal and genuinely trusted domains.
• Use gateway rewriting where available: some secure email gateways can proxy or strip remote images and rewrite tracked links. Test the effect on legitimate newsletters before enforcing.
• Prefer plain or safe rendering for high-risk roles: finance, executives and help desk staff receive the most targeted probes.
• Block known tracking domains at DNS or proxy: tracking protection lists used in browsers also cover many email trackers; the PETS 2018 authors proposed stripping tags with enhanced versions of these lists. See the Protective DNS Guide.
• Teach the trade-off: awareness material should explain that "download pictures" tells the sender you opened the message. See the How to Spot a Phishing Email Guide.

For organisations sending email

• Inventory pixels: list every platform that inserts open tracking (marketing automation, CRM, sales engagement tools, transactional mail services) and what it stores.
• Separate purposes: distinguish deliverability measurement, campaign analytics and profiling, because regulators treat them differently.
• Turn tracking off where it is not needed: password resets, security alerts and account notifications rarely need open tracking.
• Stop relying on open rates as truth: proxying and privacy features make opens unreliable; use clicks, replies and conversions for decisions.

What regulators say

This table is a summary for orientation. Confirm against the official text before relying on it.

The CNIL recommendation is the most detailed so far. It asks senders to collect consent preferably when the address is collected, to treat inactivity as refusal, to put a withdrawal link in every email footer, and, for the deliverability exemption, to keep only the date of the last known open. For web trackers and the wider consent picture see the Cookie and Tracking Technology Compliance Guide.

How to implement: a phased approach

1. Baseline: record the remote content setting on every managed mail client and webmail service, and which users have broad Safe Senders exceptions.
2. Pilot blocking: enforce remote content blocking for a pilot group, such as IT and security staff, for two weeks and collect complaints about broken internal mail or newsletters.
3. Fix internal senders: make internal templates, HR systems and alerts work without remote images (embedded images or plain text) so blocking does not train users to click "download pictures".
4. Roll out by ring: high-risk roles first, then everyone. Keep the policy reversible by group so you can roll back if a business-critical sender breaks.
5. Add gateway and DNS layers: where your gateway supports image proxying or tracker stripping, enable it in monitor mode first and compare delivered content.
6. Clean up outbound tracking: remove pixels from security and account emails, document lawful basis or consent for the rest, and add withdrawal links where required.

Detection and measurement

• Policy coverage: percentage of managed clients with remote content blocked by policy.
• Exception sprawl: number of Safe Senders or remote content exceptions per user, and how many are external domains.
• Probe detection: inbound messages with a single remote image and little or no content from first-time senders, which often signals address validation.
• Tracker egress: DNS or proxy requests to known email tracking domains from corporate devices, which shows blocking gaps.
• Outbound hygiene: share of security and transactional templates with no open tracking.

Common failure patterns

• Blocking by default but trusting by sender address: Safe Senders lists and per-address exceptions are spoofable, so a phisher who imitates a trusted sender gets images loaded.
• Internal mail that depends on remote images: if HR and IT newsletters only work with pictures enabled, users learn to click "download pictures" on everything.
• Assuming a proxy means no tracking: proxying hides location but tracked links still record clicks and identities.
• Pixels in security notifications: putting open tracking in password reset and alert emails shares security events with marketing platforms and third parties.
• Treating open rates as consent evidence or engagement proof: privacy features distort opens, and regulators increasingly see analysis of them as needing consent.

Framework mapping

Practitioner checklist

• Block automatic remote content on all managed mail clients by policy.
• Restrict remote content and Safe Senders exceptions to verified internal or trusted domains.
• Rebuild internal templates so they render without remote images.
• Enable gateway image proxying or tracker stripping where available, after a monitor-mode test.
• Block known email tracking domains at DNS or web proxy for high-risk groups.
• Remove open tracking from password reset, security alert and account emails.
• Document the purpose and lawful basis or consent for every outbound pixel, with an easy withdrawal route.
• Explain in awareness training what loading pictures reveals to a sender.

Standards and references

• EDPB: Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive
• CNIL: Pixels de suivi dans les courriers électroniques, recommendation
• CNIL: Recommendation on tracking pixels in emails (English text)
• ICO: What are storage and access technologies?
• Microsoft: Block or unblock automatic picture downloads in classic Outlook email messages
• Apple: Use Mail Privacy Protection on iPhone
• Mozilla: Remote content in messages
• PETS 2018: I never signed up for this! Privacy implications of email tracking

Related NHI Mgmt Group resources: Email Security Guide · Cookie and Tracking Technology Compliance Guide · MITRE ATT&CK T1598 Phishing for Information · Newly Registered Domains Guide