How does email tracking work?
A tiny image creates a network request. The difficult part is deciding what that request actually means.
How does email tracking work behind the scenes?
A typical system inserts a remote image reference into an HTML message. Its URL includes an opaque identifier associated with that message. When a mail application requests the image, the receiving server can record the identifier and request time, then return the image.
The backend turns these request records into an activity timeline. A browser extension may add controls to an inbox, while a notification service delivers alerts. These are separate components: neither a static website nor a generated image tag provides the entire service.
Message → image request → server record → interpreted signal. The final step is an inference, not proof of attention.
The identifier has a limited job
A random ID allows a service to distinguish one message from another without placing a recipient address in the URL. It does not prove who requested the image. Forwarding can cause another reader to load the same address, and multiple recipients can share one message identifier.
Before associating events with a specific person, ask how the provider handles forwarded mail and group messages. A dashboard may look precise while the underlying evidence is ambiguous. Time, location, device labels, and counts all need an explanation of their limitations.
Privacy features change the signal
Apple documents that Mail Privacy Protection can fetch remote content in the background regardless of whether the recipient engages with a message. That can create a request without a person opening the email. It also hides the recipient's IP address.
Image blocking can create the opposite problem: someone reads the text without generating a request. Caching and proxy services can also change the number and timing of observable events. A missing event is not proof that a message was ignored.
Source: Apple's explanation of Mail Privacy Protection.
Read receipts are a different mechanism
An explicit receipt is a response from the recipient's email system. In eligible Gmail work or school accounts, a sender can request a receipt, but the recipient or administrator may affect whether it is returned. Personal Gmail accounts do not offer this built-in feature.
Even an explicit receipt should not be treated as a delivery certificate or a guarantee of reading. Google explains that an email can be marked read without being opened in some clients. For an important decision, a direct reply remains much more useful.
Source: Google's read receipt documentation.
Inspect the code without sending anything
If you are asking “how does email tracking work?” from a technical perspective, start with the markup. This builder creates a snippet for your own endpoint. It does not make a request, collect an event, or connect to Gmail.
Code only. Your server must record requests and return an image.
No email is sent. We never load the generated pixel or contact your endpoint.
Use less data, and interpret it carefully
Decide which information you actually need before deploying collection. Avoid putting personal information in image URLs, document retention rules, and make your practices understandable to recipients. Requirements depend on context and jurisdiction; installing software does not settle those obligations.
Use activity as one input alongside replies, deadlines, and the existing relationship. Do not write that someone definitely read a message simply because a tool showed an event. Good follow-ups should make the next step easier for the recipient.