Can I stop security scanners from clicking my links?

Not from the sending side. The scan belongs to the recipient's security stack, and an administrator there can add exclusions, but you cannot ask every recipient's IT team to do it. The practical answer is to recognise the traffic and exclude it from your own reporting and segmentation.

Do bot clicks hurt deliverability on their own?

Not directly. A scanner opening a link does not make a mailbox provider think worse of you. The harm comes from the decisions you make on the false data: keeping people who never read the mail, pruning people who do, and mailing an unengaged list more often because the numbers look healthy.

How do I know whether my unsubscribe endpoint removes people on a GET?

Make a plain GET request to the unsubscribe URL of a test subscriber record, then look at the record. If it is now unsubscribed, any automated link check can do the same thing. A GET should render a confirmation page and change nothing; only the POST should act.

Bot clicks in email: how to tell a scanner from a reader

Say a 14-person insurance brokerage sends one client letter a month. The report for the latest send comes back with a click rate three times the usual, and a handful of contacts who apparently clicked every link in the message: the main button, the three body links, the office address in the footer and the unsubscribe, all of them. Nobody replied. Nobody called. The "most engaged" segment built from that send is full of people who have never read the letter in their lives.

That is not a good campaign. It is a security product reading the mail on the recipient's behalf. It happens on almost every list that contains business addresses, and it does more damage than a flattering number: those clicks decide who you keep mailing, who you prune as inactive and who the owner calls next week.

What is actually clicking

Mail security gateways exist to protect people from links that turn malicious after a message has been delivered. The only way to do that is to look at the link, either before delivery, at the moment of the click, or both.

Microsoft documents this for Safe Links in Defender for Office 365: it scans and rewrites URLs in inbound mail during mail flow, and it verifies URLs at time of click. A rewritten link points at a Microsoft wrapper first, and the destination is checked before the reader is passed through. Other mail security gateways work the same way with their own wrapper domains. Every one of those checks is an HTTP request to your tracking link, and your sending platform has no way of knowing it did not come from a person.

Two details decide what your report looks like:

A gateway usually walks every link in the message, not the one link a reader would have chosen. That is why one contact appears to click five different things inside the same second.
The scan can happen on delivery, before anyone has seen the message. A click with no open in front of it, repeated across sends, is one of the clearer signs.

Open tracking has the mirror version of the problem. Kit's help documentation describes it plainly: open tracking works by loading a tiny embedded image, so any automated program that loads images is recorded as an open, and Kit notes this is especially common in Apple Mail, Gmail, and email clients managed by corporate and educational institutions. We wrote about the other half of that story in what Apple Mail Privacy Protection did to open rates.

Telling a scanner apart from a reader

No single signal is conclusive. Together they are usually enough to decide whether a campaign's numbers can be trusted at all. This is the table we work through when a client's report looks too good.

What the report shows	What it usually is	What to check	What we do with it
One contact clicked every link in the message inside the same second	A gateway walking the message	Whether other contacts at the same recipient domain did the same	Discard the whole burst, keep the contact
Click rate far above this list's own normal, with no replies and no conversions	Scanner traffic on a batch of business addresses	Replies, conversions and unsubscribes over the same send	Compare against the list's own history, never a published benchmark
A block of clicks arriving together, hours after the send	A delayed or scheduled scan	Click timestamps against the send window	Read the block as one event, not as engagement
Clicks from a contact who never registers an open	Link checking without image loading	Whether that recipient domain runs a security gateway	Keep the contact active, drop the click from the engagement score
An unsubscribe nobody remembers requesting	An automated request to the unsubscribe URL	Whether your endpoint acts on a `GET` as well as a `POST`	Fix the endpoint first, then restore the subscriber and apologise

Read the headers before you argue with the report

When a client insists a contact never clicked, the fastest way to settle it is the message itself. Ask the recipient for the original source of the message, the full headers rather than a forward, which loses most of them.

The Received chain names every hop the message passed through on the way in. If a security gateway handled it, that hop is in the chain, and its wrapper is usually visible in the links as well. That is the difference between telling an owner "we think something scanned it" and naming the product that did.

The unsubscribe nobody asked for

