These 3 email headers prove a message is fake — here’s how to check

Fraud is prevalent in our society, and if you’re not careful, you may approve a wire transfer just because the email looks legitimate. Bad actors have perfected the art of making the logos crisp, matching the sender name with your vendors’, and giving just the right amount of urgency to a subject line. In the end, they may fool even the smartest among us.

However, the real problem is that when you receive an email, you typically ascertain authenticity by judging what’s visible. I once talked about a checklist to use before opening PDFs, but there’s also a set of parameters to check before assuming an email is authentic. The real information to watch out for often lives in the metadata.

The “From” field doesn’t prove who sent the email

Authentication validates a domain, not a brand

Afam Onyimadu / MUO

Learn to distrust the display name because, in the grand scheme of things, it really doesn’t prove anything. Of course, it is generally conspicuous, especially if you use Gmail or Outlook, but this is only because of the way most of these email clients are built; they prioritize convenience rather than verification.

Receiving an email that clearly says “PayPal Security” doesn’t mean PayPal sent it. The actual sender may be noreply@paypa1-secure.ru, with the lower case “L” in PayPal swapped out for “1.” This can trick you if you’re in a hurry. To see the real sender, check the From header for the sender’s email in angle brackets. However, this alone cannot give a final confirmation of authenticity. You must inspect the mail source. In Gmail, open the email, click the three dots beside the reply icon, and click Show original; in Outlook desktop, navigate to File -> Properties -> Internet Headers; in Apple Mail, navigate to View –> Message –> All Headers. On the Original Message page, the three pieces of data that matter are From, Return-Path, and Authentication-Results (SPF, DKIM, and DMARC outcomes).

The values for SPF, DKIM, and DMARC must be PASS. However, this alone still doesn’t prove authenticity. But at least it tells you that the sending email was authenticated correctly, meaning whoever sent the email has technical control of the domain. Remember, a criminal can register paypa1-secure.com, and if they configure SPF, sign messages with DKIM, and publish a DMARC policy, they will successfully prove technical control.

At this layer, the primary sign of a fake email is misalignment among headers (From, Return-Path, SPF/DKIM results). Confirm that the visible From address matches the domain in the Return-Path, and confirm that the SPF IP passes for the actual brand’s domain. If all these check out, then there is a high chance that the email is not fake.

The “Received” chain shows where the email actually came from

Every mail server leaves a fingerprint attackers struggle to control

When an email server handles a message, it appends a Received line to the top of the header. An attacker can forge Received lines before the email leaves the attacker’s system. However, the inbound mail server also includes a line as part of the Received chain. This addition is what an attacker wouldn’t be able to forge. If there is a mismatch, then you should suspect the email.

You still see this information on the Source View page of the email. Below is an example of the first Received line where my provider accepts the email:

Received: from a74-66.smtp-out.amazonses.com (a74-66.smtp-out.amazonses.com. [54.240.74.66])
by mx.google.com

This example is the line that Google writes, not the one that the sender added. It simply tells me Google received the email from IP 54.240.74.66 at smtp-out.amazonses.com. Now, for me to see if this makes sense, I have to check it against other visible headers on the message.

For this specific message, the visible sender in the header is noreply@makeuseof.com. The Return-Path is an Amazon domain: amazonses.com. From the other information I checked earlier, I can see that SPF passed for that Amazon SES IP, 54.240.74.66, and DKIM passed for makeuseof.com. Everything is consistent. It is quite common for companies to send notifications using Amazon SES infrastructure, so the entire picture checks out.

When an email is legitimate, it follows a routing trail that includes:

1. Recognizable mail service
2. Authentication that matches the sending server
3. No random hosting provider in the chain (should be a recognizable email service platform)

Fake emails will typically leave a trail where your provider is receiving the message from an unrelated VPS, a strange domain, or an IP unrelated to the claimed sender.

While all these generally hold, note that more sophisticated attacks can also route through compromised legitimate accounts or well-known cloud services, so the absence of these red flags doesn’t guarantee 100% legitimacy.

Message-ID and envelope anomalies expose lazy or mass phishing

Infrastructure details rarely match the brand being impersonated

Afam Onyimadu / MUO

The Message-ID field is another important header that shouldn’t be ignored. It’s the first element you see on the Source View page. This is a globally unique ID that the message sender’s server generates. Typically, it comes in the form of a long string terminating with the @domain component. You must pay attention to this domain.

You should expect that a message coming from amazon.com should have a Message-ID that ends with Amazon’s domain. In place of Amazon, it is a red flag if you get something like @cheapmailer.hosting123.net; do not overlook it.

However, there are a few other Message-ID clues that show a message isn’t authentic:

1. Missing Message-ID entirely.
2. Identical Message-ID formats across unrelated phishing emails.
3. Outdated or strange X-Mailer headers.
4. An exposed X-Originating-IP that points to a residential or low-cost hosting range.

The reason why Message-ID is a powerful tool for spotting fraudulent email is that, while sophisticated attackers may clean it up, mass phishing operations often prioritize volume over polish.

Message-ID is one of the easiest headers for an attacker to forge, so a convincing Message-ID should never be taken as proof of authenticity; its value is almost entirely in catching lazy or automated phishing campaigns that don’t bother to set it correctly.

Unifying the three headings

The common denominator of the three headings I have described is that they are all connected with how a message is transported. They don’t account for how the message is presented. However, the transport element is vital because presentation may be cloned much more easily. Also, transport elements leave residue that serves as markers for spotting legitimacy.

Of course, if you’re getting too much spam, it’s wise to take practical steps to reduce its volume, because the more there is, the more likely something may fall through the cracks.

Related

I Got a Suspicious Link in a Text Message: Here’s How I Checked It Safely

Don’t open that text until you’re sure it’s safe.