Open tracking answers a deceptively simple question: how does open tracking work? In most email systems, it works by adding a tiny remote image to an HTML email and recording the web request made when a mail client fetches that image.

That mechanism is useful, widely implemented, and inherently imperfect. A recorded open can mean a person viewed a message, but it can also mean a privacy proxy, security scanner, or mail client downloaded remote content automatically. Treat open data as a signal about message rendering and possible attention—not definitive proof that a particular human read every word.

What email open tracking actually measures

An email “open” is usually not an event transmitted by the recipient’s mailbox. SMTP delivers a message from one server to another, but the mail protocol does not include a standard command saying, “the recipient read this.” Once a receiving provider accepts a message, the sender generally cannot observe what happens inside the recipient’s inbox.

Open tracking creates an observable event indirectly. The sender includes a remotely hosted image in the HTML version of a message. When a recipient’s mail application displays the message and decides to load external images, it requests that image over HTTP or HTTPS. The tracking service receives the request, matches a unique identifier in the image URL to the sent message and recipient, and records an open event.

In other words, an open means:

A client or intermediary requested the tracking image associated with this email.

It does not necessarily mean:

the intended person consciously opened the email;
the person read it from top to bottom;
the email remained visible long enough to be understood;
the message reached the inbox rather than a tab or filtered folder; or
the request came from the recipient’s home, office, or mobile IP address.

This distinction matters most when open data drives an automated decision. Do not use a single open event as the sole basis for declaring a user engaged, suppressing a reminder, triggering a sales follow-up, or assessing employee behavior.

The tracking pixel: the core technical mechanism

A tracking pixel is normally a 1-by-1-pixel image that is visually unobtrusive. It may be a transparent GIF, PNG, or another tiny image response. Email infrastructure commonly injects it near the end of the HTML body so the original email template remains readable and so plain-text content is left unchanged.

A simplified HTML fragment looks like this:

<img
  src="https://track.example.com/o/8f31b2c4e7d94d44a9b0.gif"
  width="1"
  height="1"
  alt=""
  style="display:block;border:0;outline:none;text-decoration:none"
/>

The important part is not the dimensions. It is the URL. The path contains an opaque, message-specific token such as 8f31b2c4e7d94d44a9b0. A good token is difficult to guess and should not expose an email address, customer ID, name, or other personal information in the URL.

What happens when the image loads

A typical sequence is:

Your application composes an HTML email and submits it through a REST email API or an SMTP relay.
The sending service stores a relationship between the message, recipient, campaign or tag, and a unique tracking token.
The service adds the image tag to the HTML part when open tracking is enabled.
A receiving mail system accepts and stores the email.
The recipient’s mail client, proxy, or scanner requests the image URL.
The tracking endpoint validates the token, logs the request, and returns a valid image response.
Reporting aggregates that event into metrics such as first open, last open, total image requests, unique opens, and open rate.

The tracking server commonly returns 200 OK with an image content type such as image/gif or image/png. A successful response is in the HTTP 2xx class. A malformed tracking URL may return 400 Bad Request; a token that is unknown or intentionally hidden could return 404 Not Found; service failures may produce 500 Internal Server Error or 503 Service Unavailable. These HTTP outcomes are distinct from SMTP responses used earlier in the sending path.

Why the pixel must be a real image response

Mail clients and intermediary caches can be strict. Returning a valid, tiny image with correct headers is more robust than returning an empty response or HTML. A minimal conceptual response might include:

HTTP/1.1 200 OK
Content-Type: image/gif
Content-Length: 43
Cache-Control: no-store, max-age=0

[binary GIF data]

The exact cache policy is a design choice. If the URL is unique per delivered message, caching is less likely to cause one recipient’s event to be attributed to another. However, an image can still be cached by a mail client, proxy, or security layer, which is one reason repeated opens are much less dependable than the first recorded request.

Why open tracking only works in HTML email

A plain-text email contains text only. It cannot contain an HTML <img> element, CSS background image, or other remote asset that a mail client renders as part of the message. Therefore, a text-only message cannot use standard pixel-based open tracking.

The usual best practice is to send multipart email with both versions:

text/plain for recipients, clients, and accessibility contexts that prefer plain text;
text/html for layout, branding, buttons, images, and optional open tracking.

A multipart message does not make every recipient trackable. If a recipient reads the plain-text alternative, blocks remote images, uses a text-focused mail client, or receives a security-sanitized copy, the tracking pixel will not create an event. That is normal behavior, not a delivery failure.

