FCP FortiMail: Email Routing and Delivery

The Email Routing and Delivery domain tests policy evaluation and mail flow: how FortiMail decides to accept, relay, deliver, quarantine, or reject a message. You need to know the difference between access control rules and recipient policies, how relay hosts and destinations are used, and how to prevent loops.

Policy order and matching

• Access control rules are evaluated early and match connection attributes such as source IP, sender, and recipient. They can allow, reject, or bypass processing.
• Recipient policies match recipient addresses or domains and attach antispam, antivirus, content, and DLP profiles. They also decide the delivery action.
• Rules are first-match. Put specific exceptions above broad catch-alls; a general rule above a partner exception will hide the exception.
• A policy that lacks a relay or delivery action can accept mail and then queue or reject it, which looks like a routing failure.

Inbound and outbound paths

• Inbound: MX points to FortiMail; FortiMail validates the recipient, scans, then relays to the protected mail server using the configured destination or relay host.
• Outbound: internal clients submit to FortiMail, either authenticated or allowed by IP; FortiMail relays to the internet, directly by MX lookup or through a smart host.
• Recipient verification through LDAP or AD rejects unknown users at SMTP time, reducing backscatter.
• Use a relay host when policy or ISP requirements demand a smart host. Do not point FortiMail's relay host back to itself; that creates a loop.

Worked example

Exchange at 10.0.0.10 sends outbound mail through FortiMail. Create an access control rule allowing 10.0.0.10 to relay, then a recipient policy for the internal domain with action relay to the internet. If the ISP requires a smart host, set the relay host to the ISP. Reason: the access rule authorizes the connection, while the recipient policy chooses scanning profiles and the outbound route. If you only create the access rule, mail may be accepted but not routed as intended.

Traps

• Broad catch-all rules above specific partner or bypass rules.
• Missing relay permission, producing relay denied errors.
• A loop between FortiMail and the internal server.
• Assuming recipient verification works without a working directory binding.
• Forgetting that outbound and inbound policies are separate.