Knowledge base

See when mail you sent was opened

Whether a message you sent has been opened, when, how many times and which of its links were followed. On unless you turn it off, and plain about the readings it cannot get.

Details

Two switches rather than one, and both are on unless the mailbox turns them off. Opens and clicks are two different bargains with the person receiving the mail. A pixel reports that a message was displayed and nothing else, while a rewritten link routes an actual visit through us, and plenty of senders want the first and refuse the second. A message sent with both off carries no pixel, no rewritten link and no row claiming it was tracked. A send through the API names tracking: { opens, clicks } to decide for that one message instead of for the mailbox, and it decides in both directions: a program that wants nothing recorded says so per message and gets that, whatever the mailbox is set to.
Either switch decides what your NEXT message carries and nothing else. Mail already sent keeps the pixel and the rewritten links it went out with, and goes on reporting after the switch is off, and the only way to stop it would be to break the links in messages people are already holding, which is a worse thing to do to a reader than to carry on counting. Turning tracking off is a decision about what leaves from now on; there is no recall.
No IP address is stored for an open or for a click, and there is no column to put one in. What is kept is what the edge already knew before the request reached us (a country, a region, a city, a time zone, none of them looked up to obtain), plus a SHA-256 fingerprint of the address and the user agent, salted with a value that turns over at midnight UTC. The hash is what lets a report say two devices rather than two opens, and a day later it cannot be matched back to an address by anyone, us included. Read the location as a fact about the network rather than about the person: anybody behind a VPN or a corporate proxy is reported somewhere they have never been.
Two kinds of record sit behind the numbers. A hit row carries a user agent, a city and a fingerprint about somebody who never agreed to be measured, and it exists to answer the questions asked in the days after a send: was that a scanner, which device, was it really them. The other kind is the reading itself (first, last and a count, per message and per link), which is a fact about your own mail rather than about the person who opened it.
Automated fetches are recorded and then not counted, which is a different thing from being thrown away. Apple’s Mail Privacy Protection downloads every remote image in every message on delivery whether or not a person looks at it. It is on by default, and counting it hands every sender an open rate near 100% that means nothing, so it is recognised from the user agent and from the network the request came out of, and marked as a machine. Corporate scanners, link checkers, headless browsers and anything arriving within ten seconds of the send are marked the same way, because nothing a person does happens that fast. The user agent is kept exactly as it arrived, alongside what was read out of it, because that string is what the call was made from and a call nobody can check against its input is a call nobody can correct. A client may write anything there and many of them say almost nothing, so it is a claim rather than a fact. The report prints how many were filtered out rather than leaving an unexplained gap between the log and the total.
Gmail is a third case and is reported as one. Its image proxy fetches because somebody displayed the message, so the open is real while the device, the location and the client are simply not knowable, and the proxy caches, so the second and third reading may never reach us at all. An open count through Gmail is a floor, not a total.
No open recorded is not evidence that a message went unread. Blocking remote images is ordinary, since plenty of clients ship with it on and every other one offers it, and it suppresses this completely, so silence here is no evidence in either direction, and it is the answer you will get most often. Nothing in the product renders an untracked or unreported message as “not opened”, because that would be reading a refusal into an absence.
A click is stronger evidence than an open, so the two are never merged into one number. Images are blocked far more often than links go unclicked, which makes a message with clicks and no opens one that has certainly been read. Up to 100 destinations per message are rewritten, once each. The same campaign page linked from a header image, a button and a footer is one row with its own count, because it is one question asked three times, and a report can say which link was worth following rather than that something somewhere was followed. Past that cap the remaining links are left exactly as they were written rather than dropped, since an untracked link still works and a message that quietly loses two hundred of them does not.
A rewritten link cannot be pointed anywhere we did not put in the message ourselves. The destination is held in a row and the URL carries only its id, so there is no query parameter to tamper with and nothing here can be turned into an open redirect on a mail provider’s domain, which is the raw material phishing campaigns are built from. The redirect is a 302 rather than a 301, because a permanent one is cached by the browser and by every proxy in between and the count would stop at one and stay there. A link whose message has since been deleted says the address no longer points anywhere rather than answering a bare 404.
Only the new part of a reply is rewritten; the quoted history under it is somebody else’s message and their links stay theirs. The copy filed in Sent has the pixel taken out and every link put back the way you typed it. Without that, forwarding your own sent mail forwards a recipient’s token to a stranger, clicking a link in your own outbox records the recipient clicking it, and the copy you keep is not what you wrote.
A message with one recipient always names them: there is nobody else it could have been. Past one, naming which recipient opened it means giving each person their own copy of the body, which is only done on a message small enough that rebuilding it per person is affordable: the estimated size multiplied by the number of recipients has to come in under 8MB. Past that budget, and on a sealed message whose single block of ciphertext cannot vary per person, one body goes to everyone, and an open is recorded as someone on this message rather than a name picked out of the list. Two people opening within thirty seconds of each other count as one reading there, which is the same limitation said a second way. Thirty seconds is the window in every case: a preview pane redrawing, or a message scrolled back into view, refetches the image and is not a second reading.
Mail from one OpenEmail mailbox to another reports its opens from the reader itself. The reader here strips any 1×1 image out of every message before it reaches your screen, ours included, so the pixel is never fetched. When a message is displayed with remote images showing, the reader records the open against the copy that mailbox received and names the client as OpenEmail. A reader who keeps images hidden registers nothing, the same as any other client that blocks them. Links are not stripped by anything, so a click from one OpenEmail mailbox to another comes back the usual way.
The whole report is on the REST API under the emails:read scope that already covers sent mail: a list, open and click rates over the tracked messages in a window, and the individual hits with the automated ones included if you ask for them. The per-hit log stops at 2,000 rows per copy while the counters carry on, so a pixel fetched in a loop cannot grow a table nobody is watching.
A message sent with tracking off shows nothing at all rather than zero opens. Nobody opened it and we were not recording are different answers, and nothing in the product renders them the same way.