Most phishing awareness training repeats the same handful of tips, and most of those tips are sound. The problem is what sits underneath them — a set of assumptions about how links work that were reasonable a decade ago and are actively wrong today. Attackers have adapted to the advice people were given. The advice, in a lot of workplaces, has not caught up.
Here are five beliefs that still circulate as common sense, and what actually holds up when tested against how modern phishing infrastructure is built.
Myth 1: "If the site has a padlock, the connection is safe"
This one has the longest shelf life and does the most damage, because it isn't entirely false — it's just answering a different question than the one people think it answers.
The padlock confirms that traffic between a browser and a server is encrypted in transit. That's genuinely useful; it means nobody sitting on the same network can read the data as it passes by. What the padlock does not confirm is who operates the server on the other end, or what they intend to do with whatever gets submitted.
Free, automated certificate issuance became standard practice years ago, and phishing infrastructure adopted it just as quickly as legitimate businesses did. A fraudulent login page today is encrypted by default, not as an exception. The padlock used to correlate loosely with legitimacy because getting a certificate took effort. That correlation is gone. Reading HTTPS as a trust signal is now closer to reading a firm handshake as proof of honesty — a fine social convention, no guarantee of anything.
Myth 2: "I'd recognize a fake link — the spelling would be off"
Character substitution is real and worth watching for, but treating it as the primary tell trains people to miss the far more common technique: structural placement, not spelling.
Consider an address like login.accountservices.com.secure-verify.net. Every character is spelled correctly. Every word is a plausible, boring piece of corporate-sounding text. Nothing about it looks like a typo. And yet the domain actually receiving that traffic is secure-verify.net — everything before it, including the part that reads like a familiar service name, is subdomain text that the real owner can set to anything they like.
Domain ownership reads from the right, stopping at the boundary just before the top-level suffix. Spelling checks catch a narrower and increasingly rare category of attack. Structural reading catches a much broader one, including polished attempts with zero typos anywhere in the string.
Myth 3: "A clean scan result means the link is safe to open"
This is the myth that does the most damage precisely because it feels like due diligence. Someone runs a suspicious link through a reputation checker, sees "no known threat detected," and treats that as clearance.
Reputation systems can only flag what has already been observed, reported, and verified. A domain registered a few hours ago and used in a targeted campaign for the first time has, by definition, no track record for any reputation service to draw on. "Clean" in that context doesn't mean safe — it means undetected so far, which is a meaningfully different claim.
This gap is well understood by attackers, who deliberately rotate through short-lived domains precisely because it keeps them ahead of blocklists that depend on prior sightings. A scan result is one data point. Domain age, registration recency, and the surrounding message context matter just as much, sometimes more.
Myth 4: "Suspicious links come with obvious red flags — urgency, threats, bad grammar"
Early phishing campaigns leaned heavily on panic: account suspensions, tax threats, prize notifications. That style still exists, but it's increasingly the amateur end of the spectrum, and training that only teaches people to spot panic-driven messages leaves them unprepared for the more effective version.
The more successful modern lures are boring on purpose. An invoice notice referencing a vendor the company actually works with. A calendar update from a plausible colleague. A document-share notification that matches a tool the recipient uses every day. None of these trigger the adrenaline response that "urgent action required" does, which is exactly why they convert better. The absence of red flags isn't reassurance — it's often a sign the message was built by someone who understands what red flags people are watching for.
Myth 5: "Checking the link is the whole job"
Link inspection is necessary and genuinely useful, and it's still only half the picture. A single link tells you about one message. It doesn't tell you whether the same lure landed in other inboxes across the organisation, whether the sending account has been compromised versus merely spoofed, or whether this incident connects to something seen before.
Anyone who wants the mechanics of inspecting an individual link properly — reading the domain correctly, tracing redirects safely, interpreting a scanner's verdict without over-trusting it — will find a solid walkthrough of how to check a URL for malware covers that ground well. That's the right first move for any one suspicious message.
But once a link like that shows up inside a business email environment, the more useful question usually isn't "was this one link safe" — it's "what else does this connect to." That's a mailbox-wide, header-level question, and it's the kind of correlation that Email Forensics Software is specifically built to handle: tracing a single flagged message back through sender history, delivery patterns, and related indicators across an entire mail environment, rather than treating each suspicious email as an isolated event.
What actually holds up
Strip away the outdated assumptions and the durable practices are fairly simple. Read domains from the right, not by vibe. Treat encryption as privacy, not proof of legitimacy. Treat a clean scan as a snapshot, not a verdict. Watch for messages that are unremarkable on purpose, not just the ones that scream danger. And recognise that inspecting one link well is the beginning of a proper response, not the end of one.
None of that requires new technology or a bigger budget. It requires updating a mental model that was built for a threat landscape that has already moved on.
Sign in to leave a comment.