Telling five readers apart on one email

You put five people on one email, and two hours later the tracker says it was opened. The question you have is which of the five, and one shared pixel cannot answer it. The reason sits in how the message was sent rather than in the tracker, which is the useful part: you can decide differently before you press send.

One pixel, one URL, one fact

A tracking pixel is an image in the message body, and the body is one document. Put five addresses on the To line and every copy carries the same image URL, so every reader pulls the same string from the same server. In Gmail the request does not even reveal the reader's network: Google's admin documentation states that when your users open email messages, Gmail uses Google's secure proxy servers to serve images. The address in your server log is Google's.

So a hit on that URL supports one sentence: somebody opened this email. What tools do with that sentence varies more than you would hope. Outreach credits the open to everyone and says so in its own help centre: send a one off email to several people, one of them opens it, and it will track as opened for every recipient. Others name one recipient and five others. The third choice is to say somebody opened it and leave the name empty, because a name attached to a guess costs more than a blank.

The envelope and the header are separate things

The way out is older than email tracking. SMTP carries what RFC 5321 calls a mail object, in two parts: an envelope, sent as protocol commands, carrying one or more recipient addresses, and the content, which holds the header section and the body. The To and Cc lines your reader sees belong to the content. The addresses that decide where the message is delivered belong to the envelope, and the standard is explicit that the two need not agree.

There is no inherent relationship between either "reverse" ... or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the header section.

That sentence sits in section 7.2 of RFC 5321, on blind copies, and the same section goes further: a sending system aware of blind copy use may find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command. RFC 5322 notes the same habit in its account of the Bcc field, where some implementations send a separate copy to each recipient with a Bcc line containing only that recipient's address. One copy per person is a practice the standards were already describing in 2008, for a privacy reason rather than a measurement one.

What per-person copies usually cost

Give every recipient their own copy and every copy can carry its own pixel, so an open becomes attributable by construction. This is why the usual advice for who opened it is to abandon the To line and run a mail merge. It works, and it spends something. Google's mail merge documentation is candid about the trade: each recipient gets a unique copy of the email, and recipients cannot check who else you sent the message to. Outreach describes its bulk compose the same way.

For a newsletter that is correct behaviour. For a live deal it is a loss you can feel. Much of the value of a group thread on a buying committee is that the members can see each other, and that a reply lands in front of all of them at once. Trade the visible group away and you have paid for measurement with the thing you were trying to measure.

Keeping the group and the certainty

Those two goals only compete while the envelope and the header stay coupled. Separate them and each recipient receives their own physical copy while every copy still displays the whole To and Cc group exactly as you typed it. Our delivery works this way, and the test that guards it asserts the property directly: three recipients, three SMTP transactions with one envelope address each, all three carrying the full To and Cc headers, each with its own pixel and none with anybody else's.

• Envelope: one address, so that copy's pixel is reachable only through that person's mail client.
• Visible To and Cc headers: the full group, so the reader still sees who else is on the thread and can answer all of them.
• Pixel and wrapped links: unique to the copy, which is what turns attribution from a score into a fact.
• Message-ID and Date: shared by every copy, so the set behaves as one message in a conversation instead of five near duplicates.

That shared Message-ID looks like a standards violation at first glance. RFC 5322 does ask for a single unique identifier per message, then says what counts as a different message: in all cases, it is the meaning the sender wishes to convey, whether this is the same message or a different message, that determines whether the Message-ID changes, and not any syntactic difference in the message. Five copies differing only in which pixel they carry are one message on that test.

Certain, likely, and somebody

A group email stays a single message here by default, because fanning every one of them out into separate copies would clutter your Sent folder and spend your send allowance without being asked. So both modes exist, and they report differently.

Certain

The open arrived on a pixel belonging to exactly one recipient, because only that person's copy contained it. The timeline names them, with no qualifier.

Likely

The open arrived on a shared pixel and matched something an earlier certain event had taught us about one recipient: the client family their mail app reports, or the network prefix they read from. A network match weighs nearly twice a client match, because whole companies share a browser and an operating system while two unrelated recipients rarely share a /24. The hit has to clear 0.55 and beat the runner up by 0.2, or it stays unattributed, and the screen prints the confidence as a percentage beside the word likely. Only certain events teach the model, so one guess cannot become the basis for the next.

Somebody

Below those thresholds the open is recorded against the email and against nobody in particular. It is the answer people like least and the one that holds up.

Where certainty runs out anyway

Per recipient copies settle attribution at the moment of sending. Four things after that are beyond any tracker's reach.

• Forwarding. A forwarded copy still carries the original recipient's pixel, so the open reports against whoever forwarded it. Outreach states the same limit for its own tracking, that an open from a forwarded email is indiscernible from opens coming from intended recipients.
• Apple Mail Privacy Protection. Apple's own description is that it hides your IP address and prevents senders from seeing if you have opened the message. Those opens cannot be confirmed, so they are labelled rather than counted or quietly dropped.
• Automated fetches. Gateways and prefetchers pull pixels too. A scanner user agent, a user agent with no browser or operating system token in it, a hit inside three seconds of send, and a hit from a datacentre range stay out of the human counts and visible on the row for audit.
• Prefetch fan out. Per recipient pixels allow one further check: one client address touching two recipients' pixels on the same email within five seconds is a prefetcher rather than two readers, so both hits are flagged, including the earlier one already on record.

Where everyone involved is on Workspace and you want one named person confirmed, Gmail already has a narrower answer with consent attached. Read receipts are only available to work or school accounts, the recipient may need to approve each request, and none is returned for a group mailing list or alias.

Fast Mail Tracker splits delivery per recipient while leaving your To and Cc lines exactly as you typed them, so a group thread stays a group thread and each open still has an owner. Verified opens are separated from proxy and scanner fetches, and an inferred open is marked likely with its confidence rather than promoted to a fact. Access is early and limited while our security assessment is in progress, and the install button just below this article is the way in.