How to Detect Email Phishing Fast: A Practical Step-by-Step Guide for NOC Engineers

Skip the lecture. Here’s the deal: phishing is still the fastest way attackers get into your mail server, your cPanel, or your client’s inbox – and honestly, most of it is detectable in under five minutes if you know what to look at. I run mail infrastructure that sees thousands of messages a day, and I can’t even count how many phishes we’ve intercepted. This is the exact checklist I use when someone forwards me a suspicious email. Steal it.

Think of an email like someone ringing your doorbell claiming to be from the building management. You wouldn’t hand over your keys without checking their ID, right? Same logic applies here – you just need to know which ID cards to inspect. This guide shows you, step by step, how to check the sender, the headers, the links, and the attachments. No fluff, no theory – just what to do.

Why Learning How to Detect Email Phishing Is Not Optional

Let’s be honest about why this matters. One phished credential doesn’t just cost the person who clicked. It costs the whole server. Once an attacker owns a mailbox, they’ll use it to blast more phishing from your IP. Your domain reputation tanks, mail scores drop, legitimate email starts bouncing, and you end up un-blacklisting IPs at 2 AM. That’s the job nobody wants, and it’s completely avoidable if detection becomes a habit.

The phishing game keeps evolving, and it’s worth paying attention. It’s no longer just “You won a prize.” Now it’s fake invoices that mirror real vendors, fake login warnings that mimic Google or AWS, and spear phishing that references your actual projects by name. Generative AI has also made phishing emails a lot more polished – bad grammar used to be a giveaway, and honestly, that’s not reliable anymore. So you need a repeatable method, not gut feeling. This checklist is that method.

One thing I keep seeing in incident after incident: the phishing email itself was almost never perfect. There was always something slightly off – a wrong domain, a mismatched header, a URL that didn’t match the display text. The problem was that nobody was looking. So the real question isn’t “how do attackers hide?”, it’s “are you even checking?” Let’s make sure you do.

The Classic Red Flags (Know These Cold)

Before the technical part, get the basic patterns in your head. In my experience, phishes almost always hit one or more of these:

• Manufactured urgency – “Your account will be suspended in 24 hours”, “Invoice overdue, payment required today”. It’s pressure so you don’t stop to think.
• Weird sender address – the display name looks legit, but the actual address is off. Like support@go0gle-security.com or security@bankmikrojaya.co.id-secure.net.
• Unexpected links or attachments – a “Click here to log in” button, or a .zip / .docm / .html you never asked for.
• Requests for sensitive data – password, OTP, card number, or “log in via this link”. No legitimate service asks for your password over email. Ever.

If you spot two or more of these together, stop. Don’t click, don’t reply, and don’t forward it to a colleague either (that’s how it spreads). Mark it as suspicious and run it through the steps below.

Step 1: Check the Sender Address, Not the Display Name

This is the cheapest check and the most skipped one. The display name is trivially easy to fake – I’ve seen “Bank Mikro Jaya Security” sitting on an email sent from a random .xyz domain. Always expand the sender details and read the actual address. In Gmail, click the sender name and pick “View details”, or open “Show original” from the three-dot menu. In Outlook desktop, double-click the message, go to File > Properties, and read the Internet headers. In Thunderbird, View > Headers > All.

Here’s a pattern I’ve seen dozens of times:

Display name: Bank Mikro Jaya Security
Actual address: security@bankmikrojaya.co.id-secure.net   <-- wrong domain

Display name: Dinas Perpajakan
Actual address: info@pajak-nasional.info.top             <-- cheap TLD

The real bank domain is bankmikrojaya.co.id. The attacker registered bankmikrojaya.co.id-secure.net, which reads almost identically until you look closely. This is called domain impersonation. There’s an even sneakier variant called a homograph attack, where letters are swapped for visually similar ones – “o” becomes “0”, “l” becomes “1”. Read it slowly, character by character.

Step 2: Read the Headers – Check SPF, DKIM, and DMARC

Now we’re at the heart of how to detect email phishing reliably. Email headers are the fingerprint of a message. They record the full journey from origin server to your inbox, and they tell you whether the message is really from the domain it claims to be from. Here’s a real example (sanitized, obviously) from a phish that hit one of our mailboxes:

Received: from mail.gw-client-a.com (mail.gw-client-a.com. [203.0.113.25])
        by mx1.client-a.com with ESMTP id 1ABCde-0000XyZ-00
        for billing@client-a.com; Thu, 06 Aug 2026 09:41:12 +0700
Received: from [192.0.2.34] (unknown [192.0.2.34])
        by mail.gw-client-a.com (Postfix) with ESMTPSA id 7c1e2f
        for billing@client-a.com; Thu, 06 Aug 2026 09:40:58 +0700
DKIM-Signature: v=1; a=rsa-sha256; d=sentosa-invoices.com; s=default;
        c=relaxed/simple; q=dns/txt; bh=1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d;
        h=From:Subject:Date:To;
        b=8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f
Authentication-Results: mx1.client-a.com;
        spf=fail (203.0.113.25 is not allowed to send mail for
        ptsentosajaya.co.id) smtp.mailfrom=ptsentosajaya.co.id
        dmarc=fail header.from=ptsentosajaya.co.id
From: "PT Sentosa Jaya - Finance" <invoices@ptsentosajaya.co.id>
To: billing@client-a.com
Subject: Invoice 20891 - Payment overdue
Date: Thu, 06 Aug 2026 09:40:44 +0700
Content-Type: application/pdf; name="invoice-20891.pdf"
MIME-Version: 1.0
Content-Disposition: attachment; filename="invoice-20891.pdf"

Let’s walk through it line by line, because this matters:

• Top Received line – the message arrived at mx1.client-a.com from mail.gw-client-a.com. Normal last hop.
• Bottom Received line – here’s the problem. The message was actually handed to the relay from IP 192.0.2.34, a random host, not PT Sentosa Jaya’s mail server. First mismatch.
• DKIM-Signature – note the d= value. The signing domain is sentosa-invoices.com, not ptsentosajaya.co.id. The signature is valid, but for the wrong domain. Attackers own the lookalike domain, so they can sign it themselves.
• Authentication-Results – this is the receiver’s official verdict – spf=fail and dmarc=fail. That’s your biggest red flag right there.
• From line – the actual sender address. Note it also carries a PDF attachment you never requested.

Trace it like this: symptom (invoice from a supplier) – pattern (unknown source IP, DKIM for the wrong domain, SPF/DMARC fail) – root cause (message is not from the real company). One verdict: phishing. If you’re on the server side, you can grep the same results out of your mail logs. On Exim:

grep -i "spf" /var/log/exim/mainlog | tail -20

Or inspect a single message still sitting in the queue:

exim -Mvh <message-id>

If you want to go deeper on reading headers, I’ve written a longer piece on how to read email headers that covers the trickier fields.

Step 3: Inspect Links Without Clicking

This is where people lose the game. They see a link, get curious, and click. Don’t. On desktop, hover over the link and read the URL that appears in the browser status bar. On mobile, press and hold the link – the preview URL pops up before you open anything.

Shortened URLs (bit.ly, tinyurl, and friends) are a favorite obfuscation trick. If you’re curious where one actually goes, resolve it first without your browser touching the page:

curl -sIL "https://bit.ly/xxxxxx" | grep -i "^location"

That prints the destination URL before you actually visit it. You can also paste the URL into urlscan.io for a full page analysis in a sandbox, or drop it into VirusTotal to see if any engine flags it as phishing or malware. Watch out for typosquatted domains (one letter off) and cheap TLDs like .xyz, .top, .club, or .site – they require no real verification and are heavily used by phishers.

Step 4: Don’t Open Unexpected Attachments

Phishing attachments come in a few flavors: .zip files hiding an .exe, .docm with enabled macros, PDFs that link to a fake login page, or .html files that are self-contained fake login forms. If you weren’t expecting a file, don’t open it. If the task genuinely needs it, verify with the sender through a separate channel – a phone call, a WhatsApp message, a direct chat. Not by replying to the email.

