This is unfortunate. It would be desirable to delay replicating the message until there is a need to do so.
However, one easy fix is to eliminate the unnecessary disconnect-reconnect that occurs between each recipient of a multiple-recipient message. The time lost seems to be only about a quarter of a second, but it also breaks FIFO sequencing. The downstream server sees the secondary recipient(s) as subsequent to every parallel stream that may have been started while the first recipient was being transmitted.
The net result of both problems is that the secondary recipients are excessively delayed by spam filtering.
Here is a sanitized extract of the disconnect and reconnect log entries:
RSP: 250 HELP
CMD: MAIL FROM:<sendinguser@sendingdomain> SIZE=4942
RSP: 250 Sender <sendinguser@sendingdomain> OK
CMD: DATA
RSP: 354 Start mail input; end with <CRLF>.<CRLF>
RSP: 250 Ok: queued as A4693AC0065
********** start of wasted effort **********
CMD: QUIT
RSP: 221 server2.example.com Goodbye server.example.com, closing connection
Initiating connection to 192.168.1.203
Connecting to 192.168.1.203:25 (Id: 3)
Connection to 192.168.1.203:25 from 192.168.1.119:55413 succeeded (Id: 3)
RSP: 220 server2.example.com ESMTP (493ac9a54b921d242e0b077fa5020003)
CMD: EHLO server.example.com
RSP: 250-server2.example.com Hello server.example.com [192.168.1.119], pleased to meet you
RSP: 250-SIZE 51300000
RSP: 250-STARTTLS
RSP: 250-PIPELINING
RSP: 250-8BITMIME
RSP: 250 HELP
CMD: STARTTLS
RSP: 220 Ready to start TLS
CMD: EHLO server.example.com
RSP: 250-server2.example.com Hello server.example.com [192.168.1.119], pleased to meet you
RSP: 250-SIZE 51300000
RSP: 250-PIPELINING
RSP: 250-8BITMIME
RSP: 250 HELP
********** end of wasted effort **********
CMD: MAIL FROM:<sendinguser@sendingdomain> SIZE=4942
RSP: 250 Sender <sendinguser@sendingdomain> OK