Anatomy of a phishing email: what's happening under the hood

Phishing works not because people are careless, but because the emails look right. The From field shows a real bank name. The logo matches. The link differs from the real one by a single character. To tell a fake from the genuine article, you have to look past the text and into the technical structure. That's what this piece covers.

Why phishing still works in 2026

According to the Anti-Phishing Working Group, over 4.7 million phishing attacks were recorded in 2025. The number climbs every year despite spam filters, security training, and compliance certifications. The reason is straightforward: phishing evolves faster than awareness.

Ten years ago a phishing email was easy to catch: broken grammar and a link like http://192.168.1.1/login. Today, attacks use registered domains with SSL certificates, copy HTML email templates pixel-for-pixel, and route sends through legitimate ESPs that pass SPF checks.

Visual inspection is no longer reliable. You need the technical layer.

Email headers: the first diagnostic layer

Every email has two layers: the body (the HTML or text the recipient sees) and the headers (metadata that only the mail client reads). Phishers put effort into the body. They fake headers less convincingly, because many headers are set by servers, not senders.

To view headers in Gmail: open the message, click the three-dot menu, select Show original. In Outlook: File → Properties → Headers. In Thunderbird: View → Message Source. The output looks dense, but only a handful of fields matter.

From vs. Return-Path vs. Received

The From field is what users see. Anyone can set it. SMTP has no requirement that From match the actual sending server, which is exactly how you can receive an email "from your bank" sent by a server in a completely different country.

Return-Path (also called the envelope sender) is where bounce notifications go. Legitimate senders usually have it on the same domain or subdomain as From. With phishing, it often points somewhere else entirely.

The Received chain records every server the message passed through. Read it bottom to top: the lowest entry is the originating server. If an email claims to be from google.com but the first Received line shows an IP block from a shared hosting provider in Southeast Asia, that's a red flag.

The word unknown instead of a PTR record is suspicious. Real bulk senders always have reverse DNS configured: the IP resolves back to a hostname that matches the sending domain.

SPF, DKIM, DMARC: three checks that decide everything

If you already know these protocols, skip to the next section on how phishers bypass them. If not, here's the thirty-second version.

SPF is a DNS record listing the IP addresses authorized to send mail for a domain. DKIM is a cryptographic signature on each message, with the public key stored in DNS. DMARC is the policy: what to do when SPF or DKIM fail, plus aggregate reporting.

In a legitimate message's headers, the receiving server stamps an Authentication-Results line:

Three pass results are the best sign you can get. A single fail is worth investigating. If you see dmarc=fail but the message still landed in the inbox, the sending domain is running p=none: a monitoring-only policy that blocks nothing. Phishers know this and deliberately target domains configured that way.

How phishers get around authentication

Blunt spoofing, faking a From address without any SPF or DKIM setup, works less and less. Gmail and other providers filter those messages before they reach inboxes. But attackers have workarounds.

Lookalike domains. Instead of spoofing an existing domain, attackers register a similar one: paypa1.com instead of paypal.com, or amazon-support.net instead of amazon.com. That domain gets its own SPF and DKIM records, and they pass. Technically everything checks out. The problem is only in the name.

Compromised ESP accounts. An attacker signs up for Mailchimp or SendGrid, connects a domain, configures SPF and DKIM properly. The send passes authentication because it is technically correct. You can only tell by the content and the domain's reputation history.

Display name spoofing. The simplest trick, still effective. The sender name in From says something like "Chase Bank Security" while the actual address is info@random-domain.xyz. On mobile, the address is often hidden; only the display name shows. A lot of users never expand it to check.

Subdomains without a DMARC policy. If the root domain has p=reject but the record lacks sp=reject, subdomains are unprotected. A message from support.example.com with no separate DMARC record for that subdomain can slip through.

Phishing in 2026 is not about hacking servers. It exploits the gap between what the protocol checks and what the human sees.

Links: where the substitution hides

In an HTML email, the visible text of a link and its actual href are two separate things. The email can display "yourbank.com/login" while pointing to yourbank-login.phishing-site.com. The check is simple: hover over the link and read the destination. On mobile that's inconvenient, and under time pressure it gets skipped.

A more sophisticated technique chains redirects through trusted services. The email contains a Google Docs link that bounces to a phishing page. Or a URL shortener: bit.ly, clck.ru. The initial domain looks safe; the destination does not.

Punycode domains are another red flag. Cyrillic "а" and Latin "a" are visually identical but different Unicode code points. The domain xn--80ak6aa92e.com can render in a browser address bar as a familiar word. Modern browsers have partial protection against this; email clients are weaker.

