Short answer: it can tell you roughly where a network request came from, and that is frequently
not where the person is. Some tools present that guess as a city on a map. The honest description
is that you are looking at the location of a network, sometimes a data centre, and only sometimes a
human being.
Here is what actually arrives, and the four reasons the city on the map is unreliable.
Does email tracking record the recipient's IP address?
Open tracking works by putting an image reference in the message. When something fetches that
image, the sender's server receives a request. That request carries a token, a timestamp, an IP
address and a user agent string.
The IP address is the only part with any geographic content, and it is the address of whatever made
the request. Turning it into a city means looking it up in a database that maps address ranges to
places. Those databases are decent at country level and much weaker below it.
So the chain is: something fetched an image, it had an address, and a database has an opinion about
that address. Every link in that chain can be right while the conclusion is wrong.
Reason one: provider side image proxies
Several mail providers fetch remote images on their own servers and serve a cached copy to the
recipient. When they do, the request that reaches you comes from the provider's infrastructure.
The address then belongs to a data centre, and the city you see is wherever that data centre is.
It has no relationship to the recipient's location at all, and it will be stable and wrong for
every message you send to that provider.
Reason two: mobile networks
On a phone, the traffic usually leaves through the carrier's network, and carriers aggregate
traffic through a limited number of egress points.
The result is that a person reading in one town regularly appears in another, sometimes a few
hundred kilometres away. This is not an error in the database, it is what the address genuinely
belongs to.
Reason three: corporate networks
If your recipient works somewhere with centralised egress, every one of their requests appears to
come from wherever the company routes its traffic. Head office, or a cloud region.
Two colleagues in different countries can produce identical locations, and a person working from
home through a company tunnel produces the office.
Reason four: privacy relays and VPNs
These exist specifically to make the address uninformative, and they are now on by default for a
meaningful share of users. When one is in play, the location you get is the relay's.
There is no way to detect this from your side with any confidence. You receive an address; you do
not receive a note saying it was borrowed.
What is left that you can actually use
Country, sometimes, and with less confidence than you would like.
A change in the pattern, occasionally. If every open on a thread has come from one place and one
suddenly comes from another, something changed. What changed is undetermined: a phone instead of a
laptop, a train, a forwarded copy read by a colleague, or a provider rerouting.
That is genuinely all. If you were hoping to learn that a client read your proposal from their
office rather than at home, the mechanism cannot support that inference, and any interface that
implies it can is dressing a guess as a fact. The proposal case has its own write up, what an open
tells you and the one thing you must never do with it.
The part that is about the recipient, not about you
Location is the piece of this that people find most uncomfortable when they learn it exists, and I
think that reaction is reasonable rather than naive.
A recipient who opens an email has not agreed to tell you where they are. The address arrives
because that is how the web works, not because anyone chose to share it. Presenting it as a feature
turns a transport artefact into a claim about a person's whereabouts.
So the question I would ask of any tool in this category, mine included, is not how accurate its
location data is. It is whether it should be showing it at all, and what it does with the address
once the request is handled.
What I would want stated on any product page
Whether the tool derives and displays a location from the IP address. Whether it stores the address
after handling the request, and for how long. And whether it will tell the recipient any of this if
they ask.
Mine shows a count of fetches for your message, and its privacy page states that no IP addresses
are stored. I would rather report that plainly than turn a data centre in another country into a
pin on a map.
Disclosure
I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in
your Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the
free tier covers 30 emails a month. It does not ask for OAuth access to your Google account and it
does not read the content of your emails. You can find it at
blueticks.io.
Everything above is a property of how the technique works rather than of my product: an IP address
is what the transport hands you, and no tool can make it mean more than it does.
Top comments (0)