This is the part that costs real subscribers, and it is the one worth fixing today.

RFC 8058, published in January 2017, defines one-click unsubscribe. The sender puts an HTTPS URI in the List-Unsubscribe header and adds a List-Unsubscribe-Post header carrying a fixed key and value. The receiving mail provider then makes an HTTPS POST to that URI when the reader chooses to unsubscribe from inside the mail client. The RFC is explicit on two points: the receiver must not send that POST without the user's consent, and the sender must not answer it with an HTTPS redirect, because redirected POSTs have historically been turned into GETs.

List-Unsubscribe: <https://example.com/u/9f2c1a>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The gap is on the other method. The RFC notes that the POST target is the same URL a person reaches by clicking the unsubscribe link in the body, so one endpoint receives both kinds of request. It does not say what that endpoint should do with a GET, and that is where the damage happens. If a GET removes the subscriber, every scanner that walks your footer link quietly unsubscribes a reader who never asked, and the first you hear of it is a customer asking why the invoices stopped.

The fix is small and it lives entirely on your side. A GET renders a confirmation page and changes nothing. A POST carrying the documented List-Unsubscribe=One-Click body removes the subscriber immediately, with no confirmation step and no login, and the request is honoured within two days, which is the window Google's sender guidelines name. The full setup is in our guide to one-click unsubscribe and the two headers Gmail reads.

What your sending platform already filters

Check what the platform does before building anything, because the answers differ and they change what you should be reading.

Klaviyo stamps each Clicked Email event with a Bot Click value of true or false, and you can filter on it in segments and in custom reports. Its documentation notes the bot click data starts on 1 January 2022, so older events carry nothing.
Constant Contact keeps a maintained list of known bot and security scanner user agents and does not record the open or the click when it recognises one. Its article, last updated 2 October 2025, is honest that this cannot catch all of them.
Kit has a bot activity filter you can turn on or off in report settings, covering click counts, open counts and engagement scoring.

Two things follow from that. Filtering classifies events that were recorded, so it cannot recover a click that was never tracked in the first place, and no vendor claims it catches everything. Treat a filtered number as better, not as true.

What we check on a client account

Pull the last three sends and read the shape of the clicks, not the rate: timestamps, links per contact, and which recipient domains the bursts came from.
Turn on the platform's bot filter if it has one, then recompute the same three sends so the owner can see the size of the correction.
Make a GET request to the unsubscribe URL from a test subscriber record and check whether the record changed. If it did, that is the first fix.
Rewrite every segment and automation that uses engagement: active on replies, purchases and filtered clicks over a long window, never on opens alone.
Look at what the false data already did. Suppression rules, re-engagement flows and sales follow-up lists built on inflated clicks all carry the error forward.
Check whether the links themselves are worth trusting, which is a separate question if you run a custom tracking domain.

The numbers we trust instead

The user-reported spam rate in Postmaster Tools is the one figure a scanner cannot inflate, because a machine does not press "report spam". Google's sender guidelines ask bulk senders to keep that rate below 0.3 percent, and every point of it was produced by a person. Replies, conversions and support tickets are the same kind of evidence. Unsubscribe rate becomes trustworthy once the GET hole is closed, and not a day before. Our guide to setting up Postmaster Tools and reading it covers where those numbers live.

Click rate and click-to-open still have a job. Read them as a trend on one list, against that list's own history, recomputed after the bot filter is on. Reading them against another company's published benchmark was never useful, and it is less useful now, because you have no idea what share of their list sits behind a gateway.

How Guanacos Tech helps

Most of the work here is reading, not configuration: deciding which half of a report is real, then repairing the segments and the automations that were built on the other half. We go through the last few sends with the owner, name the recipient domains doing the scanning, test the unsubscribe endpoint against both methods, turn on whatever filtering the platform offers, and rewrite the engagement rules around signals a machine cannot produce. If your click rate went up and your replies did not, that is worth an hour with email deliverability consulting for small business before anyone prunes a list on those numbers. A 30-minute call is enough to tell you how much of your engagement data is real and what it would take to clean it up.

Bot clicks: why your click rate is inflated and what a security scanner leaves behind