If you receive a suspicious attachment and want to analyze it safely, upload it to a sandbox like any.run or Hybrid Analysis. The sandbox executes the file in an isolated environment and reports its behavior – which domains it contacted, which processes it spawned, which files it created. That’s a lot better than finding out the hard way on your production machine.

Step 5: For Admins – Move Detection to the Server Side

Most “how to detect email phishing” articles stop at the recipient side. For NOC folks and sysadmins, that’s not enough. You can catch most of this at the gateway before it ever reaches an inbox. Here’s what I’d prioritize:

5a. Make Sure Your Own SPF, DKIM, and DMARC Are Complete

Funny thing about mail admins: a lot of them have impeccable filters, yet their own domains lack SPF/DKIM/DMARC. That makes their domain trivial to spoof. Check first:

dig +short TXT client-a.com | grep spf
dig +short TXT default._domainkey.client-a.com
dig +short TXT _dmarc.client-a.com

If any record is missing, fix it. This isn’t just about your own reputation – it gives other mail servers a clean way to reject phishes that pretend to come from you. Full walkthrough here: SPF, DKIM and DMARC setup guide.

5b. Watch Mail Logs for Anomaly Patterns

When an account gets phished, the logs usually tell you before you notice anything else. Watch for:

grep -i "auth failed" /var/log/exim/mainlog | tail -20
grep "login.*smtp" /var/log/mail.log | awk '{print $4}' | sort | uniq -c | sort -rn | head

• Successful logins from foreign IPs, especially VPN or proxy ranges you’ve never seen.
• A sudden spike in outbound mail volume – a classic sign the account is being used to send phishing.
• Outbound bursts to many domains at once with similar subjects.

If you see these, act immediately: suspend the account, reset the password, and revoke every active session. Don’t wait for the attacker to hop between accounts. For cleaning spam out of the queue, see my Exim mail queue troubleshooting guide.

5c. Add Layered Spam Filtering

Rspamd and SpamAssassin are your friends. Rspamd has a dedicated phish module plus a FANN classifier that can catch phishing URLs in message bodies:

rspamadm configdump phish

Layered filtering means suspicious mail gets blocked at the gateway, not delivered to a confused user at 9 AM. It’s a small investment with a huge payoff. Here’s how to set it up: install Rspamd as an anti-spam filter, plus Postfix mail server hardening for the rest.

Quick Decision Table

Bookmark this. It’s the 30-second version of the whole article.

Already Clicked? Run This Playbook

It happens to the best of us. If you or someone on your team already clicked, don’t panic and don’t play the blame game. Do this, in order:

1. Kill the access now – rotate the password, revoke sessions, log out every device, and enable 2FA if it wasn’t already.
2. Check the outbound queue – see what’s queued and identify anything that shouldn’t be there:

exim -bp | head -30

SECURITY WARNING: Backup before continuing. Before you remove any message from the queue, (1) save the queue listing first with exim -bp > /tmp/queue-backup-$(date +%Y%m%d).txt, (2) verify the message-id you’re about to delete is genuinely the phishing email, not a legitimate client message, (3) when in doubt, leave it queued. Deleting without a backup can cause permanent data loss.

Once you’re certain, remove messages one by one:

exim -Mrm <message-id>

3. Warn your contacts – tell them your account may have been used to send phishing. People can’t be careful about something they don’t know about.
4. Scan devices and accounts – run an antivirus scan, check for unknown browser extensions, review recently installed apps. If it happened on a server, check running processes and startup entries.
5. Report it – forward the phish to [email protected], and submit the URL to Google Safe Browsing or PhishTank so it gets blacklisted for everyone.

Wrap-Up

There it is. How to detect email phishing in practice, from the cheap checks (sender address, urgency, tone) up to the technical ones (headers, SPF/DKIM/DMARC, source IPs) and the server-side defenses that catch the rest before it reaches anyone. Detection isn’t a one-time skill – it’s a routine. Run it on every unexpected email and it takes seconds.

Take this checklist, share it with your team, and make it a habit. Practice on real emails, test each other, and build the instinct. If your team can catch a phish before clicking, you’ve already won more than half the battle – your IP stays clean, your clients stay safe, and your nights stay quiet. Done. Now go apply it.