You open a newsletter on the bus. Before you have read the first line, the sender knows the message was opened, roughly where you were, what device you were holding and the time to the second. Nobody asked you, and nothing on the screen told you it happened.
None of this is clever. Email tracking is built from two ordinary web features: an image that loads from someone else's server, and a link that goes somewhere else before it goes where it says. Both have existed since HTML email existed. Both cost the sender almost nothing to run across a million recipients.
What follows is what each technique actually reports, what you can switch off in your own mail app in about two minutes, what a paid service adds on top, and the parts that nothing can fix. The last section is the one worth reading twice.
How a 1x1 tracking pixel reports on you
A tracking pixel is an image tag pointing at a URL on the sender's tracking server. The image is normally one pixel square and transparent, so you never see it. The picture is not the point. The request is the point.
The URL carries an identifier that is unique to you. Not unique to the campaign, unique to this campaign sent to this address. When your mail app fetches that image, the tracking server writes a line in a log, and that line contains more than most people expect.
- That the message was opened at all, tied to your address by the identifier in the URL
- The time of the fetch, to the second
- The IP address that made the request, which maps to a rough location and to your broadband provider or mobile carrier
- The User-Agent string, which usually names your mail client and operating system, and often the device class
- Every later fetch, so re-opens show up as separate opens, and a forwarded message can register as opens from a second person
Two things soften this in practice. Gmail routes remote images through Google's own servers, so the IP the sender records is Google's rather than yours, and Google caches the image, which makes later opens unreliable. Apple's Protect Mail Activity goes further and fetches remote content in the background whether you open the message or not, which means the sender gets an open event that has nothing to do with you reading anything.
So the marketing dashboard is noisier than it looks. It is still worth stopping, because even a poisoned open tells the sender that the address is live and monitored. That is exactly why spam campaigns use pixels too: not to measure engagement, but to sort dead addresses from real ones before selling the list on.
Link tracking parameters and what they add
Link tracking comes in two shapes, and commercial email usually uses both at once.
The first is a rewritten link. The text says example.com, the actual target is a tracking domain that logs the click and then redirects you. You can see it by hovering: the status bar shows a host you have never heard of and a long string of characters.
The second is parameters bolted onto the end of a real URL. The familiar ones are campaign tags: utm_source, utm_medium, utm_campaign, utm_content and utm_term. On their own these describe the campaign, not you. The ones that describe you sit alongside them, things like mc_eid from Mailchimp or mkt_tok from Marketo, or an opaque identifier with no obvious name. Those are per recipient. Advertising identifiers such as gclid and fbclid can also ride along and connect the visit to an ad profile.
A click reports much more than an open. It proves a human acted rather than a preview pane loading. It hands your address, or its internal identifier, to the destination site at the moment you arrive. And it lets that site set cookies and join the visit to any account you happen to be signed into there.
Crucially, a wrapped link is immune to image blocking. It fires when you click, not when you view. Any advice that stops at "turn off images" has covered half the problem.
Unsubscribe links deserve a note of their own. They are always unique to you, because that is how the sender knows which subscriber to remove. For a legitimate company, clicking is still the right move and you should do it. For obvious spam it confirms the address is live and read, which is the one thing you did not want to confirm. If your mail app shows a native unsubscribe button at the top of the message, prefer it. That button uses a header the sender publishes for the purpose rather than a link inside the body.
Read receipts, and how they differ from pixels
A read receipt is the formal, standardised version of the same question, and it behaves in almost the opposite way. The sender's client adds a Disposition-Notification-To header. Your client sees it and is meant to ask you whether to reply.
RFC 8098, the specification for message disposition notifications, is explicit that this should not be silent. It says it is "strongly recommended that the user agent obtain the user's consent" before sending one, and that the default should be not to send.
- A read receipt is a request that you can decline. A pixel never asks.
- A read receipt is visible. Your mail app tells you it was requested.
- A read receipt reports a disposition, such as displayed or deleted. It does not report your IP address, your location or your device.
- Many clients ignore the header entirely, so a sender cannot rely on it.
- Inside one organisation this can differ, because an administrator may set the policy for everyone and the receipt can go back without prompting you.
That contrast explains why marketing email almost never uses read receipts. A mechanism that asks permission and can be refused is useless for measuring a mailing list. The pixel exists because it does not ask.
Fix 1: block remote images
This is the highest value change on the list and it is free. It takes one setting in each mail app you use, and it has to be done in each one, because the setting lives in the client rather than in your account.
Gmail on the web: click the gear icon, then See all settings, then the General tab. Under Images, select "Ask before displaying external images" and click Save Changes at the bottom. In the Gmail mobile app: menu, Settings, tap the account, then Images, then the same option. One side effect worth knowing is that this also turns off dynamic email.
Classic Outlook for Windows: File, Options, Trust Center, Trust Center Settings, then the Automatic Download tab. The box you want is "Don't download pictures automatically in standard HTML email messages or RSS items", and Microsoft ships it ticked. Check the sub-options underneath, because downloads are still permitted for senders on your Safe Senders list and for content in trusted zones. The new Outlook for Windows and Outlook on the web do not currently expose an equivalent switch.
Apple Mail on Mac: Mail, Settings, then the Privacy tab. There are two different protections here and the difference matters. Protect Mail Activity hides your IP address and downloads remote content privately in the background, which conceals you but still generates an open for every message that arrives. If you want no fetch at all, untick Protect Mail Activity, then tick Hide IP Address and Block All Remote Content. You then get a banner on any message with remote content and you decide per message. On iPhone and iPad the same choices sit under Settings, Apps, Mail, Privacy Protection on recent versions of iOS, or Settings, Mail, Privacy Protection on older ones.
Thunderbird blocks remote content by default and shows a bar at the top of the message when it has done so. If someone has turned it off, it is under Settings, Privacy and Security.
What you give up is small but real. Some newsletters look broken until you allow images, and every message carrying remote content gives you a banner to click before it renders in full. The trade is one extra click on the messages you actually wanted to look at.
Fix 2: services that strip trackers before delivery
A forwarding or alias service sits between the sender and your inbox, which means it can edit the message on the way through. It can remove image tags that point at known tracking hosts, unwrap redirect links back to their real destination, and drop tracking parameters before you ever see them.
The advantage over a client setting is that it applies everywhere at once, including the phone app you forgot about and the webmail you use at work. It is also the only one of these approaches that touches links, which image blocking never does.
Where a service offers this, check how it is switched on before you assume you are covered. Some providers apply it to everything arriving in your account, while others make it a per alias setting that stays off until you enable it. Find out which kind you are dealing with, because on the second kind, turning it on for the addresses you care about is a step you have to take yourself.
Three honest limits. Stripping works from a list of known trackers and patterns, so a novel tracking host, or a pixel served from the sender's own domain, can walk straight through. Rewriting HTML occasionally breaks a message layout. And a service that edits your mail has to read your mail, so you are trading one exposure for another and should pick a provider that documents what it keeps and for how long.
There is also a plain case for not paying anyone. If you read mail in one app and your only goal is to stop open tracking, the free setting in the previous section does the job and a subscription adds nothing. A stripping service earns its money when you read mail in several places, when you want links cleaned as well as pixels, or when you already want aliases for other reasons and this comes along with them.
Fix 3: stripping tracking parameters in the browser
Once you have clicked, the request has happened. What you can still control is how much of the tag follows you onto the site, and what gets carried along when you copy a link and paste it to someone else.
Firefox strips known tracking parameters from URLs when Enhanced Tracking Protection is set to Strict, under Settings, Privacy and Security. Mozilla's documentation describes the released version as working from an initial list of parameters, with a longer list running in Nightly, controlled by the privacy.query_stripping preferences. Firefox also offers "Copy Link Without Site Tracking" in the right click menu, which is the useful half of the feature for everyday use.
Recent versions of Safari remove known tracking parameters from links opened in Private Browsing, and from links in Mail and Messages. Brave strips a list of parameters by default and has a clean copy option. Chrome has nothing built in, so it needs an extension such as uBlock Origin or ClearURLs.
The limitation is the same everywhere: these tools work from a list. They remove parameters somebody has already catalogued. They will not remove an unnamed identifier a sender invented last week, and they cannot remove an identifier that is part of the URL path rather than the query string.
The manual version costs nothing and always works. For a link you do not trust, copy it, delete everything from the question mark onwards, and paste that. The page will usually load exactly the same. If it does not, the parameter was doing real work and you have learned something.
What no tool can stop
This is the part most guides skip, and it is the reason to aim for a realistic target rather than zero.
A click is a visit. The destination server logs your IP address, your user agent, the time and the exact URL you asked for. Stripping utm_source changes what the site's analytics can attribute. It does not make the connection invisible, because the connection is the whole mechanism.
A unique URL per recipient defeats parameter stripping completely, because there is no parameter to strip. If the link is example.com/r/8fJq2Xb, the identifier is the address itself. No filter can tell that apart from an ordinary short link, and stripping it would break the page.
That pattern is not rare. Password resets, order confirmations, booking references and unsubscribe links all have to be unique to you, because being unique to you is their function.
- Forwarding a tracked message hands your unique URL to someone else, and their open or click is recorded as yours
- Replying tells the sender everything a pixel would have, and more
- Loading remote content inside a webmail you are signed into lets that platform associate the fetch with your account
- The receiving mail server knows the message was accepted, whatever your client does afterwards
There is also a limit that no tracker blocker addresses at all. Blocking pixels controls what one sender learns about your behaviour. It does nothing about the fact that a hundred companies hold the same address for you, which is what lets a broker join those records together. That is a separate problem with a separate fix, which is not handing the same address to everyone, and it is worth knowing the two are not substitutes.
The sensible goal is this: the silent default case stops, and the tracking that remains is tracking you chose by clicking something.
How to test whether you are being tracked
You do not need a tool for this. Pick three commercial emails sitting in your inbox and look at them properly.
- Open the raw source. In Gmail on the web it is the three dot menu, then Show original. In Apple Mail on Mac it is View, Message, Raw Source. In Thunderbird it is Ctrl and U. In classic Outlook, open the message, then Actions, Other Actions, View Source.
- Search the source for img and read what you find. A tag with width="1" and height="1", or a filename like open, pixel, beacon or o.gif, or a src ending in a long random string, is a tracker.
- Compare the image host with the sender's domain. A newsletter from a company you know that fetches an image from a marketing platform's domain has just told you which platform is counting.
- Search the headers for Disposition-Notification-To. If it is there, the sender asked for a read receipt, and your client should have prompted you.
- Hover over the links without clicking. If the target host does not match the visible text, the link is wrapped and the click is logged before you arrive.
- Turn images off, then watch which messages show a blocked content banner. Nearly all commercial mail will, and the ones that do not are usually plain text.
If you run a website, you can watch the whole thing happen. Put an image hosted on your own server into a test message, send it to yourself, and read the access log. You will see the fetch, the IP address, the user agent and the timestamp arrive within seconds of opening the message. It is a five minute exercise and it makes the abstract concrete in a way no article can.
Do this once on a handful of messages and you stop needing to. The shape of a tracked email becomes obvious from the sender and the subject line alone, and the settings you changed in the first fix are already doing the work quietly in the background.