Tracking Pixels & JavaScript
Most email tracking does not require JavaScript. A remote image or redirect can create a signal, while modern mail clients usually restrict active scripts.
Read the guide →Email tracking privacy
Email tracking pixels, redirects, aliases, and privacy choices
Most email tracking does not need JavaScript in the inbox. Remote resources and redirects can create signals—but those signals are noisy and privacy-sensitive.
Separate signal from certainty
What email activity data can—and cannot—show
An image request or click can be generated by a person, a proxy, a preview pane, or a security scanner. Treat it as transport evidence, not proof of human intent.
Remote images
A unique image URL can record a request when a message is rendered, even when the image is transparent.
See how pixels work →Tracked redirects
A link can record the first visit before redirecting to the final destination; scanners may visit it automatically.
Verify sensitive links →Masked addresses
Private aliases reduce exposure of a primary address and make unexpected sharing easier to detect.
Compare alias types →Privacy controls change the meaning of common metrics
Image proxying can hide a recipient’s direct network address and can preload content before a person reads the message. Remote-image blocking can prevent a request even when the message is read carefully. Forwarding can create another person’s request under the original identifier. These behaviors make individual-level conclusions unreliable.
Click data can be more intentional than an image load, yet security products often inspect links. Senders should avoid placing sensitive personal data in URLs, use recognizable tracking domains, protect redirectors from abuse, and retain only the detail needed for a stated purpose.
Individuals can reduce exposure by disabling automatic remote content, using privacy relays or private aliases, navigating directly for sensitive actions, and separating different relationships. Sites should not treat every unique or masked address as abuse; assurance should match the risk of the action.
An open is not a receipt. Do not use a pixel event to prove that a person read, understood, consented to, or legally received a message.
Operating checklist
Build privacy into both sides of the mailbox
Recipients need usable controls, and senders need purpose limitation, transparency, security, and realistic interpretation.
- Make essential message content understandable without remote images.
- Use aggregate metrics when recipient-level history is unnecessary.
- Do not place sensitive data or durable identifiers in visible URLs.
- Offer recovery methods that do not depend on one forwarding alias.
- Treat scanner clicks and proxy opens as measurement limitations.
ObserveCollect the minimum evidence needed to describe the event.
VerifyUse a trusted system or independently known channel.
ConstrainLimit permissions, scope, duration, and affected recipients.
ReviewMeasure mistakes, remove stale rules, and document changes.
Signal Desk reading
Continue with a detailed guide
Use these long-form articles to move from the topic overview into a specific workflow.
Disposable Email Addresses
Disposable addresses can reduce unwanted mail and limit breach exposure, but blunt blocking can punish privacy-conscious users. Here is a risk-based approach.
Read the guide →
Important Email Triage
A calm inbox separates urgency from importance. Use deterministic rules for known workflows, a review queue for uncertainty, and human judgment for high-impact actions.
Read the guide →