Email Tracking Pixels Explained: How Senders Know You Opened

An email tracking pixel is a tiny, usually invisible image whose web address is unique to you. When your mail client fetches it, the sender's server logs the time, your IP address (and so a rough location), and your client and operating system. You block it by stopping remote images loading automatically, or by letting your provider fetch them for you.

The pixel is only one part of a measurement system that also rewrites every link in the message, sometimes passes your address to third parties, and now has to cope with providers that load images for you or before you open anything. This post goes one level deeper than our guides to replacing Gmail with private email and browser fingerprinting: what a pixel request carries, how tracked links work, what Gmail, Apple Mail and Outlook say they do, what EU, UK and US law says, why open rates stopped being reliable, how to find trackers in raw source, and what an honest sender should do instead.

Key takeaways

• A tracking pixel is an ordinary remote image, usually 1 by 1 pixel and transparent, with an identifier for you and the campaign built into its URL. The European Data Protection Board describes it as a resource whose "sole purpose is to automatically establish a communication" back to its host.
• Loading it tells the sender's server when the message was opened, how often, from which IP address, and which client and operating system made the request. The UK ICO's own example lists time, location and operating system.
• Links in marketing email are usually rewritten to pass through a redirect server first, which records the click and then forwards you on. Blocking images does nothing to stop click tracking.
• A 2018 Princeton study of 12,618 commercial emails from 902 senders found that 85% embedded third-party content, 70% contained resources on tracking protection lists, and about 29% leaked the recipient's email address to at least one third party when viewed.
• Gmail has served images through Google's own proxy servers since December 2013. Apple's Mail Privacy Protection downloads remote content in the background whether or not you open the message, through two relays, so senders cannot learn when you opened it or your IP address. Desktop Outlook blocks automatic picture downloads by default.
• In the EU, the EDPB's Guidelines 2/2023 (version 2.0, adopted 7 October 2024) say Article 5(3) of the ePrivacy Directive applies to tracking pixels and tracked links. The UK ICO says regulation 6 of PECR applies to email pixels that store or access information on a device. US CAN-SPAM rules focus on honest headers and working opt-outs, not on open tracking.
• Open rates are now a weak signal. Prefetching inflates them, image blocking deflates them, and proxies hide location. Senders who want honest numbers count clicks, replies and conversions, and ask for consent before tracking.

What an email tracking pixel is

An HTML email is a small web page delivered by mail. Like any web page it can reference images that live on someone else's server instead of being attached to the message. When your mail client renders the message, it fetches those images over HTTP or HTTPS. A tracking pixel exploits that fetch. It is an image the sender does not need you to see: typically a single transparent pixel, sized to 1 by 1 or hidden with styling, placed near the end of the message. Its value is entirely in the request your client makes to fetch it.

The European Data Protection Board puts the definition precisely in its Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive. It describes a tracking pixel as a link to a resource, usually an image file, embedded in a website or an email, which normally serves no purpose for the content itself. Its job is to make your client contact the pixel's host, a contact that would not otherwise have happened. The EDPB adds that a sender may put a pixel in an email to detect when the recipient reads it. The UK ICO's glossary for its storage and access technologies guidance uses almost the same words.

Here is what a typical pixel looks like in the HTML source of a message. The domain and identifiers are made up.

<img src="https://t.example-mailer.net/o/9f3c2a71e4b8?c=fall-sale&amp;r=7731042"
     width="1" height="1" alt="" style="display:block;border:0;" />

Three parts do the work. The host (t.example-mailer.net) is the server that logs the request; it may belong to the sender, to the sender's email platform, or to an advertising or analytics third party. The path segment (9f3c2a71e4b8) is usually a per-recipient token: the sending system generated a different value for every copy of the message and stored which recipient received which token. The query string (c=fall-sale&r=7731042) often carries a campaign name and sometimes a recipient or list identifier in clear text. Because every recipient gets a unique URL, a single request is enough to say "this person opened this message".

Not every tracking image is invisible. Some senders attach the identifier to a real image, such as the logo or a product photo, so that blocking "only the 1 by 1 pixels" does not help. The EDPB guidelines note this explicitly: tracking information can also be attached to images that are part of the visible content. The defensive conclusion is that you cannot reliably tell a tracking image from a decorative one by its size. The only dependable control is whether remote images load at all, and who loads them.

What loading the pixel reveals

When your mail client requests the image, the request itself is the data. The server at the other end sees what any web server sees for any request, plus whatever the sender put into the URL.

