Premise: I know pretty well how SMTP works, and how to read an e-mail header. I know what all the main fieds mean, but I couldn't know what to look for if I want to know if the mail is kind of malicious (e.g. spoofed).

For instance, given the following e-mail header:

Delivered-To: damore@dis.uniroma1.it
Received: by with SMTP id u132csp362868ykc;
 Wed, 18 Jun 2014 22:23:12 -0700 (PDT)
X-Received: by with SMTP id w20mr2259156qax.50.1403155391885;
 Wed, 18 Jun 2014 22:23:11 -0700 (PDT)
Return-Path: <nazaret.galilea@archaeologist.com>
Received: from mout.gmx.com (mout.gmx.com. [])
 by mx.google.com with ESMTPS id s2si5075397qak.63.2014.
 for <damore@dis.uniroma1.it>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 18 Jun 2014 22:23:11 -0700 (PDT)
Received-SPF: none (google.com: nazaret.galilea@archaeologist.com does not designate permitted sender
 hosts) client-ip=;
Authentication-Results: mx.google.com;
 spf=neutral (google.com: nazaret.galilea@archaeologist.com does not designate permitted sender
 hosts) smtp.mail=nazaret.galilea@archaeologist.com
Received: from [] by 3capp-mailcom-lxa14.server.lan (via HTTP);
 Thu, 19 Jun 2014 07:21:59 +0200
MIME-Version: 1.0
Message-ID: <trinity-10a5ee53-e71d-4b2c-a69f-f9624b154874-1403155319290@3capp-mailcom-lxa14>
From: "Luis Gutierrez" <nazaret.galilea@archaeologist.com>
To: Marina.Scheidler@bibliothek.uni-augsburg.de
Subject: Prayer
Content-Type: multipart/mixed;
Date: Thu, 19 Jun 2014 07:21:59 +0200
Importance: normal
Sensitivity: Normal
X-Priority: 3
X-Provags-ID: V03:K0:QOIMVsTNJekpMbcCkjuHDVKatYQZ9wC72dFJEb42vaY

Content-Type: text/html; charset=UTF-8

(it is taken from an university exercise, so I know that there must be something)

The only interesting thing that I found is that contents of fields Delivered-To: and To: are different (how is it possible?).

What else should I look for?

2 Answers 2


Frankly, this mail header looks strange for me in several places and I'm not sure if this is because it was actually delivered this way, if it was changed afterwards or if the mails was just constructed:

  • The Received-SPF and Authentication-Results fields claim to be set from google.com but are located after the Received field for google.com. According to RFC 7208 9.1 and RFC 7601 4.1 these fields must be placed on top of the mail before the Received header of the specific MTA.
  • The Received header from google.com claims that the mail was received from mout.gmx.com but the mails does not include a matching Received header for GMX.
  • And finally the problem what this exercise was probably mainly about: the recipient according to the Received fields was damore@dis.uniroma1.it but the recipient according to To: is Marina.Scheidler@bibliothek.uni-augsburg.de. While this could be possible if there is a forwarding installed from Marina.Scheidler@bibliothek.uni-augsburg.de to damore@dis.uniroma1.it this should show up in the Received headers.

But again, this mail looks strange for me in many places and I rather suspect that it was somehow constructed to demonstrate something, only it was constructed incomplete and wrong.

  • Thank you so much, I think I'm going to accept this answer, in the absence of a better one. Anyway, my question was intended to be more generic: I would appriciate if you expanded the answer adding more things to be careful with (even not related to the specific example).
    – user402843
    Mar 31, 2019 at 10:34
  • Furthermore, I noticed that the first Received: is -> 3capp-mailcom-lxa14.server.lan, while the second is mout.gmx.com -> mx.google.com. So 1) Aren't we missing a hop? 2) Is the actual sender's device IP address or something else?
    – user402843
    Mar 31, 2019 at 10:44
  • 1
    @user402843: " Aren't we missing a hop?" - this is exactly my second point. Mar 31, 2019 at 11:47
  • 1
    "I would appriciate if you expanded the answer adding more things to be careful with" - There are some many things, like DKIM, DMARC, SPF, adherence to standards, order of headers, mismatch between headers ... - this would be too broad. Moreover many valid mails are actually more or less broken regarding the standards so many assumptions that something is wrong has to be taken with caution. Mar 31, 2019 at 11:49
  • Sure, I skipped it. Well, thank you so much!
    – user402843
    Mar 31, 2019 at 13:38

I found something of your interest :

  • The sending IP address and the SPF validation will give you a very good sense of whether an email truly comes from the person purported to be sending it.
  • The line Received: from mout.gmx.com (mout.gmx.com. []) gives you the IP address from where the email is coming from.
    Now, there are various websites that give threat intelligence reports such as VirusTotal. If you search about this IP address you will get an interesting report See this!
    The above address is reported by 2 firms also it's community score is quite shocking.
  • 1
    Given that this mail is from 2014 I would not rely on any reports which are done 5 years later. Also, SPF result is none in this case, i.e. the claimed sender domain did not publish any SPF policy so nothing could be checked. This means one cannot rely on SPF either. Mar 30, 2019 at 20:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .