Sorry it's taken me so long to reply, but I've been busy and could only do minimalistic replies, so I have waited until I had more time to delve in deeper... While the Gmail hack is no longer necessary, unfortunately Microsoft's outlook "hack" is still needed due to its difference... looking at the unmodified Received: headers in https://www.spamcop.net/sc?id=z6513483714z596b7c076a2121c3ce82e632cf6e31a3z [line] (Received origin/destination) [0001] Received: from PU1APC01HT007.eop-APC01.prod.protection.outlook.com (2603:10a6:800:92::20) [0002] by VI1PR06MB5360.eurprd06.prod.outlook.com [0003] Received: from PU1APC01FT052.eop-APC01.prod.protection.outlook.com (10.152.252.54) [0004] by PU1APC01HT007.eop-APC01.prod.protection.outlook.com (10.152.252.101) [0005] Received: from iainternalmeds.com (69.160.26.74) [0006] by PU1APC01FT052.mail.protection.outlook.com (10.152.253.137) (only the Received: lines are relevant here. Omitting the timestamps as well as the transfer method/protocol) Line [0002] is the host from which you picked the email up.
Lines [0001] and [0004] should have the same host name and number, but only the host name is the same, so SC cannot safely confirm that it is the same host and with right determines the following: "Internal handoff or trivial forgery".
Lines [0003] and [0006] also should have the same host name/address, but neither are equal, and therefore line [0005] is also a possible forgery. It looks complicated like this, but by keeping in mind, that the header lines are actually filled from the bottom up, let's "flip" the above Received: header lines: [line] (Received origin/destination) [0005] Received: from iainternalmeds.com (69.160.26.74) [0006] by PU1APC01FT052.mail.protection.outlook.com (10.152.253.137) [0003] Received: from PU1APC01FT052.eop-APC01.prod.protection.outlook.com (10.152.252.54) [0004] by PU1APC01HT007.eop-APC01.prod.protection.outlook.com (10.152.252.101) [0001] Received: from PU1APC01HT007.eop-APC01.prod.protection.outlook.com (2603:10a6:800:92::20) [0002] by VI1PR06MB5360.eurprd06.prod.outlook.com (only the Received: lines are relevant here. Omitting the timestamps as well as the transfer method/protocol) [0005] sent it
[0006] received it which then in turn sent it as [0003]  (PU1APC01FT052 is the same, but then the sub-domain name differs as well as the private IP address)
[0004] received it which then in turn sent it as [0001] (here all: host, sub-domain, and domain are exactly the same, but unfortunately the address is not)
[0002] received it in the end, waiting for you to pick it up. Therefore, unfortunately, Received: line [0001]/[0002] is the only trusted Received header: and the rest: [0003]/[0004], and [0005]/[0006] are possible forgeries in the eye of SC. By removing the top Received: line (here [0001]/[0002]) in outlook recipients, SC treats the following Received lines as Private/internal handoffs and correctly identifies the culprit in [0005]. This is not SC's fault, and SC cannot fix it. This fix has to come from M$ themselves, and, although SC did fix it in Gmail's sector, which, though Gmail's fault, and rightly also in Gmail's mail-server's code to be fixed, as 6to4 addresses should not propagate with private networks, is in the end a needed fix in SC's parser, and hopefully, whoever fixed it, made sure that only private networks are affected in the 2002:: 6to4 range, because it is possible (and allowed) to have valid IPv4 networks translated and propagated in IPv6 6to4 addresses. (please forgive the long-winding-ultra-long-complex-sentence. I hope it is understandable 🙃.) So in the end, the answer is as follows: For Gmail users: you do not have to remove/replace the 1st (topmost) Received: header. For Outlook users: you still have to remove/replace the 1st (topmost) Received: header. Sorry. This should answer both parts of the question. HTH