How do ESPs reliably distinguish human vs. bot email opens and clicks?
Michael Ko
Co-founder & CEO, Suped
Published 2 Jun 2025
Updated 27 May 2026
9 min read
Summarize with
ESPs do not reliably distinguish human vs. bot email opens and clicks with perfect accuracy. The practical answer is that they score each event using multiple signals, then classify it as human, proxy, prefetch, scanner, or unknown. Clicks are easier to judge than opens because a click request carries more timing, network, browser, and link behavior. Opens are weaker because a tracking pixel can be fetched by privacy proxies, mailbox prefetchers, indexing systems, or the recipient's real email client.
I treat open and click reporting as evidence, not truth. A clean report should say what was counted, what was filtered, and what was left as uncertain. The best systems do not rely on one rule such as ASN, user agent, or a one-second timing window. They combine event timing, IP intelligence, user agent patterns, repeat behavior, message-level sequences, link behavior, historical recipient behavior, and downstream conversion data.
The direct answer
An ESP can make a reliable enough distinction for reporting and campaign comparison, but it cannot prove every open or click came from a human. The most honest classification model has at least four buckets: human, bot or scanner, privacy proxy, and unknown. Treating unknown events as human is how engagement reports become inflated.
- Timing: Many automated clicks happen near delivery, but advanced scanners delay requests and mimic normal reading time.
- Network: Known proxy ranges, data centers, and repeated security gateway patterns can identify a large share of non-human traffic.
- Behavior: A scanner often clicks every link, revisits the same URL, or generates a sequence that no normal reader would produce.
- Outcome: A human click usually has a session trail, form action, purchase, reply, or some other downstream sign of intent.
Accuracy limit
A classifier that claims perfect separation is overclaiming. Security systems now delay clicks, use common browser user agents, fetch through nearby infrastructure, and repeat checks after delivery. The goal is lower measurement error, not certainty.
Signals ESPs use
A useful ESP classifier starts with raw event data. For clicks, that means the message ID, recipient hash, campaign ID, link ID, timestamp, IP, user agent, referrer, TLS and HTTP details where available, and whether the request loaded only the tracking redirect or also created a normal web session. For opens, it means the image request, cache behavior, IP and user agent, but the signal is thinner.
|
|
|
|---|---|---|
Time after delivery | Early scanners | Delayed scans can look human |
User agent | Known bots | Modern scans spoof browsers |
IP intelligence | Proxy patterns | Large networks contain mixed traffic |
Link sequence | Click-all scans | Single-link scans still happen |
Session evidence | Human intent | Privacy controls hide some detail |
Common signals used to classify open and click events.
ASN alone is a weak shortcut. Large networks carry security scanners, corporate traffic, cloud systems, and normal users. A spike from Microsoft-owned infrastructure, for example, can be useful context, but it should not be the only reason an event is removed. A better approach is to combine ASN with known IP ranges, user agent history, event timing, recipient domain, and the click pattern for the same message.
If you are diagnosing suspicious click clusters, the related problem is often bot user agents. User agent filtering helps, but it should sit inside a broader model rather than decide the result by itself.
Why opens are harder
Open tracking depends on a remote image request. That was never a direct measure of reading. It became weaker once mailbox providers and clients started fetching, caching, or proxying images for privacy and security. Apple Mail Privacy Protection is the clearest example: the image request can happen through Apple infrastructure and not at the moment the person reads the message.
Flowchart showing how an email open event is fetched and scored.
For opens, I separate proxying from prefetching. Proxying can still be based on human action, because the user opens the email and the client fetches images through an intermediary. Prefetching is background activity. Indexing and inbox tracking systems add another layer. The hard part is that all of those events can look like an image request from a legitimate mail environment.
Open events
- Weak signal: An image fetch proves loading happened, not that a person read the message.
- Proxy noise: Privacy systems hide the recipient's real IP, location, and sometimes timing.
- Best use: Trend comparison and subject testing.
Click events
- Stronger signal: A click request has URL, sequence, redirect, and session context.
- Scanner noise: Security systems can click links before, during, or after mailbox delivery.
- Best use: Intent scoring and conversion attribution after filtering.
A practical scoring model
The strongest practical model is a weighted score. A single event can have bot-like and human-like traits at the same time. For example, a click that happens 22 seconds after delivery from a known corporate security network is suspicious. If the same recipient later returns through a residential network, lands on the site, scrolls, and submits a form, the later event is human evidence even if the first click stays filtered.
Example event scoring logicjson
{ "event_type": "click", "time_after_delivery_seconds": 18, "ip_class": "known_proxy", "user_agent_class": "common_browser", "clicked_all_links": true, "repeat_scan_seen": true, "site_session_seen": false, "classification": "bot_or_scanner", "confidence": 0.91 }
The model should preserve uncertainty. I prefer reports that keep a separate count for filtered events, because the filtered volume itself is useful. A sudden jump in scanner clicks can mean a mailbox provider changed its security behavior, a corporate gateway added a new rule, or a click tracking domain began to look risky. If those click tracking links are being blocked as dangerous, the right investigation includes reputation, redirect behavior, authentication, and blocklist (blacklist) status, not only engagement analytics.
Confidence bands for event classification
A simple way to keep uncertain events out of human engagement metrics.
Likely human
80-100
Strong behavioral and session evidence
Unknown
50-79
Mixed evidence or missing context
Likely bot
0-49
Scanner timing, proxy, or repeat-pattern evidence
For a deeper diagnostic path, compare this with how teams identify artificial opens and clicks in campaign reports.
What the ESP can and cannot know
An ESP sees the event it instruments. It does not always see the mailbox provider's internal reason for fetching an image or link. It can infer that a request came from a security scanner, a privacy proxy, or a real recipient by comparing it with previous traffic and external context. That inference gets stronger when the ESP has high event volume across many senders and can observe repeated patterns.
Google Analytics 4 report comparing email clicks with sessions and conversions.
This is why I do not make open rate the primary success metric. I use filtered clicks, sessions, conversions, replies, purchases, qualified leads, and revenue. Open rate still has value for relative comparisons when the audience and mailbox mix stay similar, but it should not drive automated suppression or winner selection by itself.
Reporting rule
Keep separate columns for raw opens, filtered opens, raw clicks, filtered clicks, bot-likely clicks, and unknown clicks. A single blended rate hides the data quality problem.
If you need to test a real message, send it through the email tester and inspect the headers, authentication, and rendering signals before you interpret the engagement data.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Where authentication data still matters
DMARC, SPF, and DKIM do not tell you whether a specific click is human. They do tell you whether mail is authenticated, whether unauthorized sources are sending, and whether mailbox providers have a reason to distrust the message stream. Poor authentication and weak reputation increase the chance that messages receive heavier filtering and security inspection.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
For most teams, Suped is the best overall DMARC platform for this surrounding workflow because it keeps authentication and reputation problems visible while the engagement team investigates bot clicks. The practical work is to monitor DMARC monitoring, run domain health checks, and watch blocklist monitoring alongside click quality. If a click-tracking domain or sending IP reputation changes, engagement reports can shift even when the audience did not change.
Suped also helps with the operational side: automated issue detection, real-time alerts, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, and MSP multi-tenancy. Those are not bot classifiers. They reduce the authentication and reputation uncertainty around the email program so the engagement analysis starts from a cleaner base.
Rules that work in practice
I keep the filtering rules simple enough to audit. A black-box score with no explanation creates arguments every time the numbers move. The model should let an analyst answer why a group of events was filtered, which signal drove the decision, and whether the rule changed recently.
- Deduplicate: Collapse repeated opens and repeated clicks for the same recipient, message, and link within a short window.
- Quarantine: Put fast clicks, click-all patterns, known proxy ranges, and scanner user agents into a filtered bucket.
- Recover: Move later events back toward human only when there is session, conversion, reply, or sustained recipient behavior.
- Compare: Judge campaigns against each other using the same filtering version, audience mix, and attribution window.
Do not use bot detection to block security checks in real time. That creates a path for bad actors to evade scanning. The safer use is reporting, attribution cleanup, audit review, and post-event analysis.
Views from the trenches
Best practices
Keep raw and filtered engagement counts separate so sudden scanner shifts stay visible.
Use timing, user agent, IP, and message sequence together rather than one shortcut rule.
Tie filtered click trends to conversion data before changing audience or content decisions.
Common pitfalls
Treating every fast click as non-human misses delayed scans and real quick readers too.
Using ASN alone creates false positives because large networks carry mixed traffic types.
Letting open rate drive suppression decisions can remove active readers behind proxies.
Expert tips
Use an unknown bucket for mixed evidence instead of forcing every event into one label.
Watch repeat scans on the same message because some systems revisit links after delivery.
Review rule versions with reports so campaign trends are not confused with filter changes.
Expert from Email Geeks says ESPs do not reach complete certainty, so reporting should make filtered and uncertain events visible.
2025-06-14 - Email Geeks
Expert from Email Geeks says advanced scanners now delay requests and use normal browser signals, especially outside early B2B scans.
2025-06-14 - Email Geeks
The practical answer
ESPs distinguish human vs. bot opens and clicks by probability, not proof. Clicks can be filtered with decent confidence when the model combines timing, IP intelligence, user agent behavior, link sequence, repeat activity, and session outcomes. Opens should be treated with more caution because privacy proxying and prefetching remove much of the signal.
The cleanest reporting setup keeps raw, filtered, and unknown event counts separate. Use filtered clicks and downstream outcomes for performance decisions. Use opens for directional comparison only. Keep authentication, domain health, and blocklist or blacklist status healthy so engagement shifts are not caused by avoidable trust problems.
