You send a message to a business contact and get a reply within an hour of them opening it. Then you wonder how they knew you opened it. The answer is probably a tiny invisible image, and the mechanics behind it say a lot about how much a plain email can reveal.
A tracking pixel is a picture file, usually a 1×1 transparent PNG or GIF, embedded in an email. The image isn’t attached. It sits on the sender’s server, and the email contains only a link to it. When you open the message, your mail app requests that file. The request carries the same information every HTTP request carries: your IP address, your user agent string, your language settings, and the time to the second. The sender’s server logs that request. That single log line is the read receipt.
The link also contains a unique token, so the sender knows exactly which recipient opened it. If a marketer mails 5,000 people, each person gets a pixel URL with a different identifier. One open equals one row in a spreadsheet with your email address, your IP, your device, and the timestamp.
What the sender actually learns
The raw log line is more revealing than most people expect.
Your IP address narrows your location to a city in most cases, sometimes to a district. Home and mobile IPs are assigned in blocks to specific providers and regions, so the sender gets at least your rough area, and with a business connection, often the name of your employer. Your user agent reveals the device and app: iPhone Mail, Outlook on Windows, Gmail in Chrome. Combine that with an open at 23:40 from a residential IP and the sender can guess that you read work mail from home at night.
Open time builds a behaviour profile. Marketers track when you habitually open mail and schedule future campaigns to that window. If you open a message three times before clicking, the sender sees all three.
None of this requires sophistication. The tracking is built into mainstream bulk-mail tools like Mailchimp, Brevo and HubSpot. A free plan is enough, and the pixel itself is tiny, often under 50 bytes, though a newsletter full of hosted images can add 2 MB to every single open.
When the pixel fails
The system has real gaps, and they cut both ways.
Gmail has proxied images through Google’s servers since 2013 (and never made it optional). Your mail client never touches the sender’s server; Google fetches the image once and serves the cached copy. The sender sees a Google IP and an open time that reflects Google’s fetch, not necessarily yours. Gmail also pre-fetches images for some messages, which can create phantom opens before you read anything.
Apple went further with Mail Privacy Protection, introduced in 2021 (with iOS 15). Mail on iOS and Mac can be set to download all pixel content in the background through Apple’s proxy, regardless of whether you open the message. Senders see an Apple relay IP and an open event that may be automatic. For mail to Apple users, open rates have been largely meaningless since then, which means open rates recorded before and after the change aren’t comparable numbers. Many bulk-mail tools now discount Apple opens in their reports for exactly this reason.
When I tested this on my own mail, the pattern was easy to confirm: three newsletters opened on the same morning showed the sender three opens from one Apple relay IP within minutes of each other, and only one of them had actually been read.
Plain-text email and clients with remote images disabled defeat pixels entirely, because nothing is fetched. No fetch, no log line, no receipt.
The defensive options, honestly stated
Disabling remote images by default is the cleanest fix. Every major client supports it: Gmail and Outlook on the web have a setting to ask before loading external content, Thunderbird blocks remote images by default, and Apple Mail offers the load-remote-content toggle per message. The cost is real too: newsletters with charts and photos arrive as broken boxes until you approve them. Most people who turn images off permanently end up switching back within weeks.
A proxy service such as DuckDuckGo’s email protection strips pixels before mail reaches you. It works, but it adds a relay address between you and your correspondent, which is its own trade-off.
The practical middle ground is to allow images from real correspondents and block them for anything bulk. If a newsletter asks you to click images to confirm you read it, treat that click itself as a tracking event, because it often is. A click is a far stronger signal than an open anyway; it confirms a human,.
None of these measures hide the fact that you received the mail. The sender always knows the address was delivered. What pixel blocking removes is the timing, the location, and the device fingerprint that comes with an open.
Why this sits next to other tracking you already have
Pixels are one thread in a wider fabric. If you use encrypted DNS, your ISP can still see which services you connect to, as we covered in our explainer on what DoH actually hides. Push notifications leak metadata about your phone even while the screen is off, as we wrote in our piece on phone metadata. The pattern is the same in all three: the content stays private in a narrow technical sense, and the surrounding metadata does the work. An email tracker doesn’t read your words, and it doesn’t have to. The IP address and the clock do the job.
If you want a single rule to take away: assume every commercial email you open tells the sender when and roughly where you opened it, unless you have specifically switched remote images off. Most of the time that’s an acceptable trade. Knowing it’s happening is the part that matters, and that part costs one setting change.
What most readers should actually do
You don’t need to panic about pixels. If you run a business and your opens feed someone’s drip campaign, block remote images in your mail client on the phone and the laptop. If you’re a regular user who reads newsletters, leave images on and accept the profile, or turn on Apple’s Mail Privacy Protection and let it fuzz your opens automatically. Both are reasonable. The only bad option isn’t knowing the pixel exists.