Phishing Variant Comparison
| Type | Medium | Targeting | Typical Goal | Sophistication |
|---|---|---|---|---|
| Phishing | Mass (anyone) | Credential harvest, malware delivery | Low | |
| Spear Phishing | Specific individual | Targeted credentials, APT access | Medium–High | |
| Whaling | C-suite executives | BEC, financial fraud, strategic data | High | |
| Vishing | Phone | Specific or random | Credential reset, info gathering | Medium |
| Smishing | SMS | Mass or targeted | Link clicks, credential harvest | Low–Medium |
| Clone Phishing | Prior email recipient | Credential harvest via trusted content | Medium | |
| Pharming | DNS / Hosts file | Everyone visiting a domain | Credential harvest at scale | High |
Phishing Email Anatomy
DISPLAY NAME
The attacker controls this field freely and independently of the actual sending address. "Microsoft Support," "DocuSign," "HR Department" — any name can be set. Most email clients display this prominently. Many users never look past it to the actual email address. This is the most commonly exploited field in phishing.
FROM ADDRESS (Actual Email)
The actual sending email address — separate from the display name. Look for cousin domains: microsoft-support.com instead of microsoft.com, micros0ft.com, paypa1-security.com. The attacker hopes the recipient never looks past the display name. Always expand the sender information and verify the actual domain, not just the displayed name.
SUBJECT LINE
Designed to trigger urgency, fear, or curiosity — but calibrated to avoid spam filters. Common patterns: "Action Required," "Account Suspended," "Unusual Sign-in Detected," "Failed Delivery Attempt," "Invoice Attached." Urgency prevents reflection; specificity adds credibility. Excessive urgency ("ACT NOW OR LOSE ACCESS FOREVER") is itself a red flag.
EMAIL BODY
High-fidelity copy of the legitimate brand's email template — correct logos, colors, fonts, and footer. Tells: generic greeting ("Dear Customer" instead of your name — though spear phishing uses your real name), grammar errors, slightly wrong formatting, incorrect footer details. A professional-looking phishing email may have none of these tells — never rely on appearance alone.
LINK DISPLAY TEXT vs. ACTUAL URL
In HTML, the text you see and the URL you go to are completely independent: <a href="http://evil.com">Click to verify your Microsoft account</a>. The display text can say anything. The HREF goes anywhere. HOVER OVER EVERY LINK before clicking. Check the domain in the browser status bar. The domain is the registerable portion — everything before the first slash after the protocol.
LANDING PAGE (Credential Harvest)
A pixel-perfect copy of the legitimate login page, served from the attacker's domain. When credentials are submitted, they are captured and logged. The user is immediately redirected to the real site, which logs them in normally — they notice nothing. The session on the attacker's site is complete. The redirect is the reason most phishing victims never realize they were phished.
Email Authentication Flow: SPF → DKIM → DMARC
1
Email arrives claiming to be from ceo@company.com
The receiving mail server begins authentication checks. The "from" domain is company.com — the server looks up company.com's DNS records for authentication policies.
The receiving mail server begins authentication checks. The "from" domain is company.com — the server looks up company.com's DNS records for authentication policies.
↓ SPF Check
2
SPF: Is this sending server authorized?
The receiving server looks up company.com's SPF record in DNS. Is the sending server's IP address on the authorized list? YES → SPF pass. NO → SPF fail. SPF validates the sending server only — not the message content.
The receiving server looks up company.com's SPF record in DNS. Is the sending server's IP address on the authorized list? YES → SPF pass. NO → SPF fail. SPF validates the sending server only — not the message content.
↓ DKIM Check
3
DKIM: Is the message signature valid?
The receiving server finds the DKIM-Signature header in the email. It looks up company.com's DKIM public key in DNS. Does the public key verify the signature over the email headers and body? VALID → DKIM pass. INVALID or MISSING → DKIM fail. DKIM validates message integrity and server authorization.
The receiving server finds the DKIM-Signature header in the email. It looks up company.com's DKIM public key in DNS. Does the public key verify the signature over the email headers and body? VALID → DKIM pass. INVALID or MISSING → DKIM fail. DKIM validates message integrity and server authorization.
↓ DMARC Policy Check
4
DMARC: What to do with the result?
If SPF or DKIM failed, the receiving server checks company.com's DMARC record. What is the policy? none → deliver and log. quarantine → send to spam. reject → block the email entirely. DMARC is what gives SPF and DKIM their teeth. Without it, failures are observed but not acted on.
If SPF or DKIM failed, the receiving server checks company.com's DMARC record. What is the policy? none → deliver and log. quarantine → send to spam. reject → block the email entirely. DMARC is what gives SPF and DKIM their teeth. Without it, failures are observed but not acted on.
↓ Final Disposition
5
Email Delivered, Quarantined, or Rejected
If reject: email blocked before delivery. If quarantine: email goes to spam. If none (or no DMARC record): email delivered regardless of SPF/DKIM results — failures are logged and reported to the domain owner, but the email reaches the inbox. Many organizations stay at "none" for monitoring and never advance to "reject."
If reject: email blocked before delivery. If quarantine: email goes to spam. If none (or no DMARC record): email delivered regardless of SPF/DKIM results — failures are logged and reported to the domain owner, but the email reaches the inbox. Many organizations stay at "none" for monitoring and never advance to "reject."
DMARC reporting: even at "none" policy, DMARC generates reports sent to the domain owner's rua/ruf addresses. These reports reveal who is sending email claiming to be from your domain — valuable intelligence even before enforcement is enabled. Moving from none → quarantine → reject is a standard rollout sequence.
Defense Layers Against Phishing
| Layer | Controls | What It Stops |
|---|---|---|
| Layer 1 — Email Gateway (Technical) | SPF/DKIM/DMARC enforcement, URL scanning at delivery and click-time, attachment sandboxing, external email warning banners | Blocks spoofed emails, known phishing URLs, malicious attachments before they reach the user |
| Layer 2 — Endpoint and Account (Technical) | MFA on all accounts (blocks credential replay even after successful phishing), phishing-resistant MFA for privileged accounts (credentials cannot be captured by phishing sites), DNS filtering (blocks access to known phishing domains) | Prevents account takeover even when credentials are stolen; blocks access to phishing infrastructure |
| Layer 3 — Human | Security awareness training, simulated phishing campaigns (experience-based learning), hover-before-click habit, verify unexpected requests through independent channels | Reduces click-through rates; creates habits that catch phishing emails technical controls miss |
| Layer 4 — Process | One-click "Report Phishing" button, rapid phishing investigation, incident response plan for credential compromise, wire transfer verification policy (callback to known number) | Limits damage when phishing succeeds; enables rapid response; protects against BEC financial fraud |
The most impactful single control is MFA. Even if every other layer fails and an attacker harvests credentials, MFA prevents those credentials from being used for account takeover. Phishing-resistant MFA (FIDO2/passkeys) eliminates even real-time relay attacks. Implement MFA before anything else.