What one open puts on the record

A tracking request is an ordinary web request, and web servers log requests in detail. This is the payload of a single open, with nothing exotic added:

Field Where it comes from What it reveals Real precision
RecipientID or address in the pixel URLExactly which contact in the list actedExact — that is the point of the parameter
TimestampServer clockWhen, to the second, and how oftenExact
IP addressThe connection itselfNetwork, and therefore an approximate placeExact address; the location derived from it is city-level
City and regionGeolocation lookup of that IPHome versus office; a trip; a countryCity or region, sometimes only the metro area
User agentRequest headerMail client, OS, device family, app versionDevice class and client, not the individual handset
Open countSame ID requesting againRe-reading, forwarding, checking a phone and a laptopExact count of requests
ClicksWrapped link, separate requestWhich link, in what order, how long after the openExact for links the tracker owns
Screen or window sizeOptional parameter in the URL, if the client sends itPhone versus desktop, sometimes window stateApproximate, and frequently absent
Language and timezoneRequest headers, if presentWorking language and a rough region checkClient default, not necessarily you

Which rows exist depends on the client. A proxy that fetches images on your behalf replaces the IP row with its own address, and a client that refuses remote content leaves the timestamp, IP, city, user agent and count rows empty — the recipient row is still in the URL, it simply never gets used.

Your IP address, and what a city lookup really says

The IP is the most valuable field for the sender and the most misunderstood by recipients. Geolocation services map address blocks to registered locations, which for home and mobile connections is a city, a region and an ISP — not a street. What that city-level value buys a sender is often enough anyway:

  • Home or work. An open from the office block at 9:15 on Tuesday is a different signal from the same message opened from a residential block at 22:40. Lead-scoring tools use exactly that difference to decide whether you are a professional contact or a person browsing.
  • Travel. The same recipient opening from two countries in a week is a pattern no ID could tell them.
  • Your employer, indirectly. A corporate IP block is registered to the company. If the message was addressed to [email protected], the block confirms the employer relationship and shows you are on-site.
  • Mobile versus fixed. Carrier NAT ranges say you were on a phone network, which combined with the user agent narrows the device to one in your pocket.

What the IP does not do: it does not identify a household to a stranger, it does not give a GPS position, and it is only as precise as the registry data behind it — which is frequently wrong by tens of kilometres.

The device signature that follows you between apps

The User-Agent string is a plain-English description of your software, and in mail it is unusually informative because client versions change on a schedule:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15
  (KHTML, like Gecko) Version/17.4 Safari/605.1.15

→ macOS, Intel Mac, Safari-based Mail, iOS 17-era WebKit — all from one header

Combined with the timestamp, the user agent tells a sender whether you read on a phone in the first ten minutes or on a desktop at your desk, which is how “opened on mobile, clicked later on desktop” sequences get reconstructed. It is also the reason an alias or a different client changes what a tracker can stitch together: the device signature stops being a constant.

Timing: the pattern that identifies you without your name

Even with no recipient ID at all, timing is a fingerprint. A contact who opens tracked mail at 08:35–08:50 on weekdays, once in the evening around 21:00, and never on Sundays is a schedule. Senders do not need the schedule for its own sake — they use it to decide when to send the follow-up — but the accumulated record is a behavioural profile, and it is stored beside your address in the same row.

Re-open counts add the second layer. Mail clients re-fetch images whenever a message is re-rendered, which means the count includes opening a thread on a phone, then a laptop, then a tablet, and includes re-renders caused by nothing more than resizing a window. A dashboard that says “opened 7 times” is usually saying “rendered 7 times”.

Your address is the join key

Everything above is per-message. The reason the rows accumulate into a profile is one parameter: the recipient ID. It is a foreign key into the vendor’s contact table, which means:

  • Campaigns stitch together. The same contact row is written by every send from that vendor for as long as you stay on the list, so ten campaigns become one timeline.
  • Vendors stitch across customers. A tracking company serving many senders can, depending on its own terms, match the same address appearing in different lists. Two unrelated companies emailing you through the same platform is two data streams for that platform.
  • The web side joins the mail side. Campaign parameters survive into the destination site’s analytics, so an email open, a pricing-page visit and a demo booking get attributed to one session. A cookie set on arrival ties it to your browser.
  • Replies close the loop. A tracked thread often puts the same identifier in the reply path, so answering confirms the whole sequence without another image being fetched.

This is the mechanism worth defending against, more than any individual pixel: not that one message watched you, but that your address is the primary key that makes watching additive.

What the headers say before you open anything

Some of the record exists in the message itself, which means it was collected about the sender, and about you the moment you reply or forward. Reading headers is the part of this most people never do, and it is the fastest way to learn what a mail system exposes.

