AI-written phishing emails no longer arrive with broken grammar, odd capitalisation or clumsy phrasing. Large language models can produce fluent, well-punctuated, context-aware messages at scale, so the old advice to look for typos is now unreliable. What still works is checking the destination of links, the channel and timing of the request, the pressure being applied, and the authentication results in the headers. This article explains what changed, what did not, and how to adjust your habits.
Why is bad grammar no longer a warning sign?
For years, security awareness training leaned on surface errors. Phishing kits often came from non-native speakers, were translated badly, or were assembled from templates with mismatched fonts and spacing. A message that said “Dear Valued Customer” with three exclamation marks and a stray comma was easy to dismiss.
That heuristic was always imperfect. A well-written phishing email could still succeed, and a badly written one could still catch someone during a busy day. But the correlation was strong enough to be useful, and it became the first thing many people checked.
Generative AI removed that correlation. A model can rewrite a message in polished British English, match the tone of a real company, and adjust the formality for the recipient. The cost of producing a convincing message has fallen sharply, and the quality is now consistent.
What does AI change about phishing emails?
The shift is not just about grammar. Three things change when a phishing email is written by a model rather than a person working from a template.
Fluency and tone matching
A model can produce a message that reads like it came from a real organisation. It can copy the greeting style, the sign-off, the level of formality and even the typical length of a genuine email from that company. It can also adapt to the recipient: a message to a finance team reads differently from one to a student.
Personalisation at scale
Public information — job titles, recent posts, conference appearances, company news — can be pulled together and used to write a message that references something specific and plausible. The result feels less like a mass mailing and more like a message written for you. That sense of specificity is persuasive, even when the underlying request is unusual.
Variation and evasion
Filters look for patterns. A model can generate many variations of the same message, changing wording, subject lines and structure, so that no single signature catches them all. This does not make filtering useless, but it means filters alone are not enough.
Which signals still work?
The signals that survive are the ones that depend on the facts of the message rather than its style. They are harder to fake consistently, and they are worth building into a routine.
The destination of a link
Hover over a link, or long-press it on a phone, and look at the actual address. The visible text can say anything; the destination is what matters. Be suspicious of links that go to a domain that is not the organisation's main domain, especially if it includes the organisation's name as a subdomain or in a hyphenated form. A link that goes to a URL shortener hides the destination entirely, which is a reason to treat it with caution.
Urgency and pressure
Phishing relies on making you act before you think. A deadline, a threat of account closure, a payment that must be made today, a request that is framed as confidential and time-sensitive — these are the levers. AI can write them more politely, but the underlying pressure is still there. If a message is pushing you to act quickly, slow down.
Unexpected channel or request
A message that arrives through a channel you do not normally use for that kind of request is worth questioning. A password reset that arrives by email when your organisation uses a self-service portal, a payment request that arrives by email when payments normally go through an invoicing system, a document share from someone who usually sends links through a chat app — these are the moments to verify through a separate channel.
Authentication headers
Email authentication — SPF, DKIM and DMARC — tells you whether a message was sent by a server authorised to send for that domain. When a message fails authentication, that is a strong signal. When it passes, it means the domain is legitimate, not that the message is safe: an attacker can register a lookalike domain and set up authentication for it. Headers are still useful, but they are evidence, not a verdict. Our guide to SPF, DKIM and DMARC explains what each one checks.
What should you check before you click?
A short routine catches most attempts, whether they were written by a person or a model.
- Pause. If the message is asking you to do something now, treat that as a reason to wait.
- Check the sender address, not just the display name. The display name can be anything; the address is what matters. Look for lookalike domains and unusual subdomains.
- Inspect the link destination. Hover or long-press, and read the domain from right to left. The part just before the first single slash is the actual site.
- Verify through a separate channel. If the message claims to be from a colleague or a company you deal with, contact them using a method you already trust — a phone number you have on file, a chat app you already use, or the organisation's main website typed in by hand.
- Look at the request, not the wording. Is this a request that organisation would normally make by email? Is it asking for credentials, payment details, a code, or a file? Those are the requests to scrutinise.
- Check the headers if you can. In most email clients you can view the full headers. Look at the authentication results and the received chain. Our guide to reading email headers walks through the fields that matter.
None of these steps depends on the grammar of the message. That is the point.
Where do disposable addresses fit — and where do they not?
A disposable address is not a defence against a targeted phishing email. If someone is specifically trying to reach you, they will use whatever address they have. What a disposable address does is limit the damage from the other direction: it keeps your main address out of the lists that are sold, leaked and reused for broad campaigns. That reduces the volume of phishing you have to sift through, which makes the messages that do arrive easier to spot.
Disposable addresses are useful for signups, trials, forums and downloads where you do not expect or want ongoing correspondence. They are not a substitute for careful behaviour on your primary accounts, and they are not a way to avoid verification on services that require a real identity. If you are setting one up, our step-by-step guide covers the practical side.
It is also worth being clear about what a disposable inbox does not protect. It does not stop a determined attacker who already has your real address. It does not make you anonymous. And because the inbox is temporary, a message that arrives after it expires is simply lost — which is fine for a newsletter, but not for anything you need to keep.
How should you adjust your habits?
The practical response is to stop relying on style and start relying on structure. A few habits make a difference.
- Treat every unexpected request for action as suspicious until verified. This includes messages that look routine. The cost of a quick check is low; the cost of a mistake is not.
- Use a password manager. It will not fill credentials on a lookalike domain, which is a useful signal in itself.
- Turn on two-factor authentication where it is offered. Prefer app-based codes or passkeys over SMS where you can. Our explainer on two-factor authentication covers the trade-offs.
- Keep your main address for things that matter. Use it for banking, work, government services and anything you would need to recover. Use other addresses for everything else.
- Report and delete. If your organisation has a reporting button, use it. If not, forward the message to your IT or security team before deleting it.
These habits are not new. What is new is that they now carry more of the weight, because the surface signals have become unreliable.
Sources
- NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management (on phishing-resistant authentication and verifier duties)
- RFC 9110 — HTTP Semantics (the standard behind the link destinations and redirects discussed above)
In short
AI has made phishing emails fluent, well-written and tailored, so bad grammar is no longer a reliable warning sign. The signals that still work are structural: where a link actually goes, whether the request is unexpected or urgent, whether the channel fits the request, and what the authentication headers say. Build a routine around those, keep your main address for things that matter, and treat every unexpected request for action as something to verify before you act.