In server mode FortiMail does three jobs: it's the MX host that filters inbound mail, the mailbox server, and often the SMTP relay for applications and printers. Part 2 moved the mailboxes; this part moves the other two jobs. I'll choose the target design, map each FortiMail feature to its replacement, prepare Exchange Online, switch the MX record at cutover, sort out SPF, DKIM and DMARC, and move the relay clients.
How it works: two target designs#
- Design A: Exchange Online Protection (EOP) at the edge. The MX record points to Exchange Online, EOP filters inbound mail (with Defender for Office 365 if you license it), and FortiMail leaves the mail path.
- Design B: FortiMail in gateway mode in front of Exchange Online. The MX record points to a FortiMail in gateway mode, which filters the mail and relays it to Exchange Online. Exchange Online accepts mail for your domains only from that gateway.
| Design A: EOP | Design B: FortiMail gateway | |
|---|---|---|
| Inbound filtering | EOP, plus Defender for Office 365 where licensed | FortiMail first, EOP behind it |
| Systems in the mail path | One | Two |
| Extra Exchange Online setup | None at the edge | Locked Partner connector, Enhanced Filtering, SPF for the gateway if outbound goes through it |
| Typical reason | Simplicity and one place to manage policy | Existing FortiMail policies, licenses or skills you want to keep |
Design B can't be the current unit as it stands. Fortinet's documentation is explicit that changing the operation mode resets most of the configuration to factory defaults, so a server-mode unit that still holds mailboxes and archives can't simply be switched to gateway mode. Either run a separate gateway (another appliance, a VM or FortiMail Cloud), or rebuild the old unit only after its data is out and backed up.
Coexistence doesn't need split delivery in this project. Because the IMAP batches pre-sync everyone (part 2), the MX record stays on FortiMail until all mailboxes are synced and then moves once. If some mailboxes really must stay on FortiMail after the switch, set the accepted domain in Exchange Online to Internal relay, add an outbound connector that sends mail for unknown recipients in that domain to FortiMail, and set the domain back to Authoritative when the last mailbox has moved. Directory-Based Edge Blocking only rejects unknown recipients for authoritative domains; my guide to NDR 550 5.4.1 and Directory-Based Edge Blocking explains the trade-off.
Prerequisites#
- All mailboxes pre-synced (part 2) and the leavers' shared mailboxes created (part 3), so every recipient exists in Exchange Online.
- Access to your public DNS, with the MX TTL already lowered.
- The FortiMail feature inventory from part 1.
- Exchange administrator and Security administrator roles in Microsoft 365.
Step 1: Map FortiMail features to their new home#
| FortiMail feature | Design A: Microsoft 365 | Design B: FortiMail gateway |
|---|---|---|
| Antispam, antivirus, URL and attachment scanning | EOP, plus Safe Links and Safe Attachments in Defender for Office 365 | FortiMail profiles, rebuilt in gateway mode |
| Recipient verification | Directory-Based Edge Blocking (authoritative domain) | FortiMail recipient verification against your directory |
| Quarantine and digests | Microsoft 365 quarantine and quarantine notifications | FortiMail quarantine |
| Disclaimers and footers | Mail flow rules in Exchange Online | FortiMail, with the DKIM caveat below |
| Content filtering and DLP | Mail flow rules and Microsoft Purview DLP | FortiMail content and DLP profiles |
| Encryption | Microsoft Purview Message Encryption | FortiMail identity-based encryption |
| DKIM signing | Exchange Online DKIM | Exchange Online or FortiMail: one signer, after the last change to the message |
| Archiving | Microsoft Purview retention (part 5) | FortiMail archiving or Purview retention |
| SMTP relay for apps and devices | Exchange Online relay options (Step 4) | FortiMail relay |
Step 2: Prepare Exchange Online before the switch#
- Protection. Apply the Standard or Strict preset security policy in the Microsoft Defender portal, so EOP (and Defender for Office 365, if licensed) protects every mailbox from the first minute. My runbook for moving from a third-party gateway to EOP covers pilots, user reporting and tuning in depth.
- The exact MX value. Copy it from the Microsoft 365 admin center under Settings › Domains (select the domain, then its DNS records) instead of typing it from a pattern. Microsoft notes that the value can vary from domain to domain.
- DKIM. In the Defender portal, under Email & collaboration › Policies & rules › Threat policies › Email authentication settings, create the DKIM keys for the domain and publish the two CNAME records it shows. Turn signing on at cutover, once both records resolve.
- SPF. Prepare the new record. In Design A outbound mail leaves from Exchange Online:
v=spf1 include:spf.protection.outlook.com -all. Keep FortiMail's public IP address in the record for as long as it still sends anything. - DMARC. If the domain has no DMARC record yet, publish one with
p=noneand a reporting address before the switch, and tighten it once the reports are clean. - MTA-STS and DANE. An MTA-STS policy lists the MX hosts that senders may deliver to. If your domain publishes one, add the Exchange Online host or switch the policy to testing mode before the MX change, or senders that enforce the policy will refuse to deliver. If you use DANE today, plan Exchange Online's inbound SMTP DANE with DNSSEC, which uses its own DNSSEC-capable MX host name.
- Autodiscover. Have the CNAME record to
autodiscover.outlook.comready.
The DNS records and portal steps are covered in SPF, DKIM and DMARC for your Microsoft 365 custom domain.
Step 3A: Switch MX to Exchange Online (Design A)#
- Confirm that every IMAP batch is Synced and that the DKIM CNAME records resolve.
- Replace FortiMail's MX record with the Exchange Online value, as the only MX record. Don't keep FortiMail as a lower-priority backup MX: mail that lands there after the cutover only reaches users while the batches are still syncing.
- Leave FortiMail running and accepting mail for the old record's TTL and beyond. The incremental syncs copy whatever still arrives there (part 2).
- Publish the new SPF record, turn on DKIM signing and switch Autodiscover.
# The MX record as the internet sees it
Resolve-DnsName -Name contoso.com -Type MX -Server 8.8.8.8
# Inbound internet mail now arrives in Exchange Online (FromIP shows the real senders, not FortiMail)
Get-MessageTraceV2 -RecipientAddress amal.hassan@contoso.com -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date) |
Format-Table Received, SenderAddress, FromIP, Status
# DKIM: turn it on once both CNAMEs resolve; good is Enabled True and Status Valid
Set-DkimSigningConfig -Identity contoso.com -Enabled $true
Get-DkimSigningConfig -Identity contoso.com | Format-List Enabled, StatusStep 3B: Put a FortiMail gateway in front of Exchange Online (Design B)#
On the gateway-mode FortiMail, add your domain as a protected domain whose SMTP server is the Exchange Online MX host for that domain; Fortinet's Microsoft 365 recipe sets this under Domain & User › Domain › Domain. Configure recipient verification against your directory and, if outbound mail will also pass through FortiMail, allow Exchange Online to relay through it.
On the Exchange Online side, Microsoft's guidance for an MX record that points to non-Microsoft filtering has three parts: lock the tenant so it accepts mail for your domains only from the gateway, turn on Enhanced Filtering for Connectors (or deliberately bypass filtering), and add the gateway to SPF only if outbound mail goes through it.
# 1. Accept mail for your domains only from FortiMail: by certificate (preferred) or by its public IPs
New-InboundConnector -Name "From FortiMail gateway" -ConnectorType Partner -SenderDomains * `
-RequireTls $true -TlsSenderCertificateName *.contoso.com -RestrictDomainsToCertificate $true
# New-InboundConnector -Name "From FortiMail gateway" -ConnectorType Partner -SenderDomains * `
# -SenderIpAddresses 203.0.113.10,203.0.113.11 -RestrictDomainsToIPAddresses $true
# 2. Enhanced Filtering: let EOP see the real sending IP behind the gateway (one hop)
Set-InboundConnector -Identity "From FortiMail gateway" -EFSkipLastIP $true
# 3. Optional: send outbound internet mail through FortiMail as well
New-OutboundConnector -Name "To FortiMail gateway" -ConnectorType Partner -RecipientDomains * `
-SmartHosts mx1.contoso.com -UseMXRecord $false -TlsSettings DomainValidation -TlsDomain mx1.contoso.com- Certificate name. Use the name on the certificate FortiMail presents when it connects to Exchange Online;
*.contoso.comis an example. - SPF. Add FortiMail's public IP addresses only if outbound mail goes through it, for example
v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:spf.protection.outlook.com -all. - DKIM. A footer or disclaimer added after Exchange Online signs a message breaks the signature. Add disclaimers in Exchange Online, or let FortiMail do the signing (Fortinet documents DKIM signing on FortiMail), but keep one signer at the last hop that changes the message.
- MX. The MX record points at the gateway. With a new gateway, that's a DNS change too.
How to prove the lock-down and Enhanced Filtering in message headers is in my guide to Enhanced Filtering for Connectors with a third-party gateway.
Step 4: Move the relay clients#
Find every system that relays through FortiMail: its access control rules show which internal addresses may relay, and its logs show which ones actually do. Then give each one a new path before cutover:
- Design B: devices can keep relaying through the gateway FortiMail.
- Design A: SMTP AUTH client submission with a licensed mailbox, direct send for devices that only email your own users, or a connector-based relay from a static public IP address or a certificate. My guide to SMTP AUTH, relay connectors and error 5.7.57 compares them. If you block unauthenticated direct send in your tenant, test every device before the switch.
Verify#
- The MX record resolves to the new host from several public resolvers.
- Message trace shows inbound internet mail arriving in Exchange Online: from the real senders in Design A, from FortiMail's addresses in Design B.
- A message sent to an external mailbox shows SPF, DKIM and DMARC passing in its
Authentication-Resultsheader. - DMARC aggregate reports for the following week show your mail passing from Exchange Online (and from FortiMail, in Design B).
- Every relay client on the list sends successfully.
- In Design A, FortiMail's logs show inbound traffic dying away once the old TTL has passed.
Rollback and decommissioning#
While the IMAP batches still run, rollback is a DNS change: point the MX record back at FortiMail and the incremental syncs carry on copying. After the batches are removed, mail sent to FortiMail lands where nobody reads it any more, so take any rollback decision inside that window.
Retire FortiMail only when it has received no mail for a couple of weeks, no relay client uses it, the archive decision in part 5 is made and a final backup exists. Fortinet notes that archived messages can't be deleted one by one, and that the only way to delete all email archives is to format the mail data disk, so plan the unit's disposal like any other system that holds personal data.
References#
- Manage mail flow using a third-party cloud service with Exchange Online (Microsoft Learn)
- Enhanced Filtering for Connectors in Exchange Online (Microsoft Learn)
- Configuring FortiMail to accept Office 365 (FortiMail Cookbook, Fortinet)
- Choosing the operation mode (FortiMail 7.6.5 Administration Guide, Fortinet)
