Real Phishing Email Analysis: Dissecting 5 Actual Attack Emails

Reading about phishing in the abstract is one thing. Staring at an actual phishing email and understanding exactly why it is dangerous is something else entirely. The difference between the two is the difference between knowing that fire is hot and understanding how arson investigations work.

In this article, we dissect five phishing emails modeled on real attack patterns we see constantly in the wild. Each example is fictional but built from the DNA of actual campaigns. We will walk through the headers, the authentication results, the social engineering mechanics, and the payload for each one. By the end, you should be able to look at any suspicious email and conduct this kind of analysis yourself.

For background on reading email headers, our complete guide to email headers covers the fundamentals.

Email 1: The Fake Microsoft 365 Password Reset

This is the single most common phishing template in circulation. It works because nearly every professional has a Microsoft 365 account, password resets are frequent and expected, and the urgency is built into the premise.

What the Recipient Sees

The email arrives with the subject line "Action Required: Your password expires in 24 hours." The sender display name shows "Microsoft 365 Team" and the body contains the Microsoft logo, a warning about password expiration, and a prominent blue button labeled "Update Password Now." The footer includes Microsoft's Redmond address and unsubscribe links.

What the Headers Reveal

From: "Microsoft 365 Team" <security@microsft-365notice.com>
Return-Path: <bounce-8472@microsft-365notice.com>
Received: from mail-out.microsft-365notice.com (192.184.xxx.xxx)
Authentication-Results: mx.recipient.com;
    spf=pass (sender IP matches) smtp.mailfrom=microsft-365notice.com;
    dkim=pass header.d=microsft-365notice.com;
    dmarc=pass (p=none) header.from=microsft-365notice.com

Everything passes authentication. SPF passes. DKIM passes. DMARC passes. This is the cousin domain technique in action. The attacker registered microsft-365notice.com (note the missing "o" in Microsoft) and set up full authentication. The domain was registered 48 hours before the campaign launched, which is itself a major red flag, but one that basic authentication checks will not catch.

What Gives It Away

The sending domain is not microsoft.com. Microsoft sends password notifications from @microsoft.com or @accountprotection.microsoft.com, never from a third-party domain. The "Update Password Now" button links to https://microsft-365notice.com/auth/reset?token=... rather than login.microsoftonline.com. The email creates artificial urgency with a 24-hour deadline. And the domain was registered two days ago, which any threat intelligence feed would flag.

How Filters Catch It

Domain age is the primary signal. Reputation-based systems flag newly registered domains aggressively. URL analysis catches the mismatch between the displayed brand and the actual link destination. Content analysis detects the password-reset template pattern combined with the non-Microsoft domain. Trained models recognize the urgency language pattern.

Email 2: The PayPal Payment Confirmation

This template exploits financial anxiety. Nobody ignores an email saying money left their account.

What the Recipient Sees

Subject: "Receipt for your payment of $847.99 to Electromart LLC." The email looks like a standard PayPal receipt with transaction ID, date, payment method (Visa ending in 4821), and a line item for "Premium Electronics Package." At the bottom: "If you did not authorize this transaction, click here to dispute it immediately."

What the Headers Reveal

From: "service@paypal.com" <service@paypal.com>
Return-Path: <noreply@cheap-vps-host.ru>
Received: from smtp.cheap-vps-host.ru (91.203.xxx.xxx)
Authentication-Results: mx.recipient.com;
    spf=fail smtp.mailfrom=cheap-vps-host.ru;
    dkim=none;
    dmarc=fail (p=reject) header.from=paypal.com

This one is crude. The attacker is directly spoofing paypal.com in the From header, but the actual sending infrastructure is a cheap VPS in Russia. SPF fails because cheap-vps-host.ru is not authorized to send for paypal.com. There is no DKIM signature. DMARC fails, and PayPal's DMARC policy is p=reject, which means any properly configured receiving server should reject this outright.

What Gives It Away

The Return-Path domain does not match the From domain at all. Complete DMARC failure. The "dispute" link points to a phishing page on an unrelated domain. The transaction amount is chosen to be alarming but not unbelievable. The Visa last-four digits are random, which means they will not match any card the recipient actually has, a detail that should immediately raise suspicion.

How Filters Catch It

DMARC rejection handles this one cleanly. PayPal has had p=reject DMARC for years, so any receiving server that enforces DMARC will bounce this email before it reaches the inbox. This is a textbook example of why DMARC matters and why major brands should always enforce rejection policies.

Email 3: CEO Impersonation (Business Email Compromise)

BEC attacks are the most financially devastating form of email fraud, responsible for over $2.7 billion in losses annually according to the FBI. They work because they exploit human authority dynamics rather than technical vulnerabilities.

What the Recipient Sees