One reliable rule: if an email asks you to log into a bank, payment service, or personal account, do not click the link. Open the site directly through a bookmark or the browser address bar. That's the only approach that holds every time.

Content signals that give the fake away

Header analysis is reliable but requires some skill. These content patterns are faster to spot.

Urgency without context. "Your account will be suspended in 24 hours" is the classic. Legitimate services rarely open with hard deadlines. Usually there's a sequence: first notice, second notice, final warning. Phishing hits immediately because it has no second chance.

Requests for sensitive data. Password, CVV, SMS code. No bank and no legitimate service ever asks for these over email. If the email asks, it's phishing. No exceptions.

Tone mismatch. A company that normally writes casually in support threads suddenly sends bureaucratic language. Or a government agency sends exclamation marks and emoji. Tone is hard to fake at scale, especially in mass campaigns that aren't targeted to a specific individual.

Unexpected file types. .html, .exe, .iso, .img, .scr attached to something from "accounting" or a "courier service." Macros in .docx files that ask you to "enable content." A password-protected archive where the password is in the email body (the password prevents antivirus scanners on the mail server from opening the file).

Tools for verifying a suspicious email

If an email raises doubts, a few free tools can help you investigate.

• Google Admin Toolbox (Messageheader). Paste the full headers and get a breakdown: routing path, authentication results, and timing gaps between servers.
• MXToolbox Header Analyzer. Similar analysis with a visual view of the Received chain and IP reputation checks against blocklists.
• VirusTotal. Scans attachments and URLs against dozens of antivirus engines. If a link in the email looks wrong, copy it (without clicking) and paste it into VirusTotal.
• Whois. Check when the sender's domain was registered. An email claiming to be from a major bank sent from a domain created two days ago is self-explanatory.

Larger organizations have more options: SIEM platforms that parse incoming headers automatically, and sandboxes that open attachments in an isolated environment. Those come with enterprise budgets and are a separate conversation.

Phishing and email campaigns: the connection is closer than it looks

If you run email marketing, phishing is your problem even if you're not the target. Here's why.

Phishing campaigns pollute the email ecosystem. Providers tighten their filters, raise thresholds, and send more messages to spam on a precautionary basis. Legitimate senders suffer for it. If your domain setup is loose, SPF without a hard -all, DKIM with a 1024-bit key, DMARC at p=none, your messages land in the same "questionable" bucket as phishing.

The second connection is your subscriber list. Phishers harvest addresses too: leaked databases, scraping, pattern generation. Addresses that appear in phishing sends get flagged by providers. If those same addresses are in your list and you mail them, your domain reputation takes the hit by association.

Then there are honeypot addresses. Providers and anti-phishing organizations seed these traps in public sources. Sending to one earns a reputation penalty regardless of whether the message is a phishing attempt or a standard newsletter. The trap does not distinguish.

List validation as a way to stay out of the same category as phishers

Clean authentication (SPF, DKIM, DMARC at p=reject) protects against others sending mail in your name. It does not protect you from damaging your own reputation by mailing dead addresses and spam traps.

That's where validation comes in. Checking your list before a send removes invalid addresses, disposable inboxes, and high-risk contacts. The result: lower bounce rate, fewer complaints, better domain reputation. Providers see you sending only to addresses that expect mail. Your messages pass the filters that exist because of phishing.

It runs in reverse too. If you're getting suspicious signups, bots, address generators, random entries, validation at the registration step filters them before they reach the list. Less garbage at the front end means a cleaner list and better deliverability downstream.

Quick checklist for a suspicious email

1. Expand the full sender address. Does it match the expected domain?
2. Open the headers. Are spf=pass, dkim=pass, dmarc=pass all there?
3. Compare the From domain and Return-Path. Do they match, or at least belong to the same organization?
4. Hover over links (don't click). Does the URL go where the link text claims?
5. Check the link's domain via Whois. When was it registered?
6. Is the email asking for a password, CVV, or verification code? If yes, it's phishing.
7. Is there an unexpected attachment (.html, .exe, a password-protected archive)? Do not open it.
8. Not sure? Go to the site directly through your browser, not through the email link.

This list won't stop targeted spear-phishing built for a specific person. Against the mass attacks that make up roughly 95% of phishing volume, it works well.

Phishing is an arms race. Attackers refine their fakes; defenders refine their filters. As a sender you sit in the middle: your job is to make sure no one confuses you with either side. Solid authentication and a clean list are the two things that separate your domain from phishers in a provider's eyes. Without one of them, you're in the risk zone.