What phishing is and how to spot it

Why paying more attention does not solve phishing

Phishing does not attack your computer. It attacks the order in which you make decisions. There is no break-in involved: a message arrives, puts you in a state where thinking is hard, and then asks you to do something you would not normally do.

Every phishing message carries three things at once. A pretext that is plausible, an authority that is familiar, and an urgency that removes the time to think. Your account will be suspended, your order was rejected, you have until tonight. The urgency is not decoration; it is the tool itself.

Let us drop one misconception right away. For years people were told the sign of phishing is bad language and spelling mistakes. That sign no longer works. Fluent, error-free text costs nothing today and anybody can produce it. If your detection depends on the quality of the writing, you have staked it on precisely the thing that is easiest to fix.

Our position: spotting phishing is not a feeling, it is a procedure. A careful person still gets caught on a good day, because on a bad day nobody is paying attention. What works on the bad day too is a fixed sequence of questions, run the same way every time, even when the message came from a familiar address.

The four questions, asked in order

The order here is half the work. The questions run from cheapest to most expensive, meaning from the one you can answer without opening any link to the one that takes some checking. If the first question answers it, the rest are not needed.

One: was I expecting this? This is the only question the message itself cannot influence. An invoice for something you never ordered, a parcel you never sent, an account warning from a site where you have no account. If the answer is no, everything in the message loses its standing from that moment, including its links and the phone number written inside it.

Two: is it rushing me? Real organisations give deadlines and several routes for anything important. A threat to close the account tonight, a fine that multiplies with delay, a discount that ends within the hour: all of them do one job, which is to shut the thinking window. Urgency alone proves nothing, but once it is added to the first question the answer is nearly always clear.

Three: does the link go where it claims? This question needs a skill, and it is in the next section. The text of a link can be anything; what matters is the destination domain.

Four: is it asking for something that must never be given? A short list with no exceptions: passwords, two-factor codes, the code on the back of a bank card, one-time payment codes, recovery codes, and remote access to your device. No bank, no operator and no support desk asks for these. If somebody does, no matter how right the rest of the message looks, it ends there.

Two situations cut the sequence short. If the answer to question four is yes, there is no need to ask the rest. And if the message came from a genuinely familiar address but the content is out of character, drop the questions and go straight to what the last section describes: contact that person through a route you chose yourself.

Reading the address, the skill everything comes back to

In a web address, the only part that does not lie is the domain, and a domain is read from right to left: back from the last dot. In example.com/bank the domain is example.com and bank is just a folder on that site. Anybody can create any folder.

The three shapes that claim the most victims all trade on that one point. First, the real name as a subdomain: something like bankname.example.com, where the eye sees the familiar name and does not read the actual domain that sits after the last dot. Second, the real name as a path: example.com/bankname/login. Third, a domain that differs by one letter or wears a different suffix. All three look right at a glance, and a glance is all it takes.

The practical way to read one has only two steps. Find the last dot and read one word either side of it; those two pieces are the real identity of the site. The rest of the address, however long and however full of familiar words, is only what the owner of that domain typed. The full anatomy of an address and what each piece does has its own lesson in the internet and networks track, and it is worth reading before you go further here.

On a phone this is harder and we should say so: the address bar is short, long addresses are shown truncated, and holding a finger on a link does not always reveal the full destination either. The rule that still works on a phone is this: instead of checking the link, do not use the link. Open the banking app or the site yourself. If there is news, it is there too.

And one thing that rarely gets said: the padlock beside the address has nothing to do with the honesty of the site. That padlock only says the connection is encrypted, and a fake page can be encrypted just as easily. The padlock means nobody in the middle is reading what you say; it does not say who is at the other end.

The patterns seen most often in Iran

Local phishing messages come in a handful of fixed templates, and recognising the template is more useful than memorising examples. The examples change every month; the templates have held for years. We reproduce the actual text of none of them here, because the aim is recognition, not construction.

The banking template. The claim: something is wrong with your account or card. The ask: log into a gateway to verify your identity or reactivate. The structural tell: a page asking for the card number, the second password and the code from the SMS all in one form. A real bank gateway never collects all of that from a non-bank page, and does not ask for your internet banking password either.

The benefit and shares template. The claim: a payment is due to you, a subsidy, shares or a refund. The ask: register your banking details so it can be deposited. The structural tell: no organisation needs your card password in order to send you money. An account number is enough to deposit; the password is only needed to withdraw. That one sentence disables the entire template.

The parcel and customs template. The claim: a package is waiting and a small fee is outstanding. The ask: pay the small amount through a link. The structural tell: the amount is deliberately trivial so that you do not think it is worth checking, while what they actually want is the card details, not that amount.

The workplace template. The claim: a message from a colleague or a manager, usually in a perfectly ordinary tone. The ask: change the account number on a payment, or open a file. This template is the most dangerous because it carries none of the tells above. The only thing that stops it is the habit of confirming through a second route: calling that person on a number you already had.

One point about SMS that gets asked constantly: the sender name or number you see on the screen is not evidence. Even when it is the usual number, a new message lands in the same conversation thread and looks familiar. The rule that covers both cases is simple: never reach your bank from inside a message.

Who the sender really is, and what the email itself gives away

The From line of an email is text the sender typed. Exactly like the sender name on a paper envelope: anything can be written there. That is why three mechanisms were built so the receiving server can check whether the mail really came from that domain, and it writes the outcome into the headers of that same message.

SPF says which servers are allowed to send on behalf of this domain. DKIM puts a cryptographic signature on the message itself, checked against a public key published in DNS. DMARC says what the receiver should do when those two do not work out: nothing, put it in spam, or refuse it outright. How they work has its own lesson in that same internet and networks track; here we only want the security consequence.

The practical consequence is this: in any email you can open the Authentication-Results header and see what the receiving server concluded. If it says spf=fail or dkim=fail or dmarc=fail, the message made a claim it could not back. That is a solid signal and it takes seconds to see.

Now the most important sentence in this section, and one that is said almost nowhere: all three passing does not prove honesty. These three mechanisms answer one question and only that one: did this message really come from this domain? Somebody who registers a lookalike domain this morning can have all three records right by the evening, and from then on their mail arrives with a clean pass. So a pass means the sender owns this exact domain, and you still have to read for yourself whether that domain is the one you think it is or the one with a letter changed.

So the right order is: look at the header first, because a fail ends the matter there. If it passed, then compare the domain that passed, letter by letter, with the real one. The second step cannot be handed to any system; that is exactly where a human eye is required.

I clicked; what to do now, in order

First, something reassuring that also happens to be true: opening a page, on its own, is usually not a big event. The danger starts where you typed something or opened a file. So the first job is to know exactly what you did.

If the page merely opened and you entered nothing: close it and that is the end of it. There is no need to shut down the machine or cancel a bank card.

If you entered a password: log into that service by a different route, not by the link; type the address yourself or open the official app. Change the password, and if the same password was used elsewhere, change it there too. Then, in the settings of that account, look at the active sessions and sign every other device out. The order matters: while somebody has a live session open, changing the password alone does not throw them out.

If you entered a two-factor code as well: assume somebody is inside the account right now. Go through the route above quickly and regenerate the recovery codes immediately, since the old ones may have been seen.

If you gave card details: call the bank, on the number printed on the back of the card and not the one that was in the message, and block the card. Speed genuinely matters here.

And if this happened on a work account: tell whoever runs the site or the network the same minute, however embarrassing it feels. Delay is the thing that turns a small mistake into an incident, because in that gap somebody can message the rest of your colleagues from your account.