MIME structure and placement

A multipart/alternative email typically carries plain text and HTML alternatives under the same message. The HTML part is where the pixel belongs. Do not append the pixel to the plain-text part, and do not attempt to disguise HTML markup as text.

A simplified structure is:

Content-Type: multipart/alternative; boundary="alt-boundary"

--alt-boundary
Content-Type: text/plain; charset=UTF-8

Your receipt is ready.

--alt-boundary
Content-Type: text/html; charset=UTF-8

<html><body><p>Your receipt is ready.</p><img src="https://track.example.com/o/TOKEN.gif" width="1" height="1" alt=""></body></html>
--alt-boundary--

The exact message construction is usually handled by an email provider or library. When integrating through a transactional provider, confirm whether tracking is enabled at an account, sending stream, message, API parameter, or SMTP-header level. For implementation patterns that vary by provider, consult the platform’s email API and SMTP setup guides rather than assuming API field names are portable.

The difference between sending, delivery, and opening

Email reporting is easier to interpret when each stage has a separate definition.

Submission

Submission is the handoff from your application to your email provider. With SMTP, a 250 reply after the message data is accepted generally means the relay accepted responsibility for processing that message. With an HTTP API, a successful 200 OK, 201 Created, or 202 Accepted response generally means the API accepted the request according to that service’s contract.

Neither response proves inbox delivery or a recipient open. It confirms only a prior step in the delivery pipeline.

Delivery

Delivery normally means the recipient’s receiving mail system accepted the message. A delivery event may be inferred from SMTP responses between mail servers or reported by a provider that operates the sending infrastructure. It still does not guarantee that a message appeared in the primary inbox, escaped filtering, or was read.

A hard bounce, by contrast, is a permanent delivery failure such as an invalid recipient address. A temporary SMTP failure is commonly represented by a 4xx reply and may be retried; a permanent failure is commonly represented by a 5xx reply. For example, 550 is widely used for a mailbox or policy rejection, though the complete meaning depends on the receiving server’s enhanced status text and policy.

Open

An open is a later web request for remote content. It depends on HTML being rendered and external-image behavior. It can happen seconds after delivery, days later, multiple times, or never—even if the recipient reads the plain-text version.

Click and conversion

A click occurs when a recipient or intermediary follows a tracked link, usually through a redirect endpoint. A conversion is an action on your own product or website, such as completing account verification, creating a project, downloading an invoice, or paying an order.

For most product and transactional email programs, the reliability hierarchy is:

First-party conversion or completed task
Authenticated in-app action or direct website event
Tracked click, interpreted with bot filtering
Delivery and bounce data
Open data

That does not make opens useless. It means the metric should be matched to the decision’s importance.

How tracking domains and DNS fit into open tracking

Many senders use a branded tracking domain instead of a provider-owned hostname. For example, recipients may see track.example.com rather than a generic domain in the HTML source. A custom tracking domain can support consistent branding and makes it easier to control the DNS namespace used for your email program.

The provider usually asks you to create a DNS alias from a subdomain you control to a hostname it controls. In zone-file notation, a CNAME record looks like this:

track.example.com.  3600  IN  CNAME  customer-id.tracking-provider.example.

This is real DNS record syntax, but example.com and tracking-provider.example are documentation placeholders. Your provider must supply the exact target hostname; do not substitute a guessed target. In many DNS dashboards, the same record is entered as fields similar to:

Type:   CNAME
Name:   track
Target: customer-id.tracking-provider.example
TTL:    3600

Some DNS hosts automatically append your root domain to Name, so entering track creates track.example.com. Others expect the full hostname. The provider’s domain verification instructions and your DNS host’s interface determine which format is correct.

CNAME rules that commonly cause failures

A hostname that has a CNAME generally cannot also have other DNS records at the same name. In practical terms, do not try to put an A, AAAA, MX, TXT, or another CNAME record alongside the tracking CNAME at track.example.com.

Also avoid using your root or apex domain for a CNAME. The zone apex normally needs records such as SOA and NS, and many DNS providers do not allow an apex CNAME. A dedicated subdomain—track.example.com, email.example.com, or links.example.com—is safer and clearer.

DNS propagation is not instantaneous across all resolvers. Check the authoritative record first, then test public resolution. Useful commands include:

dig +short CNAME track.example.com
nslookup -type=CNAME track.example.com

