Ip exchange on spamlist

The delay needs to be tied to an actual delivery attempt; a blocklist lookup alone does not establish which system held the messages or which rule caused it.

Choose one delayed message and collect its Message-ID, sender, recipient and UTC sending/receiving times. On your receiving gateway, inspect SMTP logs for that attempt and retain the complete response sent to the remote server. Ask the sending Exchange Online administrator to run a message trace and inspect event details and timestamps for that message.

If your gateway's response explicitly cites a reputation list, review that rule with the gateway or list provider. If the trace instead shows connectivity, TLS or service delay, investigate that event rather than changing spam rules. Microsoft notes that connection-filter IP blocks are not traceable as ordinary message events. Escalate with matching logs and trace; broadly allowing Microsoft address ranges would bypass useful filtering.