At the network connection level, directionality is determined by the destination IP address.

Connection level directionality does not consider a connection’s source IP address, nor whether or not the recipient email address’s (RCPT TO:) mail domain is a protected domain.

Directionality at the connection level may be different than directionality at the level of email messages contained by the connection. It is possible that an incoming connection could contain an outgoing email message, and vice versa.

For example, in Figure 41, connections from the internal mail relays to the internal mail servers are outgoing connections, but they contain incoming email messages. Conversely, connections from remote MUAs to the internal mail relays are incoming connections, but may contain outgoing email messages if the recipients’ email addresses (RCPT TO:) are external.

When the FortiMail unit is operating in transparent mode, directionality correlates with which proxy will be used, if any.

For example, in Figure 41, the protected domain is example.com. Mailboxes for example.com are stored on servers located at the company’s headquarters, separate from the mail relays, which are located at a branch office. All email is routed through the mail relays, and so the FortiMail unit is deployed in front of the mail relays at the branch office.

On the FortiMail unit, you have configured the protected domain’s “SMTP server” to be 192.168.0.1, a mail relay, because all email must be routed through that mail relay. You have also enabled “Use client-specified SMTP server to send email”, so, for outgoing connections, the outgoing proxy will be used instead of the built-in MTA. However, you have not enabled “Use this domain’s SMTP server to deliver the mail”, so, for incoming connections, the built-in MTA will be used, rather than the incoming proxy.