The UK Information Commissioner's Office gives a direct example in its guidance on storage and access technologies: an organisation that puts a tracking pixel in its marketing emails to record "the time, location and operating system of the device used to read the email". Apple's own privacy notice for Mail lists what senders may learn: when and how many times you opened a message, whether you forwarded it, your IP address, and other data that can build a profile and reveal your location.

The IP address is what turns an open into a location and, over time, a pattern: office hours, home network, travel. The cookie linkage is what most people do not expect. In their 2018 paper "I never signed up for this! Privacy implications of email tracking", Steven Englehardt, Jeffrey Han and Arvind Narayanan of Princeton simulated users reading a corpus of 12,618 commercial emails from 902 senders. They found nearly 900 third parties contacted at least once, an average of 5.2 third parties (median 2) in emails that embedded any third-party content, and leaks of the recipient's email address to third parties in about 29% of emails. They judged 62% of those leaks intentional. Some of the addresses were hashed rather than plain; the authors argue that hashing does little to protect privacy in this setting, because a hash of an email address is itself a stable identifier.

Why HTML email makes this possible

Plain text email cannot load anything. Pixels exist because mail clients render HTML, and rendering HTML means fetching remote resources unless the client decides otherwise. As the Princeton paper puts it, modern clients support "much of the functionality of the web", even though email started as a non-interactive text protocol. Mail clients generally do not run scripts in messages, so email tracking relies on images and links; a static image URL is enough.

Read receipts are a different mechanism: a header asking your client to send back a notification, which you can decline. Microsoft's Outlook support page draws the same line, noting that "tracking pixels aren't the same as a read receipt". A pixel does not ask.

How tracked links and redirect wrappers work

Pixels measure opens. Tracked links measure clicks, and they work whether or not images are blocked. Before a campaign is sent, the sending platform rewrites every link in the message. A link that the author wrote as a plain product page becomes a link to the platform's redirect server, carrying an identifier for you, the campaign and often the specific link position.

What the author wrote:
  https://shop.example.com/boots

What you receive:
  https://click.example-mailer.net/c/eyJ1IjoiNzczMTA0MiIsImwiOjN9/aHR0cHM6Ly9zaG9wLmV4YW1wbGUuY29tL2Jvb3Rz

What happens when you click:
  1. Your browser requests the click.example-mailer.net URL
  2. The redirect server logs: recipient 7731042, link 3, time, IP, User-Agent
  3. It answers with an HTTP 302 redirect to https://shop.example.com/boots?utm_source=email&utm_campaign=fall-sale&mc_rid=7731042
  4. Your browser loads the shop page, with campaign parameters attached

The EDPB guidelines describe the same pattern in general terms: with a tracking link the identifier is added to the web address, and when the URL is visited the site serves the page but also collects an identifier that has nothing to do with finding the page. The same guidelines note that tracked links are common in affiliate marketing, where a shop needs to know which partner sent a sale.

The click is often only the start. The landing page may carry the identifier forward in its own query string, set a first-party cookie with it, or pass it to analytics and advertising scripts on the page. The Princeton study measured this too: when it simulated clicking links, it found that 11% of links led to pages whose embedded content requests leaked the email address to a third party, and that at least 35% of senders included at least one such link in one email. This is the part of email tracking that no mail client setting can stop. Once you click, you are on the web, and the protections that apply are your browser's, not your mail client's.

Link wrapping, automatic fetching and redirect chains

Not every rewritten link comes from the sender. Many organisations route inbound mail through a gateway that rewrites links so it can check the destination at click time, and some mail systems fetch links in incoming messages to inspect them. RFC 8058, the one-click unsubscribe standard published in January 2017, exists partly because of this: its abstract notes that "mail software sometimes fetches URLs in mail header fields", which accidentally triggered unsubscriptions. The same automatic fetching can register false clicks in a sender's statistics.

