I've received some strange e-mail recently. The e-mail has different From and Reply-To fields. It has also To set to Undisclosed recipients but it's not crucial.

At first I thought it's fake, but then I've read this post which mentions that Received field can't be faked. It seems that received is proper in case of the e-mail I'm talking about:

Received: (wp-smtpd mx.tlen.pl 14490 invoked from network); 2 Oct 2018 07:19:36 +0200
Received: from mx.beniculturali.it ([])
          (envelope-sender <[email protected]>)
          by mx.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP
          for <[email protected]>; 2 Oct 2018 07:19:36 +0200
Received: from sea2.mail.beniculturali.it (localhost.localdomain [])
    by localhost (Email Security Appliance) with SMTP id 15EE31ECEEA_BB2FFE8B;
    Tue,  2 Oct 2018 05:19:36 +0000 (GMT)
Received: from MB2.mail.beniculturali.it (mb2.mail.beniculturali.it [])
    (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
    (Client CN "email.beniculturali.it", Issuer "Actalis Authentication CA G3" (not verified))
    by sea2.mail.beniculturali.it (Sophos Email Appliance) with ESMTPS id 1C9BD1E9E28_BB2FFE7F;
    Tue,  2 Oct 2018 05:19:35 +0000 (GMT)
Received: from MB2.mail.beniculturali.it ( by
 MB2.mail.beniculturali.it ( with Microsoft SMTP Server (TLS)
 id 15.0.1395.4; Tue, 2 Oct 2018 07:19:30 +0200
Received: from ca4.mail.beniculturali.it ( by
 MB2.mail.beniculturali.it ( with Microsoft SMTP Server (TLS)
 id 15.0.1395.4 via Frontend Transport; Tue, 2 Oct 2018 07:19:29 +0200
Received: from MDC.mail.beniculturali.it ([]) by
 ca4.mail.beniculturali.it ([]) with mapi; Tue, 2 Oct 2018
 07:19:29 +0200

Is it possible to spoof Received field somehow, perhaps using advanced techniques?

  • 1
    You could export a email from one inbox (e.g., *.eml format) and import it into another mailbox. Many clients won't complain. An email could be put into your inbox server side, it's just a file. I will let someone else go into more detail about why a server may accept or not accept fake headers when it receives it from a sender.
    – Eric G
    Oct 3, 2018 at 11:41
  • 45
    "The e-mail has different From and Reply-To fields." That's not strange. After all, there's a reason that they're separate fields! Oct 3, 2018 at 14:43
  • 5
    In addition to LRO's comment, a "To:" field of "Undisclosed recipients" is also not necessarily suspicious. It is what I would expect (for example) if the Italian Ministry of Culture were to send out a newsletter to all the people who had signed up for it. The recipients would be BCC (to protect their privacy), and there would be (effectively) no TO: field. Oct 4, 2018 at 7:59

1 Answer 1


It is possible to add arbitrary fields to the mail and this includes Received headers. But, any proper mail transport server will add a new Received header on top of the mail which means that, depending on the exact delivery infrastructure, the attacker can at most fully fake all but the topmost Received header. In your specific example, the top Received header seems to be some internal server and the next Received header is the one from your mail server at the perimeter which accepts mails from outside. All other Received headers might be faked.

And even the Received header added by the server at the perimeter might contain fake information. It is common that it includes the hostname claimed by the SMTP client within the EHLO or HELO command. Thus, in your specific example mx.beniculturali.it might be faked by the attacker while ([]) is added by the receiving mail server to show from which source IP the mail was received and cannot be faked.

  • 10
    TL:DR: you can trust the chain of Received: headers from servers you trust (if they haven't been hacked and this is just regular spam / phishing), until the ones after an IP address you don't trust. Oct 4, 2018 at 1:43
  • FYI, when there's a name inside the parentheses before [IP-address], it's the result of reverse DNS of the IP.
    – Barmar
    Oct 4, 2018 at 2:09
  • 1
    @Barmar: "...when there's a name inside the parentheses before [IP-address], it's the result of reverse DNS of the IP." - according to the syntax defined in RFC 5321 the TCP-info should contain "...Information derived by server from TCP connection not client EHLO..". Thus if there is a domain name given it might be the result of a PTR lookup as you say. But if the attacker controls the DNS for the specific IP he could make it return anything from the PTR lookup and thus one should not trust the domain value given there either. Oct 4, 2018 at 4:26
  • 3
    @SteffenUllrich: Maybe I shortened too much. If you trust the server who's IP address is listed in the last (top) Received: header (added by the final hop), you can trust that one previous Received: header was added by that trusted server. (It might have a bogus EHLO name, but you can trust that it was added by a trusted server and the IP address is real.) You can follow this chain backwards if you trust the IP address in the last trusted Received: header. (Again, this is true only if your threat model doesn't include hacked mail relays.) Oct 4, 2018 at 7:49
  • 2
    @PeterCordes: I fully agree with this extended description. Oct 4, 2018 at 8:28

You must log in to answer this question.

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