Why do RECEIVED email headers seem to be out of order chronologically?

Question

When reviewing the headers, it appears that the 2nd server to receive the message didn't relay it until AFTER the reported delivery date in the final header.

At c9mailgw11.amadis.com, the reported time was 22:47:49 -0800 (PST). However, the final server, BY2PR0401MB0966.namprd04.prod.outlook.com, reports the time as 06:46:08 +0000.

Is the discrepancy due to something simple, like a bad clock on the amadis relay?

I've written a script that detects email delays, and when I hit an oddity like that I get a negative value from that hop to the next and I want to understand why they are ordered this way to see if I have way to lookahead.

Can anyone offer insight?

**Received: from BY2PR0401MB0966.namprd04.prod.outlook.com (10.160.64.15) by
 CY1PR0401MB0971.namprd04.prod.outlook.com (10.160.160.17) with Microsoft SMTP
 Server (TLS) id 15.1.403.16 via Mailbox Transport; Wed, 17 Feb 2016 06:46:08**
 +0000
Received: from BN3PR0401CA0023.namprd04.prod.outlook.com (10.162.159.161) by
 BY2PR0401MB0966.namprd04.prod.outlook.com (10.160.64.15) with Microsoft SMTP
 Server (TLS) id 15.1.409.15; Wed, 17 Feb 2016 06:46:07 +0000
Received: from BN3NAM01FT022.eop-nam01.prod.protection.outlook.com
 (2a01:111:f400:7e41::207) by BN3PR0401CA0023.outlook.office365.com
 (2a01:111:e400:51d1::33) with Microsoft SMTP Server (TLS) id 15.1.409.15 via
 Frontend Transport; Wed, 17 Feb 2016 06:46:07 +0000
Received: from BAY004-MC1F22.hotmail.com (10.152.66.51) by
 BN3NAM01FT022.mail.protection.outlook.com (10.152.67.153) with Microsoft SMTP
 Server (TLS) id 15.1.409.7 via Frontend Transport; Wed, 17 Feb 2016 06:46:06
 +0000
Received: from mail2world.com ([209.67.128.125]) by BAY004-MC1F22.hotmail.com with Microsoft SMTPSVC(7.5.7601.23143);
     Tue, 16 Feb 2016 22:46:06 -0800
Received: from mail pickup service by mail2world.com with Microsoft SMTPSVC;
     Tue, 16 Feb 2016 22:46:04 -0800
ResentFrom: [email protected]
Return-Path: [email protected]
Received: from 216.163.188.203 unverified ([216.163.188.203]) by mwpop05oc.mail2world.com with Mail2World SMTP Server; 
    Tue, 16 Feb 2016 22:46:01 -0800
**Received: from sender153-mail.zoho.com (unknown [74.201.84.153])
    by c9mailgw11.amadis.com (Postfix) with ESMTP id A432C5B996A81
    for <[email protected]>; Tue, 16 Feb 2016 22:47:49 -0800 (PST)**
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; 
  s=zapps768; d=zoho.com; 
  h=content-type:mime-version:subject:to:from:date; 
  b=b6BP/HJmeP+ORBz043y8K0tUFE3u3c8tUZvDSHjfuH0zD84gax1wUlRdYGps/SBd7SnFHYT1Plps
    wRQOJoRp6hEMPerW6MSOL9psGWfNel4lnZwdtr7ujnuh54CTTEwV  
Received: from [192.168.10.1] (xxx.xxx.net [xx.xx.xx.xx]) by mx.zohomail.com
    with SMTPS id 1455691501828999.0688176107503; Tue, 16 Feb 2016 22:45:01 -0800 (PST)

Answer 1

The answer to this question is documented in rfc5321, section 4.4 as follows:

When an SMTP server receives a message for delivery or further
processing, it MUST insert trace ("time stamp" or "Received")
information at the beginning of the message content, as discussed in
Section 4.1.1.4.

This line MUST be structured as follows:

o The FROM clause, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.

o The ID clause MAY contain an "@" as suggested in RFC 822, but this is not required.

o If the FOR clause appears, it MUST contain exactly one entry, even when multiple RCPT commands have been given. Multiple s raise some security issues and have been deprecated, see Section 7.2.

An Internet mail program MUST NOT change or delete a Received: line that was previously added to the message header section. SMTP
servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other
location.

Answer 2

Another possible cause is that Outlook modifies the headers. It does this at least when it moves messages from one IMAP folder to another.

An Outlook bug report was filed for Outlook 2013, but some of this behaviour is still occurring in the latest Outlook desktop version.

It appears that the latest version of Outlook (as of August 2022) still does the following when moving a message from one IMAP folder to another:

• it groups all the Received headers together, but in a different order from the original (even though it's not strictly speaking SMTP-related, it's not quite in the spirit of RFC 5321, as quoted by @jstedfast);
• it groups all the Authentication-Results headers together, also in a different order (which also makes it complete nonsense if they're not close the Received header they were related to);
• it changes the Message-ID header, even if the message hasn't really changed (very much against the spirit of RFC 5322;
• it removes the Return-Path and Delivered-To headers.

It's not clear whether this fully matches your use-case, but since your example involves an outlook.com domain at some point in the Received headers, it's possible that other tools in the Outlook family show a similar attitude towards headers than the IMAP-specific use-case I've just mentioned.