MXToolbox’s CNAME Lookup is also useful for confirming that a hostname resolves as an alias. If the domain is correctly configured but image requests still fail, inspect TLS certificate validity, HTTP redirects, provider verification status, and whether the message’s generated pixel URL actually uses the intended custom hostname.

HTTPS and certificates

A tracking image should be served over HTTPS. Modern mail clients and web security tools expect secure remote content, and a certificate mismatch can prevent requests or create warnings. When a provider asks you to CNAME a tracking hostname to its infrastructure, it may issue and manage the certificate for that hostname after DNS verification.

Do not point the tracking hostname at an unrelated web server just because the CNAME resolves. The hostname must reach infrastructure capable of recognizing and serving the tracking endpoint. If you self-host tracking, you must handle token validation, image delivery, TLS, logging, data retention, privacy, abuse prevention, and uptime yourself.

What a tracking endpoint records

When the tracking server receives a pixel request, it can log metadata associated with that HTTP request. Common fields include:

the internal message identifier and recipient association derived from the token;
request timestamp;
user-agent string, which may identify a mail client, browser engine, proxy, or security system;
source IP address or a proxy IP address;
referer header when present, though it is often absent or not useful in email contexts;
image URL, tracking-domain hostname, and response status;
a classification such as first open, repeat open, suspected proxy, or suspected automated request.

The raw data is not automatically trustworthy. User-agent strings can be changed, suppressed, or generic. IP addresses can belong to a corporate gateway, a mobile carrier, a VPN, a privacy relay, or a large proxy service. A request from an IP geolocated to a city indicates where infrastructure is registered or observed, not necessarily the recipient’s physical location.

Unique opens versus total opens

A unique open normally means the first recorded event for a message-recipient relationship. A total open count may include later pixel requests for the same message. Providers vary in their aggregation rules, so document your definitions before comparing metrics across systems.

For example, suppose an email is sent to 1,000 recipients. The pixel is requested at least once for 420 recipient-message pairs, and those pairs produce 810 total image requests. A basic open rate might be calculated as:

unique opens / delivered messages × 100
420 / 1,000 × 100 = 42%

But that 42% is a count of observed requests. It is not a proven 42% human readership rate. If a substantial share of recipients use privacy-protecting clients that preload images, the observed rate can be inflated. If many recipients block remote images, it can be understated.

Privacy proxies, image blocking, and automated opens

The central limitation of open tracking is that email clients control remote-image loading. Senders do not control whether an image is fetched, when it is fetched, or which network fetches it.

Apple’s Mail Privacy Protection is a prominent example. Apple states that the feature hides the recipient’s IP address and prevents senders from seeing whether an email was opened. It can download remote content in the background regardless of whether the recipient engages with the message. From a sender’s perspective, that background request can look like an open even when the person never viewed the message.

Other causes of misleading or missing events include:

recipients disabling automatic image loading;
enterprise security gateways prefetching or scanning message content;
antivirus or anti-phishing systems rendering email in a sandbox;
caching proxies that fetch an image once and serve later views without another request;
forwarded messages where a later viewer loads the original pixel;
a recipient reading only the plain-text alternative;
client settings that block all remote content until the recipient explicitly allows it.

Why IP address and location are weak signals

Historically, open reports often showed a city, region, device, and IP address. Today, that information is frequently proxy information. Even without privacy features, IP geolocation is approximate and may point to a mobile carrier’s gateway or an employer’s central network rather than the recipient.

Avoid using open-IP data for security-sensitive decisions. It is not suitable evidence for account takeover investigations, employment monitoring, fraud determinations, or precise location analytics. If you need to establish a user’s identity or device, use authenticated product events and security controls designed for that purpose.

Why repeated opens are especially noisy

A second pixel request might reflect a true second reading. It might also be an image refresh, a cache expiration, a forwarded message, a proxy behavior change, or another automated system. First-open data is generally more interpretable than a long list of repeat requests, but it still remains an indirect signal.

A practical reporting policy is to retain raw events for diagnostics while making “first observed image request” the default engagement field in dashboards and downstream automation.

Open tracking and deliverability: related but not the same

Open tracking does not itself authenticate mail. It does not replace SPF, DKIM, DMARC, sender reputation management, valid unsubscribe handling, or sound list acquisition practices. It is simply remote content embedded in an HTML email.

That said, a broken tracking setup can create a poor technical experience. An unreachable tracking domain, invalid certificate, excessive redirects, or suspicious-looking host can lead to blocked images, security warnings, or reduced trust. Keep the tracking host stable, HTTPS-enabled, and operationally separate from critical application endpoints.

