What does a click-time URL-rewrite click record prove, and what does it not?
answer
- a request reached the redirect service
- machines resolve links too
- the token names a mailbox, not a person
- the record ends at the redirect
- clicking past a warning is the strong bit
basics
~20 sIt proves the protection service received a request for that recipient's rewritten link at that time, and what verdict it applied. It does not prove a person clicked, that they reached the page, or that they typed anything into it.
solid answer
~50 sThe record is generated by the redirect service, so what it attests is a request: this rewritten token was resolved at this timestamp, from this address, and the service allowed, warned or blocked it. Three gaps matter. Machines resolve links as well as people, so a chat link preview, another security product or a prefetching client can produce a click with nobody behind it. The token identifies the delivered message and recipient rather than the human at the keyboard, so a forwarded copy clicked by someone else still lands under the original recipient's name. And the record ends at the redirect: whether the page loaded, whether credentials were typed, whether a session was issued all live on the identity and endpoint surfaces. A flag showing the user clicked past a warning is the strongest bit it carries, because automation does not click through warnings.
code
json · 11 lines{
"Timestamp": "2026-03-11T09:04:17Z",
"AccountUpn": "[email protected]",
"Url": "https://supplier-portal.example[.]com/inv/8871",
"ActionType": "ClickAllowed",
"IsClickedThrough": 0,
"NetworkMessageId": "4f2c...9ab1",
"Workload": "Email",
"IPAddress": "203.0.113.44"
...
}go deeper
Know that the record comes from the redirect service and shows which mailbox's link was resolved and when, and that it stops there. Do not describe it as proof that someone was phished.
Walk through the fields and what each one supports: the timestamp, the mailbox the token was minted for, the action taken, and the click-through flag. Name at least one reason a click can exist with no human behind it.
Show how you turn the raw click list into a ranked worklist, filtering automation by source address and timing, and be explicit that confirming compromise requires surfaces this console does not hold.
Be ready to talk about what you let this record be used for. Click data names individuals, feeds awareness programmes and can end up in performance conversations, so the retention and access rules around it are a decision you should own.
## What the record is A click-time URL protection service logs one row per resolution of a rewritten link. The fields you actually reason over are the timestamp, the mailbox identity the rewritten token was issued for, the original URL, the action the service took at that moment, whether the user proceeded past a warning page, the source address of the request, and an identifier tying the click back to the delivered message. Every one of those is a fact about the *redirect service*. That is the discipline this question is testing: state the claim in the direction the evidence actually points. ## The claim, stated honestly The service received a request for a token issued to that mailbox, at that time, and applied the verdict it held then. Everything past the redirect is inference. ## Three ways the obvious reading is wrong **Machines click.** Link previews in chat platforms, other mail-security or web-security products following the URL, mailbox rules and archiving tools, mobile clients prefetching content: all of these can request a rewritten URL. A cluster of clicks arriving within a second of delivery, from a hosting-provider address rather than a user's egress address, is almost always automation. Counting those as victims inflates an incident and sends you to interview people who did nothing. **The token names a mailbox, not a person.** The rewritten link is minted for the delivered message. If the recipient forwards it to a colleague, to a personal address, or into a chat channel, whoever clicks resolves the same token, and the record still says the original recipient. Shared and delegated mailboxes make this worse: the assistant who reads the executive's mail generates clicks attributed to the executive. **The record stops at the redirect.** The destination may have failed to load, been blocked by the web proxy a layer later, presented a login form the user closed, or harvested a password in full. The click log cannot distinguish those. Deciding which happened means pivoting to surfaces this control does not own, and you should say so rather than pretending the mail console answers it. ## Absence is not innocence No record is not evidence that nobody engaged. There is nothing to log if the user copied the address out of the rendered message and typed it into a browser, scanned a QR code with a personal phone, reached the same site from a search engine, or received the lure through a channel that never traversed the gateway. Reading an empty click log as proof of a clean campaign is the most confident way to close an incident that is still running. ## The verdict field, read correctly An allowed click means the service had no adverse verdict for that URL at that instant. It is not a safety certificate, and it is very often what you see for the first clicks on a link armed after delivery, precisely because reclassification came later. A blocked click means the destination was already known-bad when the request arrived, so the user was stopped at the gateway. The click-through flag is the highest-value bit in the record: a warning page was shown and a human chose to proceed, which is both a strong indication of real human engagement and a specific fact you will be asked about later. ## Turning clicks into a worklist When a campaign is confirmed after delivery, this record is what converts thousands of recipients into a handful of people who need attention. Rank them: clicked past a warning first, then clicks from user egress addresses at plausible human times, then clicks from privileged accounts, and drop the ones that look like automation after you have checked the source address and the timing. Each surviving name becomes an identity and endpoint question that is answered elsewhere. What you must not do is report the raw click count as a compromise count. ## The sentence that earns the mark "Twelve clicks were recorded, of which nine came from user egress addresses at working hours and two of those clicked through the warning page. That is nine people to check and two I would treat as engaged until proven otherwise. None of those records tells me a credential was submitted."
- Forty clicks on one link all landed within two seconds of delivery, from the same hosting-provider address. What is your reading?Automation, not forty victims. Human clicks scatter across minutes to days and come from user egress addresses. A tight burst from one datacentre address is a link preview, an archiving tool or another security product resolving the URL. I would confirm the source address before removing them from the worklist, not after.
- The click log is empty for a campaign you know reached two hundred mailboxes. Does that close the incident?No. Nothing is logged if the address was copied out and retyped, scanned from a QR image with a personal phone, or reached from a search result, and coverage gaps mean some mail may never have been rewritten. An empty log is weak evidence of low engagement, never proof of none.
- Why is the click-through flag more useful than the click itself?Because an automated fetcher does not read an interstitial and press continue. A click-through means a warning was rendered to a human who chose to proceed, which both filters out machine noise and is the specific fact that will be quoted back to you in the write-up and in any conversation with that person's manager.
saying these in an interview costs you the question
- Reads a click record as proof the user entered credentials
- Counts every click as a distinct human victim
- Attributes a forwarded message's click to the original recipient without saying so
- Treats an allowed click as evidence the site was safe
- Concludes from an empty click log that nobody engaged