Split Routing for Two Domains Behind One Gateway
Northgate University has 12,000 mailboxes across three systems. Faculty use Exchange 2019 at 10.50.1.20, students use Microsoft 365 at northgate-edu.mail.protection.outlook.com, and alumni use a legacy Dovecot server at 10.50.1.35. A FortiMail 7.2 gateway is the only MX for northgate.edu and alumni.northgate.edu. Inbound mail for northgate.edu currently goes to Exchange for everyone; student mail is then forwarded by Exchange, which creates a loop when Exchange sends it back through FortiMail. The FortiMail administrator created two domains and set each domain's mail server to the corresponding server, but delivery did not change. Outbound mail from Exchange is relayed by FortiMail directly to the internet; the security team now wants all outbound mail to use a smart host at smtp.esp.example, port 587, with STARTTLS and authentication. A test message to an alumnus bounces with 'User unknown' at Exchange, although the mailbox exists on Dovecot. The university needs deterministic routing and no mail loops.
1. Why did setting the domain mail server not split student and faculty delivery, and what FortiMail routing construct would you use?
Read the worked answer
A domain-level mail server is a single destination for the whole domain. Both students and faculty are in northgate.edu, so FortiMail still sends every northgate.edu recipient to Exchange. Domain settings cannot distinguish student addresses from faculty addresses. Use recipient-based routing entries, ordered from most specific to least specific: route student recipient patterns to the Microsoft 365 tenant, route faculty patterns to Exchange, and keep a deliberate catch-all only if operations can explain where unmatched recipients should go. Routing is evaluated before the domain mail server for matching recipients, so the specific student route wins. Avoid a catch-all that points back to Exchange when Exchange forwards student mail to FortiMail; that combination produces the observed loop. Test each route with message tracking and confirm the next hop in the delivery log.
2. How would you stop the Exchange-to-FortiMail loop for student recipients?
Read the worked answer
The loop exists because two systems each believe the other is responsible for student mail. FortiMail routes northgate.edu to Exchange, and Exchange forwards student addresses back to FortiMail. Fix the ownership at both ends. First, create a FortiMail recipient route that sends student addresses directly to Microsoft 365 so inbound student mail never reaches Exchange. Second, remove or rewrite the Exchange forwarding rule that sends student mail to FortiMail; otherwise outbound or internally originated student mail can still loop. Confirm that Microsoft 365 accepts the domain and that the tenant is authoritative for those recipients. Use message tracking to verify a student message traverses FortiMail once and is delivered to the tenant, not requeued. Keep the faculty route pointed at Exchange and monitor for misaddressed recipients that match the wrong pattern.
3. What must be configured and verified to send all outbound mail through the authenticated smart host, and what symptoms indicate TLS or authentication failure?
Read the worked answer
Configure a relay host for smtp.esp.example on port 587, enable STARTTLS, select a TLS profile that validates the provider certificate, and attach an authentication profile containing the provider username and password. Apply the relay host through the outgoing policy or domain relay setting so all outbound mail uses it, while ensuring internal domains are not accidentally routed through the smart host. Verify DNS resolution, firewall access to port 587, time synchronization, and that the provider certificate chain is trusted by FortiMail. If authentication fails, messages typically remain queued with an SMTP 535 response and repeated retries. If TLS fails, expect TLS handshake errors or a refusal to send in the queue, depending on whether the TLS profile is opportunistic or required. Check the mail queue, SMTP session logs, and TLS logs, then release or retry after correction.