Spotting the tells

Assume the message is well written, correctly branded, and passes every authentication check. What’s left?

More than you’d think — but you have to look at different things than the training slides suggest. These are ordered by speed: the first two take seconds and catch most of it.

1. Read the actual link target

The visible text of a link has nothing to do with where it goes. Hover on desktop, long-press on mobile, and read the real destination.

When you read it, read right to left from the last slash before the first single slash — the registrable domain is what matters, and everything to its left can be attacker-controlled:

https://accounts.google.com.verify-login.example/session
                            ^^^^^^^^^^^^^^^^^^^
                            the actual domain

That URL is not Google. google.com appears only as a subdomain label of verify-login.example. This is the single most common trick and it is also the easiest to catch once you know where to look.

Similar shapes worth knowing:

• google.com.example/ — the real domain is example
• google-com.example/ — a hyphen is not a dot
• xn--goog-... — punycode, rendering as lookalike Unicode characters
• Any link where the domain is a URL shortener you cannot resolve

2. Ask whether the action matches the channel

Legitimate systems have habits. Your bank does not ask you to confirm your identity through a link in an email. Your IT department does not collect passwords over chat. A supplier does not change their bank details in a reply to an existing thread.

If the action being requested is one that this sender has never legitimately requested through this channel before, that mismatch is a stronger signal than anything about how the message looks.

3. Check the reply-to, not just the from

A message can display a perfectly legitimate From: while setting Reply-To: to somewhere else entirely. You’ll never notice until your reply — with whatever you attached to it — lands in the attacker’s inbox.

Most clients hide this. Learn where yours shows full headers; it’s worth the sixty seconds it takes to find once.

4. Notice thread-hijacking

An attacker inside a compromised mailbox can reply to a real, existing thread — correct history quoted underneath, correct participants, correct subject line. Everything about the context is authentic, because it is.

The tell is a change of ask. A thread that has been about scheduling for two weeks suddenly contains an attachment or a payment request. The conversation history is real; the newest message is not.

5. Look at what the attachment wants

Attachments that ask you to do something before showing content are the concern:

• “Enable content” or “Enable macros” — never legitimate for a document you were simply sent
• An HTML file attached to an email, which opens a login form rendered locally from your own disk
• A password-protected archive whose password is in the email body — the point of that arrangement is to defeat scanning, not to protect you
• A file whose icon says document but whose extension says otherwise

The one-minute triage

In practice, for a message that feels off:

1. Read the real link domain. Right to left.
2. Ask whether this sender has ever legitimately asked for this, this way.
3. If both pass and you still feel uneasy — verify out of band. Call the person on a number you already had. Not a number in the email.

Step three is the one that never fails, and it’s the one people skip because it feels socially awkward. It isn’t. “I got an email about the invoice, just confirming it’s you” is a normal sentence, and the ten seconds of awkwardness is cheaper than the alternative.

Next: what to do when the click already happened.