What to validate before production

Before enabling tracking on high-volume mail, test the complete message—not just the HTML template.

Send a multipart test email to inboxes at several providers and clients.
Confirm that the HTML source contains one expected pixel and that the plain-text version remains clean.
Load the message with images allowed and verify one event is recorded.
Test with images blocked and verify that no open is expected.
Inspect the tracking hostname with dig or nslookup and confirm the expected CNAME target.
Confirm that the pixel endpoint returns a successful image response over HTTPS.
Review whether your reporting labels proxy-generated events separately, if your provider offers that classification.
Send a copy to mail-tester.com to inspect the delivered message, authentication, HTML construction, and mail-server configuration signals.

mail-tester.com is useful for general email quality checks, but it cannot reproduce every recipient client or privacy proxy. Use it alongside real-client testing in Apple Mail, Gmail, Outlook, mobile clients, and any enterprise environments important to your audience.

Designing better metrics than “did they open?”

Open tracking remains valuable for high-level diagnostics. For example, if a previously healthy lifecycle message shows an abrupt decline in observed opens across all clients, that may point to an HTML rendering problem, image-host outage, audience change, or measurement change. It can also help compare broad subject-line or send-time patterns when you control for client mix and treat the outcome cautiously.

It is much weaker as the primary measure of success. Better metrics reflect the job the email was meant to accomplish.

Transactional email examples

For transactional messages, tie measurement to the recipient’s next useful action:

Account verification: verification link completed or account activated.
Password reset: reset flow completed, with careful security logging.
Receipt or invoice: invoice downloaded, payment completed, or support contact avoided.
Shipping update: tracking page visit, delivery confirmed, or fewer “where is my order?” tickets.
Product alert: alert viewed in the application, workflow resumed, or issue resolved.

The message may be important even if no pixel fires. A customer can read an invoice in plain text, view a shipping update in a privacy-protected client, or act on information copied into a notification preview.

Campaign email examples

For campaigns, favor measures that connect to actual intent:

click-through rate and click-to-conversion rate;
activated users or product adoption after the campaign;
trial-to-paid conversion;
repeat purchase or retention cohort movement;
unsubscribe, spam complaint, and bounce trends;
revenue or qualified lead outcomes, where attribution is appropriate.

Clicks are not perfect either. Security scanners can follow links, and link tracking can be affected by privacy features. The difference is that a click usually represents a stronger signal than an image request, especially when you connect it to a verified event on your own site.

Implementation choices for developers

Most email platforms offer open tracking through either an API setting, a message-level option, a stream-level default, or an SMTP header. The operational principle is the same: the provider needs permission to alter the HTML body and associate the generated pixel URL with the outbound message.

If you send through a REST API, keep these considerations in mind:

Send both text/plain and text/html bodies where possible.
Enable open tracking only for categories where the metric has a legitimate use.
Store the provider message ID alongside your internal notification ID.
Use webhooks or event APIs to ingest open events asynchronously rather than polling after every send.
Make event ingestion idempotent because retries and duplicate deliveries can occur.
Do not put recipient PII into tags, URL query parameters, or tracking tokens.

If you send through SMTP, the same content and privacy considerations apply. Your application receives SMTP acceptance responses during submission, but it should not assume acceptance equals delivery or opening. Preserve the Message-ID, provider-assigned identifiers if available, and application-level correlation IDs so delivery, bounce, click, and open events can be joined safely later.

A sensible event schema

A simple internal event model might contain:

{
  "event_type": "open",
  "provider_message_id": "msg_123",
  "notification_id": "notify_456",
  "recipient_hash": "sha256:...",
  "observed_at": "2026-08-17T14:22:31Z",
  "is_first_observed_open": true,
  "source_classification": "unknown"
}

Use a hashed or internal recipient reference in your analytics warehouse when possible. Limit access to raw IP addresses and user-agent strings, define retention periods, and document why the data is collected. Privacy requirements differ by jurisdiction and business context, so involve appropriate legal and privacy stakeholders before using tracking data for profiling or behavioral targeting.

Common open-tracking problems and how to troubleshoot them

“Delivery is successful, but no opens appear”

Start with the expected explanation: remote images may be blocked or the recipient may have read plain text. Then verify the technical path.

Inspect the delivered HTML source and confirm the pixel exists. Verify the URL host resolves in DNS, its TLS certificate is valid, and the endpoint responds with an image. Check whether your provider records events only after a webhook is configured or whether reporting has a processing delay.

