When a sending SMTP server connects to the SMG Interface (proxy). During the SMTP conversation we (SMG Interface) attempts to connect to the receiving SMTP server on their behalf. If we cannot connect to the receiving SMTP server until we have got the RCP

Here is an example outline of what happens:  

1) Sending SMTP server connects to SMG (SMTP Interface)

    SMG now has the sending server's IP address. So it can perform IP reputation check and RBL (if it is configured to do so)

    This also means information that can be added to Message Tracker (if it is configured to do so)

2) Sending SMTP server sends MAIL FROM command

    SMG now has the sender's email address. So it can perform SPF check (if it is configured to do so)


    We have more information that can be added to Message Tracker

3) Sending SMTP server sends RCPT TO command(s)


    SMG now connects or attempts to connect to the receiving server and SMG begins the SMTP conversation with the receiving server on the sendering servers behalf.

    We have more information that can be added to Message Tracker, including if SMG cannot connect to the receiving server.

4) Sending SMTP server sends the DATA command


    SMG now has the message (mime) and it can be sent to the message scanner for full scanning


    We have more information that can be added to Message Tracker, including if the message was accepted by the receiving server.

Throughout this process if the SMTP conversation is terminated between the sending server and SMG or between SMG and the receiving server (which also means if a firewall in the middle blocks the conversation), If message tracking is configure then I would expect to see some clues in the message tracking information.

It's likely that a block due to a firewall will appear as a timeout or lost connection.

Check the connection or the firewall settings

It's likely that a block due to a firewall will appear as a timeout or lost connection.