Identify 'Phishing' Emails by Checking Header Info

Why the Visible Sender Name Can't Be Trusted

The "From" name and address you see in your inbox are just text fields set by whoever sent the email — nothing stops an attacker from typing "PayPal Support" or spoofing support@paypal.com in the display. What can't be easily faked without leaving evidence is the trail of routing information every email carries underneath: the raw headers. These are added by every mail server the message passed through on its way to you, and they include authentication results that tell you whether the sending server was actually authorized to send mail for that domain. Reading them is the most reliable way to confirm whether an email is really from who it claims to be.

Viewing Raw Headers

The exact menu path depends on your mail client:

• Gmail (web): open the email, click the three-dot menu in the top-right of the message, and choose Show original.
• Outlook (web/new Outlook): open the email, click the three-dot menu, choose View > View message details (or "View message source" depending on version).
• Outlook (classic desktop): open the message in its own window, go to File > Properties, and look at the "Internet headers" box at the bottom.
• Apple Mail: select the message, go to View > Message > All Headers (or Raw Source).

This gives you a block of plain text formatted per RFC 5322, the standard that defines email header syntax. It looks intimidating, but you only need to check a handful of specific fields.

Checking Authentication Results

Look for a header called Authentication-Results, usually added by your own mail provider. It summarizes three checks:

• SPF (Sender Policy Framework) — verifies the sending mail server's IP is authorized in the claimed domain's DNS records.
• DKIM (DomainKeys Identified Mail) — verifies a cryptographic signature proving the message wasn't altered in transit and was signed by the claimed domain.
• DMARC — a policy that tells receiving servers what to do when SPF or DKIM fail (reject, quarantine, or do nothing).

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of admin@paypa1-secure.com does not designate 203.0.113.55 as permitted sender) smtp.mailfrom=admin@paypa1-secure.com;
       dkim=none (message not signed);
       dmarc=fail (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com

Any of these showing fail — especially combined with a mismatch between the domain in the "From" address and the domain that actually sent the mail — is a strong phishing signal. A legitimate email from a major company will almost always pass all three.

Comparing Return-Path and From

Look for the Return-Path header (sometimes shown as Envelope-From) and compare it against the visible From header:

From: PayPal Security <service@paypal.com>
Return-Path: <bounce-8k2j@marketing-blast-247.ru>

The Return-Path is where bounce notifications get sent, and legitimate senders often use a different subdomain for this (that's normal for services like Mailchimp or SendGrid sending on behalf of a company). But a Return-Path pointing at a completely unrelated, suspicious domain — especially one with a different TLD or random characters — is a red flag worth digging into further.

Tracing the "Received" Chain

Every server that handles the message adds a Received header, stacked with the newest at the top and the original sender at the bottom. Read from the bottom up to trace the message's actual origin:

Received: from mail-relay-09.suspicious-host.net (203.0.113.55)
    by mx.google.com with SMTP; Tue, 18 Aug 2026 09:14:22 -0700
Received: from [10.0.0.4] (unverified [203.0.113.55])
    by internal-mta.example.com; Tue, 18 Aug 2026 09:14:18 -0700

The bottom-most Received line tells you the IP address and hostname of the machine that first introduced the message into the mail system. If that hostname or IP has nothing to do with the company the email claims to be from, that's another confirmation. You can paste the IP into a WHOIS lookup or an abuse-check tool like AbuseIPDB to see if it's already flagged.

A Quick Checklist

1. Open the raw headers using your client's "Show original" / "View source" option.
2. Check Authentication-Results for SPF, DKIM, and DMARC — any failure is suspicious.
3. Compare the domain in From against Return-Path and the bottom-most Received header.
4. Look closely at the sending domain for lookalike tricks: substituted characters (paypa1), extra words (paypal-support-verify.com), or unfamiliar TLDs.
5. If in doubt, don't click anything in the email — navigate to the company's site directly by typing the URL yourself.

Wrap-Up

Reading raw headers takes an extra minute, but it moves you from "does this email look legitimate" — which is exactly what a well-crafted phish is designed to pass — to "did this email actually originate from where it claims," which is much harder to fake. Make it a habit for anything asking you to log in, verify an account, or move money, and you'll catch the vast majority of spoofed sender attempts before they cost you anything.