Do not test solely by opening the message in a provider’s activity log or raw-message viewer. Some systems intentionally avoid rendering tracking pixels in their own interfaces so that inspecting a message does not generate a false open.

“Every message appears opened immediately”

This frequently indicates proxy prefetching, automated remote-content loading, or security scanning. Examine timestamp patterns, source classification if available, user-agent trends, and IP concentration. If thousands of apparent opens occur seconds after delivery with similar proxy characteristics, do not interpret them as immediate human attention.

Segment reporting by mail client or known privacy-proxy classification when your data permits, but do not overstate the accuracy of the segmentation. For automated workflows, use a click or authenticated product event instead of “opened” as the trigger.

“Our branded tracking domain does not work”

Confirm the record type is CNAME, the hostname is spelled exactly as required, and the CNAME target came from the provider’s current instructions. A typo, an extra root domain appended by the DNS interface, a conflicting record at the same hostname, or a stale target can prevent verification.

Then check the public result:

dig +short CNAME track.example.com
curl -I https://track.example.com/

The curl command may not return a useful page response because a tracking service may require a tokenized path; it is still useful for detecting DNS or TLS failures. For a real pixel URL from a controlled test email, request headers carefully and avoid sharing the token publicly because it may identify a message event.

“Open counts do not match another provider”

This is expected unless both systems use the same definitions, client classification, deduplication window, custom-domain setup, and event-retention policy. One system may count only the first event, while another exposes every request. One may classify known proxy traffic, while another reports all requests as opens.

Compare raw definitions before comparing rates. Use the same denominator as well: sent, accepted, delivered, and non-bounced message counts can produce different percentages.

A responsible policy for using open data

Open tracking can be legitimate when it helps improve message reliability, diagnose rendering issues, understand broad engagement trends, or tailor communication in a proportionate way. The strongest implementations make the practice transparent and minimize the sensitivity of the data collected.

A responsible approach includes:

explaining tracking in your privacy notice where required and appropriate;
collecting only the fields needed for the stated purpose;
avoiding precise-location claims based on pixel requests;
setting retention limits for raw event logs;
restricting access to recipient-level tracking data;
not penalizing users for blocking images or using privacy protections;
using verified product actions for consequential decisions;
offering preference and unsubscribe controls that work independently of whether a pixel loads.

Privacy protections are not broken analytics. They are intentional user and platform choices. A resilient email program treats the loss of deterministic open data as a reason to improve first-party measurement, not as a reason to pursue more invasive workarounds.

The practical takeaway

Open tracking works by embedding a unique remote image in an HTML email and recording the resulting HTTP request. It is technically straightforward, but its meaning is conditional: image loading is controlled by mail clients, proxies, security tools, and recipient settings.

Use opens as an approximate indicator that remote content was requested. Keep sending, delivery, click, and conversion events separate. Configure branded tracking domains carefully with the exact CNAME supplied by your provider, test the actual delivered MIME message, and validate DNS with tools such as dig, MXToolbox, and mail-tester.com.

Most importantly, build measurement around the outcome the email exists to produce. A password reset should be measured by a completed reset, an onboarding message by activation, and a campaign by meaningful downstream behavior. Open tracking can inform those decisions, but it should rarely make them on its own.

FAQ

Does an email open mean someone read my message?

No. It means a mail client, proxy, or automated system requested the tracking image. The recipient may have read the message, but privacy features, image preloading, and security scanning make that impossible to prove from a pixel event alone.

Can you track opens in plain-text email?

Not with standard pixel-based open tracking. A plain-text message cannot render a remote image. Send multipart email with plain-text and HTML alternatives if you need both accessibility and optional HTML tracking.

Why are Apple Mail open rates unreliable?

Mail Privacy Protection can download remote content in the background and hide the recipient’s IP address. That can create an image request even if the recipient never opens the message, so reported opens may be inflated and location data may reflect proxy infrastructure.

Does a custom tracking domain improve deliverability?

A custom domain primarily provides branding and control over the hostname used for tracking assets. It does not replace SPF, DKIM, DMARC, reputation management, or sound sending practices. Configure it correctly with the provider-supplied CNAME and valid HTTPS support.

What should I measure instead of open rate?

Measure the next meaningful outcome: verified account activation, completed password reset, product usage, qualified click, purchase, payment, or retention. Opens can remain a secondary diagnostic metric, but first-party outcomes are more reliable for decisions.

How Does Open Tracking Work? Pixels, Privacy, and Reliable Email Metrics