Subject: "Quick favor - confidential." From: "David Chen" (the company's CEO). Body: "Hi Sarah, I need you to process a wire transfer urgently. I am in meetings all day and cannot call. Can you handle a payment of $43,200 to a new vendor? I will send the details once you confirm you can do this. Please keep this between us for now. - David. Sent from my iPhone."

What the Headers Reveal

From: "David Chen" <david.chen8847@gmail.com>
Return-Path: <david.chen8847@gmail.com>
Received: from mail-sor-f41.google.com (209.85.xxx.xxx)
Authentication-Results: mx.recipient.com;
    spf=pass smtp.mailfrom=gmail.com;
    dkim=pass header.d=gmail.com;
    dmarc=pass (p=none) header.from=gmail.com

Every authentication check passes perfectly because the email genuinely comes from Gmail. The attacker created a Gmail account with a name matching the CEO and sent a completely legitimate email through Google's infrastructure. There is nothing for SPF, DKIM, or DMARC to catch because no domain is being spoofed.

What Gives It Away

The email comes from a personal Gmail address, not the corporate domain. The request involves money and urgency. The "keep this between us" language is designed to prevent the recipient from verifying through other channels. There is no specific vendor name, invoice number, or business context. The "Sent from my iPhone" footer is meant to explain why the CEO is using a personal email, a common BEC tactic.

How Filters Catch It

Display name analysis can flag external emails where the sender name matches an internal executive. Some email security tools maintain an internal directory and compare incoming display names against it. Natural language analysis can detect the urgency-plus-money pattern. But honestly, many BEC emails slip through technical defenses because they contain no malicious links, no attachments, and no spoofed domains. This is where user training is not just helpful but essential.

Email 4: Fake Shipping Notification

This template explodes in volume during holiday seasons but runs year-round. It works because online shopping is constant and people rarely remember every order they have placed.

What the Recipient Sees

Subject: "Your package could not be delivered - action required." From: "DHL Express Tracking" with DHL branding, a tracking number (DHL-7829301847), a note that delivery was attempted but failed, and a button to "Schedule Redelivery." The email states that the package will be returned to sender if no action is taken within 48 hours.

What the Headers Reveal

From: "DHL Express Tracking" <tracking@dhl-delivery-update.net>
Return-Path: <tracking@dhl-delivery-update.net>
Received: from smtp2.dhl-delivery-update.net (45.77.xxx.xxx)
Authentication-Results: mx.recipient.com;
    spf=pass smtp.mailfrom=dhl-delivery-update.net;
    dkim=pass header.d=dhl-delivery-update.net;
    dmarc=pass (p=none) header.from=dhl-delivery-update.net

Another cousin domain attack with full authentication. The domain dhl-delivery-update.net looks plausible but is not a DHL property. DHL sends from @dhl.com and its regional variants. The attacker has set up the domain to pass all checks.

What Gives It Away

The domain is not dhl.com. The tracking number format does not match DHL's actual format. The "Schedule Redelivery" button leads to a credential harvesting page that first asks for personal details (name, address, phone) and then requests a small "redelivery fee" via credit card. The 48-hour deadline creates artificial urgency. Real delivery companies leave a physical notice and do not require online action to reattempt delivery.

How Filters Catch It

Brand impersonation detection compares visual elements and language patterns against known brand templates. URL reputation checks flag the link destination. Domain age analysis catches the newly registered domain. Content analysis detects the shipping notification pattern combined with a non-carrier domain and a request for payment information.

Email 5: LinkedIn Connection Request

Social media notification phishing is effective because these emails are frequent, expected, and people click them on autopilot.

What the Recipient Sees

Subject: "John Martinez wants to connect with you on LinkedIn." The email replicates LinkedIn's notification format: profile photo, name, job title ("Senior VP, Business Development at Apex Partners"), mutual connections (3), and buttons for "Accept" and "View Profile." A footer with LinkedIn's address and unsubscribe options completes the disguise.

What the Headers Reveal

From: "LinkedIn" <notifications@linkedinmail.org>
Return-Path: <bounce@linkedinmail.org>
Received: from mailer.linkedinmail.org (185.234.xxx.xxx)
Authentication-Results: mx.recipient.com;
    spf=pass smtp.mailfrom=linkedinmail.org;
    dkim=pass header.d=linkedinmail.org;
    dmarc=pass (p=quarantine) header.from=linkedinmail.org

This one is clever. LinkedIn actually sends some emails from linkedinmail.com, so linkedinmail.org is close enough to fool someone glancing at headers. Full authentication passes on the attacker's domain. The attacker even set a DMARC policy of p=quarantine on their own domain to appear more legitimate.

What Gives It Away

LinkedIn uses @linkedin.com or @linkedinmail.com, not .org. The "Accept" button links to a phishing page designed to harvest LinkedIn credentials. The profile photo is a stock image or AI-generated face. The mutual connections claim cannot be verified without logging in, which is the trap. Hovering over any link reveals the destination is not linkedin.com.

How Filters Catch It

Domain similarity analysis detects the near-match with LinkedIn's actual sending domain. URL analysis identifies the credential harvesting destination. Image fingerprinting can match the LinkedIn template against known phishing kits. And reputation systems flag the sending infrastructure, which is almost certainly shared with other phishing campaigns.

Patterns Across All Five Emails

Several themes emerge when you look at these examples together:

• Authentication alone is not enough. Three of the five emails passed SPF, DKIM, and DMARC completely. The two that failed only failed because they were crude direct-spoofing attempts.
• Urgency is universal. Every single email creates a time pressure: password expiring, unauthorized payment, CEO needs it now, package being returned, connection request waiting.
• The link is always the trap. In every case, the malicious payload is a URL leading to a credential harvesting page or malware download. Training users to hover before clicking remains one of the most effective defenses.
• Domain analysis is critical. In four of five cases, careful examination of the sending domain reveals the deception. This is something both automated systems and trained users can catch.
• Mobile makes everything worse. On mobile email clients, display names are prominent and actual email addresses are hidden. Every one of these emails becomes more dangerous on a phone.

Next time you receive a suspicious email, run through this same analysis. Check the actual sender address, not the display name. Look at the authentication results. Hover over every link before clicking. And if something feels urgent, that urgency itself is the biggest red flag of all.

For a quick-reference version of this analysis process, check out our email scam checklist.