Open and click tracking

Open and click tracking produce the engagement events shown on the Metrics dashboard. Both modify the message as it is sent. They remain off until you enable them for the sending domain in Email > Domains.

We inject a transparent pixel into the HTML part of the message. When the recipient's mail client fetches it, we record an email.opened event with the client's IP address and user agent.

That signal is softer than it looks. Mail privacy features, most prominently Apple Mail Privacy Protection and Gmail's image proxy, fetch images on the recipient's behalf, so an open can be a machine and not a reader. We mark those with is_prefetched: true, and your open rate counts unique non-prefetched opens only, so proxy traffic does not inflate it. Both the raw and the filtered counts are in the stats API if you want to see the gap.

Opens are still a soft signal after that filtering, which is why clicks are the better basis for a decision that matters. Apple Mail Privacy and open tracking covers how to read engagement now that machines open your mail.

We rewrite the links in your HTML through a tracking redirect. The recipient clicks the rewritten URL, we record an email.clicked event with the original url, and the browser goes straight on to the destination.

Rewritten links are served over HTTPS from your branded tracking hostname, a CNAME on your sending domain that defaults to links (so links.mail.acme.com for a sending domain of mail.acme.com). Nothing is rewritten until that record verifies. Adding it, choosing a different label, and changing it later are all covered in Tracking domain.

A message can record a click and no open at all. The two instruments explain it: an open needs an image to load, and a click does not.

The pixel goes unrecorded whenever it never loads. The recipient's client blocks remote images, or they read the plain-text part of the message, which carries no pixel at all. A rewritten link still works in both cases, so the click lands and the open never does. The reverse of the prefetch problem, in other words: privacy features inflate opens, and blocked images deflate them.

Forwarding produces the same shape from a different cause. A forwarded copy carries the same rewritten links, so a click can arrive from someone who was never on your recipient list, and no open of theirs was ever yours to measure.

None of this is a fault to fix, and a report showing clicks above opens is not wrong. It is the reason the page above says clicks are the better basis for a decision that matters.

Tracking on a given message is the AND of three things:

So a fresh workspace tracks nothing even though the per-send flags default to true: a per-send true cannot switch tracking on by itself. Add and verify the tracking CNAME, then turn the domain setting on. You can flip the setting on before the record verifies and it takes effect once it does, but turning it on for a domain with no tracking hostname configured at all returns a 409.

A per-send false always wins, which is the reason the flags exist. Set track_clicks: false on password resets and security notifications, where a rewritten link is worse than no click data. Both flags are booleans on POST /v1/email/messages, and the message resource echoes the resolved values back on the send response and on later reads, so you can see what a message was actually sent with.

An unverified tracking CNAME never blocks sending. A domain reports its tracking readiness separately from its sending readiness, as capabilities.tracking and capabilities.sending.