Header Typical value What it tells you
ReceivedChain of hops with hostnames and timesThe sender’s mail infrastructure, and which provider they actually pay
X-MailerA vendor product nameWhether a bulk platform or a personal client produced the message — bulk platforms track
Return-PathBounce addressWhether the sender owns the domain they appear to write from; a mismatch is a flag
Authentication-Resultsspf=pass dkim=pass dmarc=passWhether the displayed sender is proven. A fail means the tracking claims are nobody’s to trust
List-UnsubscribeHTTPS and mailto URLsThat there is a route out, and whether it is one-click under RFC 8058
List-IDMachine-readable list nameWhich of a vendor’s lists you are in, useful when the visible sender is generic

Your own reply adds Message-ID, a timestamp, and whatever your client volunteers: User-Agent, X-Mailer, your outgoing mail server’s hostname, and sometimes a References chain that hands over the entire prior thread text.

What a tracker cannot see

The limits matter as much as the capabilities, because most of the fear attached to email tracking is about things that are not technically possible from a pixel.

  • Your other email. A tracker sees only requests its own URLs generate. It has no view into your inbox, folders or labels.
  • Your screen or files. Mail clients render HTML without running scripts. Gmail strips JavaScript entirely; Outlook’s renderer never executes it. There is no path from an image request to your disk.
  • Whether you forwarded it. Not directly. Forwarding re-sends the text including the pixel, so the next recipient’s client may fire a request that lands in the same log under the same identifier — which is a strong hint, not proof.
  • Whether you deleted it. Deletion produces no request. Absence of opens after a burst is an inference, not an event.
  • Your precise location. City-level at best, and only for the network that made the request.
  • Read receipts, as such. Webmail does not report reads back to senders. What looks like a receipt is a pixel log with a nicer label.

How the fields combine into three realistic profiles

The useful question is not “what can one field say” but what a sender with a year of your rows can answer.

Profile Fields that build it What the sender concludes
The sales prospectOpens, re-opens, pricing-page click, calendar link, replyHot lead, push for the meeting, forward the record to the account owner
The commuterMobile user agent, residential IP, 07:40–08:10 weekday timestampsBest send time; the newsletter list tunes its schedule to a stranger’s train
The dormant addressSix opens in eighteen months, no clicks, evening timestamps from one cityLow engagement, price the list accordingly, or sell the segment

None of those three profiles needed your name. They needed a stable ID and a few months of ordinary request logs.

How much of your mail is actually tracked

Do not take a percentage from this page — nobody can measure your inbox but you. The arithmetic is easy enough to run yourself once you have a count:

tracked mails per month = (mails you receive) × (share that contain a pixel)
→ 200 a month with 100 checked in the detector is a rate you can multiply by 12

The practical way to get your own number: run ten messages from a week through the detector and note how many score above zero, how many name a service, and how many put your address in a URL. If even a third of your mail carries an open pixel, a year of ordinary reading is a few hundred logged events with your location attached. That is the volume the profile is built from — not one sinister email.

measure your own exposure

Email Tracker Detector

Paste the raw source of a message and see which of the fields above a sender already holds about you: the pixel host, the recipient identifier, whether your address travels in the URL, and which links report back. Free, in your browser, no upload.

Inspect an email

faq

Frequently Asked Questions

The exposure questions, answered with the precision the data actually supports.

Does opening an email reveal my IP address?

Yes, whenever your mail client fetches a remote image directly. The HTTP request to the tracking host carries your IP address, and the server logs it with the rest of the request. Two providers change the picture: Gmail proxies images through its own servers, so the tracker sees a Google address, and Apple Mail Privacy Protection routes fetches through a proxy for the same reason. If your client loads remote content itself, your IP travels.

Can an email tracker find my location?

It can find the city or region your IP address is registered to, which is what geolocation databases resolve to for ordinary residential and mobile connections. That is enough to tell a home connection from an office one, or to notice that you were in a different city when you read the message. It is not a street address, and it is often only accurate to a metropolitan area.

What do trackers do with the data they collect?

Commercial senders use it to rank leads and time follow-ups: who opened, how many times, which links were clicked, whether a reply came back. That scoring decides whether you get another email. Vendor-side, your opens contribute to aggregate deliverability and campaign statistics, and a per-recipient identifier lets the same record be joined across campaigns so a profile builds up over months rather than messages.

Can a tracker see what I did after I opened the email?

Only through things it controls. A click on a wrapped link is visible because the request passes through the tracker, and once you land on the sender's own site their cookies and analytics continue to watch you there. What happens in another tab, in your other mail, or on your machine is not observable from an email pixel. There is no channel from your mailbox back to the sender after the requests stop.

Is open tracking personal data under GDPR?

Yes, when it is attached to an identified or identifiable person, which is what a recipient ID in a pixel URL does. EU guidance and the Court of Justice have treated the loading of a tracking image as storing information on the recipient's device, which brings it inside the consent requirement of the ePrivacy Directive's Article 5(3) — the same rule that governs cookies. The Court made that point in Case C-80/18 in October 2021.