AI-Written Phishing Emails: Why They Fool People and How to Check
For non-technical teams who need to judge suspicious email without becoming email experts. This guide explains why AI-generated phishing feels more believable, what signals still matter, and the practical checks you can do in your mail app, domain dashboard, and DNS records.
TL;DR — AI makes phishing emails more convincing because it removes the old clues people relied on: bad grammar, awkward tone, and obvious formatting mistakes. The most useful fix is to stop judging email by writing quality alone and instead check identity signals: the real sender domain, links before clicking, and whether your domain has SPF, DKIM, and DMARC records published. Reading time: ~7 min
What it is and where it sits
AI-written phishing is a normal phishing email with better writing. Instead of a scammer typing broken English, they use a large language model (LLM, a system that generates text from prompts) to produce polished messages that sound like your finance team, your CEO, a supplier, or a support desk.
That means the attack has not changed at the transport level. It still arrives through normal email systems: SMTP (the protocol used to send mail), your mail provider, and your inbox. What changed is the social engineering layer — the words, tone, and structure are now much more believable.
In a typical flow, AI sits before the email is sent. It helps the attacker write the message, personalize it, and sometimes generate many variations so spam filters see less repetition.
What it replaces:
- Obvious spelling mistakes and generic wording
- Reused scam templates that looked copied and pasted
- Poor localization for region, currency, or job role
What it does not replace:
- The attacker still needs a sending domain or compromised mailbox
- The attacker still needs links, attachments, or a reply target
- The email still passes through normal authentication checks like SPF, DKIM, and DMARC if your provider uses them
A simple architecture view:
View as text
[Attacker] ---- 1. prompt ----> [AI writing tool] [Attacker] <---- 2. polished email ---- [AI writing tool] [Attacker] ---- 3. send via SMTP ----> [Mail system] [Mail system] ---- 4. auth/filter checks ----> [Inbox] [Inbox] ---- 5. human reads ----> [User action] [User action] ---- 6. click/reply/pay ----> [Attacker site]
For your business, the important context is this: AI phishing is not mainly an "AI platform" problem. It is an email identity, user verification, and domain protection problem. The controls that matter most usually live in:
- Your email provider admin console
- Your DNS provider dashboard
- Your team's day-to-day inbox habits
How it actually works
Let’s walk one realistic example end to end.
Scenario: your operations manager receives an email that appears to be from a known supplier asking to update bank details before the next invoice payment.
Step 1: The attacker gathers context
They scrape your website, LinkedIn, prior breach data, or public invoices. They learn:
- your company name
- the supplier name
- the finance contact's title
- your timezone and writing style
Step 2: AI writes a tailored message
The attacker asks an AI tool for something like: write a polite email in UK English from a supplier accounts team, mention invoice timing, sound professional but slightly urgent, and avoid spammy phrases.
The result is dangerous because it removes the old warning signs. The message may:
- use the correct names and departments
- match local spelling like "authorise" or "favour"
- include realistic invoice language
- keep the urgency subtle instead of dramatic
Step 3: The attacker sends from a lookalike or compromised account
Common patterns:
- A lookalike domain such as
suppller-example.cominstead ofsupplier-example.com - A free mailbox with a display name like
Supplier Accounts - A real supplier mailbox that has already been compromised
This is why "the name looked right" is not enough. The display name is easy to fake.
Step 4: Your mail system checks technical signals
Your mail provider may check:
- SPF (a DNS record listing which mail servers may send for a domain)
- DKIM (a cryptographic signature proving a message was signed by the sending domain)
- DMARC (a DNS policy telling receivers what to do if SPF or DKIM checks fail, and where to send reports)
These checks help, but they are not magic:
- If the attacker uses a lookalike domain, SPF/DKIM can still pass for that fake domain
- If the attacker sends from a compromised real mailbox, the message may authenticate correctly
- If your own domain has weak or missing DMARC, attackers can spoof it more easily
Step 5: The human decision point
The user sees a well-written email and thinks, "This looks legitimate." That is the AI effect. It increases trust by improving language quality, not by changing how email fundamentally works.
Step 6: The practical checks that catch it
Here is the exact sequence a non-expert can use before clicking or paying:
-
Open the sender details in your mail app.
- In most mail apps, click the sender name or the down-arrow next to it to reveal the real email address.
- Compare the full domain after the
@, not just the display name.
-
Hover over links without clicking.
- On desktop, place the mouse over the link and read the destination shown by the mail app or browser status area.
- On mobile, long-press the link to preview the URL.
- Look for misspellings, extra words, or unrelated domains.
-
Check whether the request changes money, credentials, or urgency.
- Bank detail changes
- invoice rerouting
- password reset requests
- MFA (multi-factor authentication, a second login check) prompts you did not initiate
-
Verify using a second channel.
- Call the supplier using the number already in your records, not the number in the email.
- Start a fresh email to the known address from your contacts, instead of replying.
-
If it claims to be from your own domain, inspect your authentication setup.
- In your DNS provider's dashboard (for example, your provider's DNS or domain management area), open the zone for your domain and look for TXT records for SPF, DKIM, and DMARC.
When to use it (and when not to)
Here, "use it" means: when to treat AI phishing as a serious planning assumption and add checks or controls specifically for it.
| Scenario | Recommendation |
|---|---|
| Your team approves payments, payroll, or bank changes by email | Treat AI phishing as a high-priority risk. Add callback verification and tighten DMARC. |
| Your staff often work with suppliers, recruiters, or inbound sales emails | Add link-hover training and sender-domain checks. AI improves impersonation quality a lot here. |
| You run a public-facing business with staff names and roles visible online | Assume attackers can personalize emails easily. Review mailbox and domain protections. |
| You already rely on "bad grammar" as a scam signal | Change that habit now. It is no longer reliable. |
| You are a tiny team using one shared mailbox and no money moves by email | You still need basic checks, but you probably do not need a large anti-phishing program. |
| You want a tool that automatically proves every polished email is safe or malicious | You probably do not need to chase that idea; no single tool can do this reliably. Use layered checks instead. |
You probably don't need a complex new security product if your main gaps are basic ones:
- no DMARC record
- staff do not verify bank changes by phone
- people click links from display names without checking the real address
Fix those first. They usually produce more value than buying another dashboard.
Trade-offs
Every useful control has a cost.
| Benefit | What it costs |
|---|---|
| SPF, DKIM, and DMARC reduce spoofing of your domain | DNS work, testing time, and possible mail delivery issues if configured incorrectly |
| Stronger mail filtering catches more suspicious messages | False positives: legitimate mail may land in junk or quarantine |
| Callback verification for payment changes stops business email compromise | Slower operations and a little friction for finance teams |
| Staff training on sender and link checks improves judgment | Ongoing repetition is needed; one training session is not enough |
| Locking down supplier/payment workflows outside email reduces fraud | Process change, internal buy-in, and sometimes software changes |
| AI-aware simulations and exercises make teams less trusting of polished scams | Time cost and possible training fatigue if overused |
The biggest mindset trade-off is this: convenience versus verification. AI phishing succeeds because it feels smooth and normal. Your defenses work by adding a pause.
In practice
Below are practical things you can do today.
1) Publish a DMARC record in DNS
In your DNS provider's dashboard, open your domain, then add a TXT record. The menu path varies by provider, but it is usually something like: Domain Management → DNS → Add Record.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"
What it does: tells receiving mail systems to quarantine mail that fails DMARC checks and send aggregate reports to dmarc-reports@example.com.
Gotcha: do not jump straight to p=reject unless you have already checked that your legitimate senders pass SPF or DKIM. A strict DMARC policy can block real mail if your setup is incomplete.
2) Publish a basic SPF record
Again in your DNS dashboard, add or edit the TXT record for your root domain.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com -all"
What it does: says only Google-authorized mail servers may send mail for example.com.
Gotcha: your domain must have only one SPF TXT record. If you already have one, edit it instead of adding a second SPF record, or receivers may treat it as invalid.
3) Check a suspicious sender domain from a terminal
If you do have shell access, you can inspect whether a domain publishes DMARC and SPF.
dig TXT _dmarc.example.com +short
dig TXT example.com +short
What it does: prints the TXT records for DMARC and SPF so you can see whether the domain has any published policy.
Gotcha: this does not prove a specific email is safe. It only shows whether the domain has authentication records. A lookalike domain can also publish valid records.
4) Create a simple internal verification rule for finance changes
Put this in your team handbook, ticket template, or approval form.
{
"request_type": "bank_details_change",
"required_checks": [
"Read full sender address, not display name",
"Do not use phone numbers or links from the email",
"Call the supplier using the number already stored in ERP/accounting records",
"Require second approver before payment data is changed"
],
"email_only_approval_allowed": false
}
What it does: turns a vague warning into an explicit process that staff can follow.
Gotcha: a rule hidden in a policy folder will not help much. Put it where the action happens: in the finance workflow, approval form, or payment checklist.
⚠️ If you change SPF, DKIM, or DMARC records on a live domain without checking your current mail senders, you can cause legitimate email delivery failures. Before editing DNS, list every service that sends mail for your domain: your mailbox provider, marketing platform, support desk, invoicing tool, and website forms.
Further reading
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM)
- The "Email authentication" documentation from your mail provider's admin docs
- The "Social engineering" guidance in your security awareness training materials
This article was written by an AI system and published pending human review. Verify anything you intend to act on.
Have a project in mind?
Get an instant AI price estimate for it, or talk directly to our team.
One email a month on what we learn building with AI