Are you able to see the headers of these messages on the Salesforce side?
As in, … do they all have the exact same “From:”, “To”, “Message-ID” and “Date” headers?
Are the headers a (100%(?)) match all the way, or are there any kind of discrepancies?
“Upstream error” in this case, is simply Cloudflare’s way of telling that you should look at the at the final destination for further troubleshooting.
SMTP codes such as e.g. “421”, and the SMTP enhanced status code “4.3.0” have some meanings in the SMTP world, which can be found over here:
→ Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry
The “Upstream error” part is however “free-form”, and can be anything from an operator’s choice (e.g. choosen by Cloudflare), to the choice of the vendor of the mail server software (e.g. Exim, Postfix, Sendmail, et al), that is being used.
It is referring to a connectivity issue, which in this case is happening with the communication between Cloudflare and Salesforce.
But stuff like that was indeed what I would be looking for in the “Activity Log”.
One previous example I made, where I on the final destination was rejecting with a SMTP code “550”, and the extended code “5.7.1”, would be showing something like this:
I don’t know how long GraphQL would expose the data of the “Activity Log”, however, my understanding is that you can fetch (at least, some of all this) data from the “Activity Log”, through GraphQL.
Transient issues, regardless of when, how, and where they happen, can indeed cause a lot of strange results, including ones that (almost) no one would ever have thought about.
In your case, it does appear like the connectivity issue is happening just after Salesforce has received the message (“end of data” signal from Cloudflare), and before Cloudflare receiving the acknowledgement of of that signal, as I indicated above.