A tracked link can also redirect more than once (the sending platform's click server, then an affiliate or advertising redirect, then the destination), and each hop can log the request. Some platforms encode the destination in the URL, so you can read where a link goes without visiting it. Visiting it, even with a tool that does not follow redirects, still counts as a click, because the first request reaches the sender's server. Step 3 below shows how to decode a link locally instead.

How mail clients change the picture

The behaviour of the pixel depends almost entirely on the client and the provider. The same message can reveal everything, nothing, or something misleading. Below is what each major provider says about its own behaviour, from its own documentation.

Gmail: images through Google's proxy

On 12 December 2013, the official Gmail blog announced that Gmail would display images automatically, because instead of fetching them from the original external hosts, Gmail would "serve all images through Google's own secure proxy servers". Google framed the change as a security improvement: images are checked for known viruses or malware. The privacy side effect follows from how a proxy works. The request that reaches the sender's server comes from Google's proxy, not from your device, so the connection carries Google's network address rather than yours.

What a proxy cannot hide is the fact of the fetch. When Gmail loads a uniquely addressed pixel through its proxy, the sender's server still receives a request for that recipient's token around the time the message was displayed. The proxy protects your network identity, not your reading behaviour. Google's announcement does not describe caching or which request headers the proxy forwards, so do not assume repeat views are hidden.

The Gmail help page on images says images show automatically by default, and that Gmail asks before showing images when it thinks a sender or message is suspicious. You can change the default to "Ask before displaying external images" (the 2013 announcement places it on the General tab of Settings). With that setting, each message shows a "Display images below" option, and nothing loads until you choose it.

Apple Mail: Mail Privacy Protection

Apple announced Mail Privacy Protection on 7 June 2021, alongside iOS 15, iPadOS 15 and macOS Monterey, saying it "stops senders from using invisible pixels to collect information about the user" and hides the user's IP address. Apple's current legal notice, "Mail Privacy Protection & Privacy", explains how. When you receive a message in Mail or Mail on iCloud.com, the Protect Mail Activity setting downloads remote content "in the background by default", regardless of whether you engage with the email. It routes that content through two relays run by different entities: the first knows your IP address but not the content, and the second knows the content but not your IP address, presenting a generalised identity to the sender's server.

The effect on a pixel is that it is fetched once, early, from an Apple relay address, whether or not you ever open the message. The sender sees an "open" that did not necessarily happen and a location that is not yours. Apple's iPhone User Guide adds two limits worth knowing. First, "Mail Privacy Protection does not extend to links or email attachments", so click tracking and anything inside a PDF are unaffected. Second, it requires Limit IP Address Tracking to be enabled for your network. On iPhone the setting is under Settings, Apps, Mail, Privacy Protection, then Protect Mail Activity. On a Mac it is in Mail, Settings, Privacy. Apple notes that if you turn Protect Mail Activity off, a separate Hide IP Address option can still mask your IP address through the same relay design.

Outlook: automatic picture downloads blocked

Microsoft's support page on blocking automatic picture downloads states that Outlook is configured by default to block automatic picture downloads from the internet, and lists avoiding tracking pixels among the reasons. You can download pictures for one message from the InfoBar at the top of the message, add a sender to Safe Senders so their images load automatically, or change the default under File, Options, Trust Center, Trust Center Settings, Automatic Download. The page notes a subtle point: choosing Download Pictures in the Reading Pane saves that choice for the message, so the images (and any pixel) load again the next time you open it.

Outlook comes in several forms (desktop, web, mobile, and newer desktop versions), and their defaults are not identical. Check the setting in the version you actually use rather than assuming the desktop default applies.

Other clients

Most other clients offer one of the same three controls under names such as "remote content", "external images" or "load images automatically": block it, load it through a provider proxy, or prefetch it. Look in your client's privacy or reading preferences, and check whether the setting can be made per sender.

Comparison: what each defence hides

The four common defences hide different things. This table compares them for a message that contains a unique pixel and tracked links, read by a recipient who opens it once and does not click anything unless stated.

Two lessons come out of this table. First, no reading-side defence protects clicks; the only protection there is not clicking, or reaching the destination another way (typing the site's address or searching for it). Second, proxies and prefetching protect your network identity but still send the URL itself, so any identifier or address the sender embedded in that URL still reaches the pixel host. That is why the sender's behaviour (what they put in the URL) matters as much as yours.

What the law says about tracking pixels in email

Email tracking sits where two kinds of law meet: rules about accessing information on a user's device, and data protection rules about personal data. The rules differ by jurisdiction. This section summarises what regulators have published; it is not legal advice.

European Union: the ePrivacy Directive and the EDPB guidelines

Article 5(3) of the ePrivacy Directive (Directive 2002/58/EC) requires consent for storing information, or gaining access to information already stored, in a user's terminal equipment, unless it is strictly necessary for a service the user requested or for carrying out the transmission of a communication. For years the debate was whether pixels and tracked links were "storage or access" at all, since they do not set a cookie.

The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3), version 2.0 adopted on 7 October 2024, answer that question directly in their use case on URL and pixel tracking. The Board says that delivering tracking links and pixels to a user counts as storage, at least through the caching done by the client software, so Article 5(3) applies even when that storage is temporary. It adds that putting tracking information into URLs or images instructs the user's device to send that information back, so collecting identifiers this way is also gaining access to information in the sense of Article 5(3). In plain terms: in the Board's view, a tracking pixel in an email needs consent unless an exemption applies, and analytics for the sender's own purposes is not normally "strictly necessary" for delivering the email you asked for.

Guidelines are the Board's interpretation; national regulators enforce national implementations of the Directive, which vary. Where the information collected is personal data (an IP address, a token tied to an address), the GDPR also applies to the processing that follows.

United Kingdom: PECR regulation 6 and the ICO guidance

In the UK, the same rule lives in regulation 6 of the Privacy and Electronic Communications Regulations 2003 (PECR). The ICO published draft guidance on "storage and access technologies" on 20 December 2024, consulted again in July 2025 on changes made by the Data (Use and Access) Act, and says it finalised the guidance on 29 April 2026. The guidance applies regulation 6 to any technology that stores or accesses information on a device, "by any method", and its section on what counts includes tracking pixels by name.

The ICO's email example is specific. It describes an organisation that puts tracking pixels in its marketing emails to record time, location and operating system, and states that while most email marketing is governed by regulation 22 of PECR (the rule about sending unsolicited marketing email), regulation 6 applies where the pixels store information on, or access information from, a user's device. The ICO's page on how PECR relates to the UK GDPR says PECR must be considered first, that the UK GDPR applies to processing of personal data beyond the storage or access, and lists "pixel tags" among online identifiers that can be personal data.

United States: CAN-SPAM

The US CAN-SPAM Act (15 U.S.C. chapter 103) and the Federal Trade Commission's rule at 16 CFR part 316 regulate commercial email differently. They do not require consent before sending commercial email and do not address open tracking. What they require is honesty and a working exit. Section 7704 requires a functioning return address or other internet-based mechanism to opt out that remains capable of receiving requests for no less than 30 days after the message is sent; prohibits sending further commercial email more than 10 business days after an opt-out request; and requires clear identification that the message is an advertisement or solicitation and a valid physical postal address of the sender. The FTC rule adds that a sender may not require the recipient to pay a fee or provide any information other than their email address and opt-out preferences in order to opt out.

So CAN-SPAM does not prohibit a pixel in a marketing email, but the message it rides in has to meet those rules. US state privacy laws may add rights over the data collected; that depends on the state and the business and is outside this post.

Do Not Track and why it does not help here

The W3C's Tracking Preference Expression (the "Do Not Track" header) was published as a W3C Working Group Note on 17 January 2019 after work on it stopped, and it never had an email equivalent. Mail clients do not send a preference signal with image requests, and senders are not obliged to look for one. In email, the controls that work are the ones in your client and the consent rules that bind the sender.

How reliable are open rates now?

Not very, and in both directions at once.

Prefetching inflates opens. When a provider downloads remote content in the background on delivery, as Apple describes for Protect Mail Activity, every message to that recipient looks opened, at delivery time, from a relay address. A sender who treats these as real opens will overcount engagement for those recipients and misjudge send-time tests.

Image blocking deflates opens. A recipient who reads every word in a client that blocks remote images, as desktop Outlook does by default, never registers an open unless they choose to load pictures.

Proxies blur the details. Through a provider's image proxy, the sender sees the proxy's network address instead of the reader's. Any report of "opens by city" for those recipients is describing the proxy, not the reader.

Automatic link checking adds false clicks. Systems that fetch links to inspect them can register clicks that no human made, which is the same failure mode that RFC 8058 describes for unsubscribe URLs.

The result is that an open rate is now a mixture of real reads, prefetches, proxy fetches, and invisible reads that never loaded an image. That is why many senders have moved their primary measures further down the funnel:

The healthy conclusion for a sender is that measuring individual opens no longer pays for the privacy cost and the legal exposure. Aggregate delivery and engagement data, clicks on links people chose to follow, and replies give a more honest picture.

Step by step: find pixels and tracked links, then turn them off

This walkthrough works on any computer with Python 3. Nothing here contacts the sender. The goal is to see exactly what a message would have reported, then change your settings so it does not.

Step 1: get the raw source of a message

Every mail client can show the raw message, the full text including headers and the HTML part. In Gmail, open the message, click More (the three dots next to Reply) and choose "Show original"; that page has a "Download original" option that saves a .eml file. In other clients, look for "View source", "Show original", "Raw source" or "Save as" in the message menu, and save the result as a .eml file.

Do not open the HTML part in a browser to look at it. Opening it in a browser loads the images, which is exactly what you are trying to avoid.

Step 2: list every remote image and its size

Save this script as find_trackers.py. It uses only the Python standard library, reads the .eml file, and prints every remote image with its declared size, plus every link and the host it points to.

#!/usr/bin/env python3
"""List remote images and links in a saved .eml file without fetching anything."""
import sys
from email import policy
from email.parser import BytesParser
from html.parser import HTMLParser
from urllib.parse import urlsplit, parse_qsl

class Collector(HTMLParser):
    def __init__(self):
        super().__init__()
        self.images, self.links = [], []
    def handle_starttag(self, tag, attrs):
        a = dict(attrs)
        if tag == "img" and a.get("src", "").startswith(("http://", "https://")):
            self.images.append(a)
        if tag == "a" and a.get("href", "").startswith(("http://", "https://")):
            self.links.append(a["href"])

def html_parts(msg):
    for part in msg.walk():
        if part.get_content_type() == "text/html":
            yield part.get_content()

def main(path):
    with open(path, "rb") as fh:
        msg = BytesParser(policy=policy.default).parse(fh)
    c = Collector()
    for html in html_parts(msg):
        c.feed(html)
    print("Remote images:")
    for img in c.images:
        w, h = img.get("width", "?"), img.get("height", "?")
        tiny = " <- likely pixel" if (w in ("0", "1") or h in ("0", "1")) else ""
        host = urlsplit(img["src"]).hostname
        print(f"  {w}x{h}  {host}{tiny}")
        for k, v in parse_qsl(urlsplit(img["src"]).query):
            print(f"      param {k} = {v[:60]}")
    print("\nLink hosts:")
    hosts = {}
    for href in c.links:
        hosts.setdefault(urlsplit(href).hostname, 0)
        hosts[urlsplit(href).hostname] += 1
    for host, n in sorted(hosts.items(), key=lambda x: -x[1]):
        print(f"  {n:3d}  {host}")

if __name__ == "__main__":
    main(sys.argv[1])

Run it against the saved message:

python3 -I find_trackers.py newsletter.eml

Typical output for a marketing message looks like this (domains invented):

Remote images:
  600x200  img.example-mailer.net
  1x1  t.example-mailer.net <- likely pixel
      param c = fall-sale
      param r = 7731042
  1x1  pixel.ads-partner.example <- likely pixel
      param e = 5f4dcc3b5aa765d61d8327deb882cf99

Link hosts:
   14  click.example-mailer.net
    1  shop.example.com

Read it like this. The 600 by 200 image is probably the banner, but it is still remote, so it may carry an identifier too. The two 1 by 1 images are pixels: one on the sending platform's tracking host, one on a third party. A parameter that looks like a long hexadecimal string may be a hash of your email address, which is the kind of third-party leak the Princeton study measured. Fourteen of fifteen links go through a click host, so almost every link is tracked; the one that is not is often the footer link to the sender's own site.

The script relies on declared sizes. A pixel sized with CSS instead of attributes will show as ?x?, so treat any remote image on a host whose name suggests tracking, or with per-recipient parameters, as a pixel regardless of size.

Step 3: decode a tracked link without visiting it

Requesting a tracked URL, even with a tool that does not follow the redirect, reaches the sender's click server and is logged as a click. Decode it locally instead. Many platforms put the destination in the URL path or a query parameter, sometimes base64 encoded.

#!/usr/bin/env python3
"""Show the parts of a tracked link and try to decode embedded destinations, offline."""
import base64, binascii, sys
from urllib.parse import urlsplit, parse_qsl, unquote

def try_b64(s):
    s = s + "=" * (-len(s) % 4)
    for decoder in (base64.urlsafe_b64decode, base64.b64decode):
        try:
            out = decoder(s).decode("utf-8")
            if out.isprintable():
                return out
        except (binascii.Error, UnicodeDecodeError, ValueError):
            pass
    return None

url = sys.argv[1]
parts = urlsplit(url)
print("host:", parts.hostname)
for seg in parts.path.split("/"):
    if seg:
        decoded = try_b64(seg)
        print("  path:", seg[:50], "->", decoded if decoded else "(not base64 text)")
for k, v in parse_qsl(parts.query):
    print("  param:", k, "=", unquote(v)[:80])

python3 -I decode_link.py 'https://click.example-mailer.net/c/eyJ1IjoiNzczMTA0MiIsImwiOjN9/aHR0cHM6Ly9zaG9wLmV4YW1wbGUuY29tL2Jvb3Rz'

host: click.example-mailer.net
  path: c -> (not base64 text)
  path: eyJ1IjoiNzczMTA0MiIsImwiOjN9 -> {"u":"7731042","l":3}
  path: aHR0cHM6Ly9zaG9wLmV4YW1wbGUuY29tL2Jvb3Rz -> https://shop.example.com/boots

The first decoded segment is the tracking payload (recipient 7731042, link 3) and the second is the real destination. If you want to visit the shop, type shop.example.com yourself. Not every platform encodes the destination this way; some keep it only on their server, and then the only way to learn it is to click.

Step 4: watch what a pixel request carries, on your own machine

If you want to see the data with your own eyes, you can run a tiny local web server and point a test image at it. This uses only your own computer and sends nothing outside it.

mkdir -p ~/pixel-test && cd ~/pixel-test
cat > show_headers.py <<'EOF'
from http.server import BaseHTTPRequestHandler, HTTPServer
from datetime import datetime, timezone

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        print(datetime.now(timezone.utc).isoformat(), self.client_address[0], self.path)
        for k in ("User-Agent", "Accept-Language", "Referer", "Cookie"):
            if self.headers.get(k):
                print(f"   {k}: {self.headers[k]}")
        self.send_response(204)
        self.end_headers()

HTTPServer(("127.0.0.1", 8000), Handler).serve_forever()
EOF
cat > test.html <<'EOF'
<p>Test message</p>
<img src="http://127.0.0.1:8000/o/test-token-123?c=demo" width="1" height="1" alt="">
EOF
python3 -I show_headers.py

Open test.html in a browser on the same machine. The terminal prints the time, the client address (here 127.0.0.1, because it is local), the path with the token and campaign, and your browser's User-Agent and language. A real tracking server sees the same fields, with your public IP address in place of 127.0.0.1. Press Ctrl+C to stop the server.

Step 5: stop remote images loading automatically

Pick the control that matches your client. Each of these is described from the provider's own documentation.

1. Gmail on the web. In the top right, click Settings, then See all settings. Scroll to the Images section and choose "Ask before displaying external images". Click Save Changes at the bottom of the page. Messages then show a "Display images below" option.
2. Apple Mail on iPhone or iPad. Go to Settings, Apps, Mail, Privacy Protection, and turn on Protect Mail Activity. Apple notes it needs Limit IP Address Tracking enabled for your Wi-Fi network (Settings, Wi-Fi, tap the info button next to your network).
3. Apple Mail on a Mac. Open Mail, then Settings, then Privacy, and select Protect Mail Activity.
4. Mail on iCloud.com. Open Settings, then Privacy & Security, and select Protect Mail Activity; Apple says the web setting is separate from your devices.
5. Outlook desktop. Automatic picture download is blocked by default. To confirm, go to File, Options, Trust Center, Trust Center Settings, then Automatic Download, and make sure pictures are not set to download automatically. Be sparing with Safe Senders, because adding a sender allows their images (and pixels) to load.

Choose between proxying or prefetching (Gmail's default and Apple's setting) and blocking (Outlook's default and Gmail's "Ask" option) based on what you want to hide. Blocking hides the open itself; proxying and prefetching keep messages looking normal and hide your network identity, but still send the pixel URL to the sender.

Step 6: read in plain text when it matters

Many clients can display the plain text part of a message, which loads nothing remote. Look for a "plain text" or "view as plain text" option in your client's reading or display settings. Many marketing messages include a plain text alternative alongside the HTML, though some contain only a link to "view this email in your browser", which itself is tracked. Plain text reading is the strongest option for messages you are suspicious of, at the cost of layout.

Step 7: handle links deliberately

None of the settings above affect click tracking. For links in commercial email:

• Decode the link offline as in Step 3, or hover over it to see the host before clicking.
• For a shop or service you already use, go to the site directly rather than through the email link.
• If you use a private or masked address per sender (the approach described in our Gmail replacement guide), a leak of that address only identifies you to that sender's ecosystem.

What a sender should do to stay honest

If you send email, your choices decide what your recipients are exposed to, and in the EU and UK they decide whether you need consent. A defensible programme looks like this.

Ask before you track, and track less

In the EU and UK, regulators have said tracking pixels in email fall under the device storage and access rules. If you want per-recipient open tracking, you need consent that covers it, obtained before the tracking starts, and an equally easy way to withdraw it. Many senders choose not to: they turn off per-recipient open tracking entirely, or keep only aggregate delivery metrics. Check your email platform's settings; open and click tracking are often separate switches that default to on.

Minimise what goes into URLs. Never put an email address, hashed or plain, in a pixel or link URL. Use an opaque token that only your system can map back to a recipient, and expire the mapping when you no longer need it. Never pass recipient identifiers to third-party hosts. The Princeton study found that most address leaks were intentional; that is a choice a sender can stop making.

Prefer first-party hosts. A pixel or click domain you control means the request reaches only you and your processor, not an advertising network.

Keep retention short. Open and click logs with IP addresses are personal data under the GDPR and UK GDPR. Decide how long you need them and delete them on schedule.

Make leaving easy: RFC 8058 one-click unsubscribe

RFC 2369 (July 1998) defined the List-Unsubscribe header, which lets a mail client show an unsubscribe button. RFC 8058 (January 2017) added a one-click variant that is safe against automatic link fetching. A compliant message carries both headers:

List-Unsubscribe: <https://mail.example.com/unsub/opaque-token-5c1e>, <mailto:unsub@mail.example.com?subject=unsub-5c1e>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The rules in RFC 8058 are precise. The List-Unsubscribe header must contain one HTTPS URI and may also contain other URIs such as mailto. The List-Unsubscribe-Post header must contain the single key and value List-Unsubscribe=One-Click. The message must have a valid DKIM signature that covers at least both headers, so the unsubscribe URL cannot be forged. When the user clicks unsubscribe, the mail client sends an HTTPS POST to the URI. That POST must not include cookies or HTTP authorization, so the URI itself must carry an opaque identifier for the recipient and list. The sender's server must not answer with an HTTPS redirect, because redirected POSTs have historically not worked reliably.

On the server side, the handler only needs to accept the POST, check that the body is List-Unsubscribe=One-Click, look up the opaque token, mark the recipient as unsubscribed and return a success status without redirecting. Test it with a POST from your own machine before wiring it to real data, and make sure the same token cannot be reused to resubscribe someone.

Meet the mailbox provider requirements

The large mailbox providers now require this for bulk senders. Google's email sender guidelines say that starting 1 February 2024, senders of more than 5,000 messages a day to Gmail accounts must meet extra requirements, including that marketing and subscribed messages "must support one-click unsubscribe" and include a clearly visible unsubscribe link in the body. Google asks senders to keep spam rates reported in Postmaster Tools below 0.10% and never reach 0.3%. Yahoo's sender best practices similarly ask bulk senders to support one-click unsubscribe, to process unsubscribe requests within 2 days, and to keep complaint rates below 0.3%.

A sender's decision table

Where Safeguard fits

Safeguard does not read your email, block tracking pixels, rewrite links, or tell you whether a message is tracked, and nothing in the reader steps above depends on it. The fit is indirect and sits on the sender's side. Email programmes run on software: the web application that renders templates, the service that rewrites links and serves redirects, the unsubscribe endpoint, and the analytics code on landing pages. Those are built from open source dependencies like any other application. Safeguard scans repositories, container images and SBOM files, builds an inventory of the components they contain, and matches them against vulnerability databases, so a team running its own mailer or unsubscribe service can see which libraries and versions actually ship and which have known vulnerabilities. It does not judge whether your tracking is lawful or how much you collect; that remains a decision for your privacy and legal teams.

Common mistakes

Assuming small means tracking and big means safe. Any remote image can carry a per-recipient identifier, including logos and product photos. Judge by whether the image is remote, not by its size.

Thinking image blocking stops all tracking. It stops opens. It does nothing for tracked links, which record every click, and nothing for what happens on the landing page.

Visiting a tracked link to "check where it goes". Any request to the click server registers a click, even from a command line tool that does not follow redirects. Decode offline, or go to the site directly.

Adding senders to safe lists out of habit. In Outlook and other clients, safe senders get automatic image loading. That re-enables their pixels.

Treating prefetch opens as real reads. For senders, counting every privacy-protected delivery as an open distorts engagement reports, send-time tests and list cleaning. Segment or discount those opens.

Embedding the recipient's address in URLs. Plain or hashed, an address in a pixel or link URL travels to every host that handles the request, including proxies and relays. Use opaque tokens.

Building an unsubscribe link that requires logging in or redirects. CAN-SPAM forbids requiring more than an address and preferences to opt out. RFC 8058 forbids redirects on the one-click POST, and large providers require one-click support for bulk senders.

FAQ

How do I know if an email has a tracking pixel?

Save the message's raw source (in Gmail: More, then Show original, then Download original) and look for remote images, especially ones sized 1 by 1 or hosted on a domain different from the sender's website. The find_trackers.py script above lists them without loading anything. Any remote image with a per-recipient parameter can act as a pixel.

Can a tracking pixel give someone my exact location?

Not exactly. It gives your IP address, which IP geolocation databases map to an approximate city or region, or sometimes only to your network provider. Over many opens, though, IP addresses can reveal patterns such as home and work networks. Through an image proxy or Apple's relays, the sender sees the provider's address, not yours.

Does Gmail block tracking pixels?

Gmail does not block images by default; it loads them through Google's own proxy servers, so the request comes from Google rather than from your device and your IP address is not in it. The sender can still see that the uniquely addressed pixel was fetched. To stop the open being reported, set Images to "Ask before displaying external images" in Gmail's settings.

What does Apple Mail Privacy Protection actually do?

According to Apple, Protect Mail Activity downloads remote content in the background when a message arrives, whether or not you open it, and routes it through two relays run by different entities, so the sender cannot tell when you opened the message or learn your IP address. Apple says it does not cover links or attachments.

Does opening an email in the preview pane count as opening it?

If the preview pane renders the HTML and loads remote images, yes: the pixel is fetched the same way. If your client blocks remote images, a preview loads nothing. In Outlook, choosing Download Pictures in the Reading Pane saves that choice for the message.

Are email tracking pixels legal?

It depends on where you and the sender are. In the EU, the EDPB's 2024 guidelines say Article 5(3) of the ePrivacy Directive applies to tracking pixels, which generally means consent is needed. The UK ICO says PECR regulation 6 applies to email pixels that store or access information on a device. The US CAN-SPAM Act does not address open tracking but sets rules for headers, identification and opt-outs.

Can I block tracked links as well as pixels?

Mail client settings do not stop click tracking. You can avoid it by decoding the destination offline, hovering to check the host, or going to the website directly instead of clicking. Some organisations' mail systems rewrite links for their own inspection; that wrapping is separate from the sender's tracking.

Why are open rates so inaccurate now?

Because "open" now mixes real reads with provider prefetches (which make every message look opened), proxy fetches (which hide repeat views and location) and blocked images (which hide real reads). That is why many senders measure clicks, replies and conversions instead.

Does replying to or forwarding an email trigger the pixel?

Replying is a separate message and does not itself fetch anything from the sender. Forwarding can: if the recipient of your forward loads remote images, the original pixel URL, with your token in it, is fetched from their device. Apple lists forwarding among the things senders may learn.

Is reading email in plain text the most private option?

For opens, yes: a plain text view fetches nothing remote, so there is no pixel to load. It does not protect clicks, because tracked URLs remain in the text, and some messages are hard to read without their HTML layout.

Fix it without waiting for upstream

The software behind an email programme (template renderers, link redirect services, unsubscribe endpoints and landing page code) is assembled from open source dependencies, and when one of them carries a known vulnerability it needs the same treatment as any other part of your supply chain. The fit with email tracking itself is indirect, but keeping the services that handle your recipients' data patched and inventoried is part of running a mail programme honestly; the fork and patch route described below is early access.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It asks the assistant to fix a lodash CVE in a repository, reads the finding and advisory, asks before each command, edits package.json to a fixed version, and runs npm install and npm test with approval, pushing nothing. The same flow applies if a scan of your unsubscribe service or link redirect service shows an outdated dependency: you ask for the upgrade and approve each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and then scans from the terminal. It suits a team that wants an inventory of the packages inside its mail templating and tracking services before a privacy review, scanning on its own hardware.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It helps when you want to ask an assistant which of your projects carry a given library version while you work through the sender checklist above.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• EDPB: Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive (version 2.0, adopted 7 October 2024)
• EDPB: Guidelines 2/2023, version 2.0 (PDF)
• ICO: Guidance on the use of storage and access technologies
• ICO: What are storage and access technologies?
• ICO: How do the PECR rules relate to the UK GDPR?
• ICO: Cookies and similar technologies (Guide to PECR)
• Apple: Mail Privacy Protection & Privacy (legal notice)
• Apple iPhone User Guide: Use Mail Privacy Protection on iPhone
• Apple Newsroom: Apple advances its privacy leadership with iOS 15, iPadOS 15, macOS Monterey, and watchOS 8 (7 June 2021)
• Official Gmail Blog: Images Now Showing (12 December 2013)
• Gmail Help: Choose whether to show images
• Gmail Help: Trace an email with its full headers
• Google Workspace Admin Help: Email sender guidelines
• Yahoo Sender Hub: Best practices
• Microsoft Support: Block or unblock automatic picture downloads in email messages
• RFC 8058: Signaling One-Click Functionality for List Email Headers (January 2017)
• RFC 2369: The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields (July 1998)
• W3C: Tracking Preference Expression (DNT), Working Group Note, 17 January 2019
• US Code, Title 15, Chapter 103: Controlling the Assault of Non-Solicited Pornography and Marketing (CAN-SPAM)
• eCFR: 16 CFR Part 316, CAN-SPAM Rule (fetched through the eCFR renderer API)
• Englehardt, Han and Narayanan: I never signed up for this! Privacy implications of email tracking (PoPETs 2018)

Related reading: how to replace Gmail with private email, browser fingerprinting explained, tag manager glossary: tag, pixel, container, data layer and CMP, DMARC alignment, relaxed versus strict and Global Privacy Control opt-out signals.

Last reviewed: 24 October 2026. Mail client settings and regulator guidance change; check the documentation linked above for the version you use.