Is it possible to fake 'received' field in the e-mail?

Question

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 ([194.242.241.200])
          (envelope-sender <pm-pie.aglie@beniculturali.it>)
          by mx.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP
          for <myemail@10g.pl>; 2 Oct 2018 07:19:36 +0200
Received: from sea2.mail.beniculturali.it (localhost.localdomain [127.0.0.1])
    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 [192.168.123.122])
    (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 (192.168.123.122) by
 MB2.mail.beniculturali.it (192.168.123.122) with Microsoft SMTP Server (TLS)
 id 15.0.1395.4; Tue, 2 Oct 2018 07:19:30 +0200
Received: from ca4.mail.beniculturali.it (192.168.123.144) by
 MB2.mail.beniculturali.it (192.168.123.122) 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 ([192.168.123.171]) by
 ca4.mail.beniculturali.it ([192.168.123.144]) with mapi; Tue, 2 Oct 2018
 07:19:29 +0200

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

Answer 1

Whenever an email server receives a message, it puts a new Received header on the top, and passes all others on unchanged. As such, the first Received header is always trustworthy (it was added by the server that you received the mail from). The second one is trustworthy if you trust the host/IP that it came from according to the first one. The third one is trustworthy if you trust the second one, and you trust the IP that the third one came from according to the second one. This pattern repeats for all of them, each chaining on the trust of all of the higher ones. Note the word "and"; a single break in the chain means that no lower Received headers can be trusted, no matter what host/IP they indicate.