Recognize Emails with Spoofed Sender

· 385 words · 2 minute read

Update 2021: See here for another great collection of different email spoofs by Kaspersky.

Recently I noticed a rise in spam emails with spoofed From-headers. This is unusual because almost all mail servers will require users to log in before sending emails. Below a typical example, which was already flagged as spam.

As you can see, the sender- and recipient addresses are the same in Apple Mail. The content implies that the user’s mailbox was hacked.

When checking the server logs, I quickly noticed that the email was actually sent from a different sender-address than the one shown here. to be precise. But why won’t this address show up as From address?

Turns out that it’s possible to pass any From header in the email body, even though the SMTP MAIL FROM said something different. While this is surely suspicious, it’s common practice for email services, like Amazon SES or Sendgrid.

If you wish to know the actual sender, you need to look at the Return-Path field also known as envelope sender or bounce address. It will have the actual sender address that was used for authentication. In my opinion it should also be displayed in the email client, if different from the From header. Below an example header with the relevant parts in bold.

Received: from ( [])
	by (Postfix) with ESMTPS id DADE6180385A
	for <manu@***>; Sat, 23 Mar 2019 13:37:34 +0800 (+08)
Received: from [] (unknown [])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by (Postfix) with ESMTPSA id 33DBFF30D6DB
	for manu@***; Sat, 23 Mar 2019 14:37:13 +0900 (JST)
To: manu@***
X-aid: 0776676839
List-ID: 10f2hkdwzncc5z0xhusfi99g.iud3kqvly5b6il5czck95ezocwxr8kf5cdj
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824
Date: Sat, 23 Mar 2019 06:37:16 +0100
Feedback-ID: 58286146:06631151.375932:us93:ve
Subject: ***** SPAM 46.3 ***** manu
Message-ID: <znh6jot6jqd070lqm9wcfmkr7szh@a5rr2un6hmrqfw7h94z94redzlq9lhvj2gjuprdzi9rf3w7wmb4pv9o0peu8>
From: manu@***

Now, what can you do to prevent this kind of spamming? Spamassassin already has a rule called HEADER_FROM_DIFFERENT_DOMAINS that will trigger in those cases. Sadly, you can’t give a high score to this rule, since legitimate services are sending for different domains all the time.

So the only option left is to educate your users about the Return-Path header and tell them to look at it when it’s an important email.