Phishing detection, in one screen
The warning signs every guide publishes describe the phishing of ten years ago. The checks below describe what a message can still be caught on today.
| Typos and urgency | Weak signals now: they measured attacker effort, and effort stopped being scarce |
| spf=pass, dkim=pass, dmarc=pass | Means the sending domain really sent it, and nothing at all about whether that domain deserves trust |
| The From address | Read the address itself, not the display name, character by character |
| Reply-To | A reply address on a different domain than the From is the loudest single header signal |
| The link | Compare the visible text with the real target, and look for an xn-- prefix in the domain |
| The decisive question | Not “does this look fake” but “was I expecting this domain to ask me for this” |
Every major source answers how to detect phishing emails with the same six items: urgency, a generic greeting, spelling mistakes, a mismatched sender, an unexpected attachment, a link that does not go where it claims. The FTC publishes that list. So does Microsoft, so does CISA, so does every security vendor with a blog.
The list is not wrong. It has simply stopped discriminating. Five of those six signals were never measurements of fraud; they were measurements of effort. Bad grammar meant the attacker was working in a second language and could not be bothered. A generic greeting meant nobody had enriched the mailing list. Those were reliable proxies for as long as writing a convincing message in fluent English cost something. That cost is now close to zero, and Google’s own AI summary on this query concedes it in passing: modern phishing, it notes, is becoming more polished.
So a clean, well written, correctly branded message is no longer evidence of anything. This page covers what still separates a phishing email from a real one, starting with the check most people get exactly backwards.
Authentication passing does not mean the message is safe
Open the full headers of almost any phishing message that reached your inbox in 2026 and you will find something like this:
spf=pass (google.com: domain of billing@micros0ft-secure.com …)
dkim=pass header.i=@micros0ft-secure.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE)
Three passes, and the message is fraudulent. This is not a failure of the standards; it is what they were built to do. SPF, DKIM and DMARC answer one question: did the domain in the From header really authorise this message? They do not, and cannot, answer whether that domain deserves to be trusted. An attacker who registers micros0ft-secure.com on Monday, publishes an SPF record, signs with DKIM and sets a DMARC policy will pass every check on Tuesday, because the domain genuinely is theirs.
Our reference on reading SPF, DKIM and DMARC verdicts out of the Authentication-Results header covers the syntax in detail. The point to carry into an inbox is narrower: pass is a statement about provenance, not about intent. Treating it as a safety verdict is the single most common way a technically literate reader gets caught.
The inverse also holds and matters less than people think. A dkim=fail or an spf=softfail on a message from a colleague usually means a mailing list rewrote the message or a forwarder broke the signature, not that anyone is attacking you. Our page on how sender addresses are forged and what stops it covers the forgery side of the same mechanism.
Four header checks that still discriminate
Every mail client can show raw headers. Gmail buries it behind the three dots as Show original; Outlook puts it under File, then Properties, then Internet headers. Once you have them, four fields carry almost all the remaining signal.
1. The From address, read character by character
The display name is attacker-controlled free text and should be ignored entirely. What matters is the address inside the angle brackets, and it needs reading as a string rather than as a shape. Substitutions that survive a glance include a zero for an o, rn for an m, an extra hyphen, a plausible subdomain of the wrong parent (paypal.security-check.com is a security-check.com address), and a legitimate brand name sitting in the local part rather than the domain.
A worked example of a phishing email address is service@apple-id-verify.com: no forgery, no spoofing, nothing for DMARC to catch, and it will authenticate perfectly. The only defect is the domain, and the only way to see it is to read it.
2. Reply-To against From
This is the loudest single signal left in the headers, and it is the one that the visual checklists never mention. A message whose From: is a familiar brand but whose Reply-To: points at a free mailbox or an unrelated domain is telling you where the conversation is meant to end up. Legitimate senders occasionally set Reply-To to a different address, but almost never to a different organization. Attackers set it constantly, because they need your answer to arrive somewhere they control. Reply-To addresses at throwaway providers are common enough that our page on how disposable mailboxes are detected is directly useful here.
3. The Received chain
Received headers stack newest at the top, so the earliest hop sits at the bottom of the block. Reading up from there tells you where the message actually entered the mail system, which is frequently a hosting provider or a consumer mail service that has nothing to do with the brand in the From. Our guide to tracing a message through its Received chain explains how to read the hops and what a broken or forged chain looks like.
4. The age of the sending domain
Lookalike domains are registered for a campaign and used within days, because they get blocklisted quickly. A WHOIS lookup on the sending domain returns its creation date, and a domain registered last week that is asking you to confirm a password is not ambiguous. This one check costs ten seconds and catches the entire category of attack that authentication cannot touch.
Checking a link without clicking it
Hovering to reveal the destination is standard advice and still correct, but it needs two additions to be worth anything.
First, compare the visible text with the real target rather than reading either alone. Link text is free text; https://www.yourbank.com/login can point anywhere. The mismatch is the signal, not the URL on its own.
Second, look at the very start of the domain for xn--. That prefix marks a punycode-encoded internationalised domain, the mechanism that lets a Cyrillic character render as a Latin one. A homograph domain is visually identical to the real thing and differs only in its encoded form, so the prefix is the only tell available in the status bar.
Marketing mail routes through click-tracking redirectors, so a first hop that belongs to a sending platform is normal rather than suspicious. What is not normal is a redirector you do not recognise wrapping a link in a message that claims to be transactional.
What a scam email checker can and cannot tell you
Searches for an email scammer check, a scam email checker or a way to check email for scams are looking for a tool that returns a verdict. Understanding what such a tool actually evaluates keeps its output in proportion.
A phishing email checker works on the technical envelope: it resolves the domain, reads the authentication results, checks reputation lists, ages the registration, and unwraps the links. Every one of those is worth automating, and any decent service will flag a domain registered nine days ago. This is also the honest ceiling of the category.
What no checker evaluates is the request. Whether your finance director actually needs a payment redirected, whether your registrar genuinely requires reverification this week, whether a supplier changed banks: those are facts about your organization, and they are where the fraud lives. This is why a scammer email check that returns green is not a clearance. The rule that survives every version of this attack is unglamorous: verify unexpected requests through a channel you chose, using a number or an address you already had, never one supplied by the message.
What to do with a message you have identified
Do not reply, and do not use an unsubscribe link: both confirm the address is live and monitored. Do not forward it inline either, because most clients strip headers when they do. Forward it as an attachment, or copy the full source, so that whoever receives the report still has something to work with.
Report it in three directions. Your provider’s report button trains the filter for everyone on that platform. The impersonated organization usually reads a phishing@ or abuse@ address and can act on the lookalike domain itself. In the United States, reportfraud.ftc.gov and IC3 take consumer and business reports; elsewhere, your national CERT does the same job.
If you clicked before you looked, change the password from a different device, revoke active sessions, and enable multi-factor authentication on that account before anything else. Credential replay usually starts within hours.
When your own brand is the one being used
Customers who receive a scam email carrying your logo will report it as spam, and receivers will eventually apply that judgment to your real mail as well. The defence is the same set of records read from the sending side: publish SPF and DKIM, then move the DMARC policy out of monitoring. Our guide to choosing between quarantine and reject and when to move covers the sequence, and the DMARC record itself covers the syntax and the reports.
None of that stops a lookalike domain, which is why publishing a BIMI record so your logo renders on authenticated mail is worth the effort: it gives recipients a positive signal that a lookalike cannot reproduce. Domains that are being impersonated at volume also tend to see their legitimate mail filtered more aggressively, which our page on the reasons legitimate mail lands in the spam folder covers from the deliverability side.
FAQ
What is a phishing scam email?
A message that impersonates a person or organization you trust in order to obtain credentials, payment, or an action that benefits the sender. The defining feature is the deception about identity and intent, not any particular technique: a phishing message may be forged, may come from a lookalike domain, or may come from a genuine account that has been compromised.
How can I tell if an email is really from my bank?
Not from the message. Read the From domain character by character and check Reply-To, but then confirm through the bank’s app or a number from your card, never a link or number inside the email. Banks design their communications so that this is always possible, and any message that pressures you out of doing it is answering the question by itself.
Can I get phished just by opening an email?
Opening the message is close to harmless on a current client, since remote content is blocked by default and the old rendering exploits are patched. The risk lies in what you do next: clicking, downloading, enabling content in an attachment, or replying. Loading remote images does confirm to the sender that the address is live, which is a reason to leave blocking on.
Why do scammer emails pass SPF, DKIM and DMARC?
Because those standards verify that the domain in the From header authorised the message, and on a domain the attacker registered themselves, it did. Authentication defeats forgery of somebody else’s domain; it has no opinion about a domain that is new, hostile, and correctly configured. A pass tells you the sender is who they say they are, which is not the same as being who you think they are.
Are typos still a reliable way to identify phishing?
No. Poor spelling used to indicate a low-effort campaign, and low effort correlated with fraud. Fluent, correctly formatted, brand-accurate text now costs nothing to produce, so its presence proves nothing. Treat writing quality as a signal that can convict but never acquit: bad grammar in a message claiming to be from a large company is still suspicious, while good grammar is no longer reassuring.
Where can I find real phishing email examples?
Your own spam folder is the best corpus, since it is targeted at people like you. For training material, the FTC and CISA publish annotated samples, and most large brands keep a page of the specific scams that abuse their name. Sample galleries age quickly, so use them to learn the structure of an attack rather than to memorise particular messages.
Should I use a phishing email checker or check the headers myself?
Both, for different things. A checker automates the mechanical work, resolving domains, reading authentication results and ageing registrations faster than you can. Reading the headers yourself is what tells you whether the specific request makes sense in your context, which no tool can evaluate. The checker narrows the field; you still decide.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
