FortiMail on Microsoft 365 without changing MX records — the out-of-band Graph API deployment playbook

If you're running Microsoft 365 for corporate email and evaluating an additional layer of security on top of Exchange Online Protection or Defender for O365, there's a deployment shape that most Indian buyers still don't realise Fortinet supports: FortiMail Cloud added on top of your existing tenant without touching a single MX record. No mail-flow reconfiguration, no cutover risk, no impact on business email if the FortiMail tenant has an issue. This is the "out-of-band" or "API-based" deployment of FortiMail Cloud SaaS — powered by the Microsoft Graph API — and it changes both the deployment risk profile and the "should we add this to our O365 stack?" conversation. This post is the practical guide: what the deployment actually looks like, the exact Graph API permissions FortiMail needs, where this shape is the right answer, and — importantly — where it isn't.

The frameWhy "add a security layer without changing MX records" is even a conversation

For most of the last fifteen years, adding a third-party email security product on top of Microsoft 365 (or Exchange on-prem before it) meant one thing: you changed your MX records to point mail at the security vendor first, they scanned it, and they delivered clean mail to your Exchange/O365 tenant. This is the "gateway" or "in-band" deployment model. It's how Mimecast, Proofpoint, Symantec Messaging Gateway, Cisco IronPort, and yes, the traditional FortiMail Cloud Hosted variant all worked. It's still the standard for a lot of enterprises.

The gateway model has real advantages — malicious mail never reaches the tenant, everything is inspected before delivery, and the security vendor sees the full session so anti-spoofing has full context. But it also has non-trivial deployment friction: you're changing DNS at your MX level, which means a botched cutover can silently bounce inbound mail for hours. You're introducing a hop that can add latency or, worse, fail closed if the vendor has an outage. And you're committing to route all your inbound mail through a third party — which raises real data-residency questions under DPDP if the vendor's scrubbing centres aren't in India.

Microsoft Graph API changed the math. Once Microsoft exposed programmatic access to mail via a well-documented API (Graph replaced the older Exchange Web Services API for most modern integrations), it became possible for third-party security products to sit alongside the tenant rather than in front of it. Mail arrives at O365 as normal. The third-party tool polls Graph (or subscribes to notifications), scans messages after delivery, and — critically — can move, quarantine, or delete messages if they turn out to be malicious. This is what Fortinet calls the FortiMail Cloud SaaS variant, and it's the deployment shape most Indian mid-market buyers should at least evaluate before they commit to the MX-cutover playbook.

What "out-of-band via API" actually meansArchitecture, side by side

Why buyers pick this shapeSix reasons the out-of-band model is winning mid-market

What you get on the API pathwayFortiMail Cloud SaaS capabilities via Graph

The capability surface of FortiMail Cloud SaaS in the out-of-band deployment is nearly identical to the gateway variant, with a few asterisks that are worth understanding upfront. Same underlying detection engines. Same FortiGuard threat intelligence. Same anti-spam / anti-malware / advanced-threat-protection pipeline. The differences are all about when the detection happens (post-delivery not pre-delivery) and what remediation options are available (clawback / move / quarantine, not block).

What FortiMail Cloud SaaS scans for

• Anti-spam — SPF / DKIM / DMARC alignment, sender reputation, IP / domain / URL reputation from FortiGuard, content analysis, behavioural analysis. Vendor claim: 99.97% catch rate (Virus Bulletin).
• Anti-malware — signature-based scanning, heuristic detection, behavioural analysis, virus-outbreak prevention. Vendor claim: 100% detection (SE Labs AAA rating).
• Advanced threat protection — Content Disarm & Reconstruction (CDR) that neutralises active content in attachments, impersonation detection (senior-exec impersonation for CEO-fraud), cousin-domain detection (visually-similar domains registered days before the campaign), click protection with URL rewriting.
• FortiSandbox integration — zero-day and ransomware detection via cloud sandbox. Attachments and URLs that pass initial filters but look suspicious get detonated in the sandbox; if malicious, the message is quarantined via Graph API even if it's already been in the inbox for a few seconds.
• Data loss prevention — outbound scanning for PII / PCI / regulated content. Also runs via Graph, hooking outbound mail via subscription events.
• Business Email Compromise (BEC) protection — the class of attack this deployment shape is arguably best at catching, because API-mode gives visibility into internal mail patterns that would otherwise be invisible.

What's different vs the gateway variant

• No pre-delivery block. Everything is post-delivery quarantine / clawback. If your policy or your regulator requires "never lands in the inbox," you need the gateway variant.
• URL-rewriting behaviour is subtle. In gateway mode, URLs in inbound mail get rewritten at the header level so click-time protection works transparently. In API mode, URL rewrite happens after the message is in the mailbox, which means very-fast-fingered users could click the original URL between delivery and rewrite. Practical impact is small (rewrite typically happens within 30 seconds) but worth knowing.
• Outbound scanning depends on Graph subscription cadence. If you're relying on FortiMail to block outbound DLP violations before they leave the tenant, API-mode adds a few seconds of latency vs gateway-mode where outbound goes through FortiMail synchronously.
• Encryption gateway features aren't available. Gateway-mode FortiMail can act as an S/MIME or Voltage encryption gateway for outbound mail. In API mode, you're relying on M365's native encryption (Purview Message Encryption) — which is fine, but different.

The permission surfaceExactly what Graph API scopes FortiMail Cloud SaaS asks for

Understanding the Azure AD app-registration permission surface matters for two reasons: (a) your security team will want to know exactly what you're granting to a third party in your Microsoft tenant, and (b) DPO / compliance review under DPDP will ask specifically what data access has been authorised. Here's the surface Fortinet's documentation specifies.

The click-pathEnd-to-end deployment walkthrough

Assuming you have a FortiMail Cloud SaaS subscription (either newly-purchased or added to your existing FortiCare account), and Global Admin access to your Microsoft 365 tenant, here's the whole flow. Do it in a change window; it's low-risk but you're granting a third-party app tenant-wide Graph permissions and that's not a change-management-free operation.

The honest comparisonFortiMail Cloud SaaS vs Defender for O365 vs Mimecast API vs Proofpoint API

Every buyer evaluating out-of-band email security on M365 is looking at least three options. Here's the honest read as of mid-2026. None of these are marketing pitches; they're operational observations from actual deployments.

The honest limitsWhen out-of-band is the wrong answer

Any piece that claims a new deployment shape is universally better without naming its limits is marketing. Here are the specific scenarios where the in-band gateway variant is still what you want — or where FortiMail via Graph API isn't the right choice at all.

1. Regulator or internal policy mandates pre-delivery block

RBI Cyber Security Framework doesn't yet explicitly forbid post-delivery clawback for BFSI email security, but some individual banks and NBFCs have interpreted the "adequate controls" language as requiring pre-delivery block. SEBI CSCRF is similar. If your organisation's compliance interpretation requires malicious mail to never touch the inbox, the out-of-band model doesn't meet that bar. Use the gateway variant.

2. High-value BEC-targeted mailboxes where seconds matter

The out-of-band clawback happens within seconds-to-minutes of delivery. For most users that's fast enough — the user isn't checking mail every second. For a CFO's mailbox during a wire-transfer-approval workflow, or a treasury team during month-end payments, even a 60-second window between "malicious mail lands" and "clawback" can be enough for a mistaken click. For those specific mailboxes, run gateway-mode alongside the out-of-band deployment (yes, both — different subsets of users) or use conditional-access mail-flow rules to send only those mailboxes through a gateway hop.

3. Encryption-gateway requirements

If your organisation has a policy requirement to encrypt outbound mail to specific external domains via a gateway-based encryption (S/MIME with certificate-based routing, or Voltage-style transparent encryption), the FortiMail Cloud Hosted variant does this natively. The FortiMail Cloud SaaS variant delegates outbound encryption to M365's Purview Message Encryption, which is fine for most use cases but doesn't replicate all gateway-encryption behaviour.

4. Very large tenants with high mail volume

Graph API has rate limits. For tenants processing more than roughly 5,000-10,000 mails per hour, the out-of-band model can bump against Graph throttling if not architected carefully. Fortinet has published guidance on scaling this out via multiple Graph subscription channels, but at some scale the gateway variant simply performs better because it's not making Graph calls at all. Ask your Fortinet SE for the specific volume threshold at which they'd recommend gateway mode over API mode; typical answer is somewhere between 10,000 and 50,000 mails/hour depending on tenant configuration.

5. Hybrid Exchange environments

If you're still running hybrid Exchange (some mailboxes on-prem, some in M365), the out-of-band model only covers the M365 side. On-prem mailboxes need a different approach — either the gateway variant covering both, or on-prem FortiMail alongside FortiMail Cloud SaaS for the cloud tenants. Most Indian enterprises we work with have completed their hybrid-Exchange migration; if you haven't, factor this in.

6. Purely M365-Defender-committed environments

If you've already invested heavily in Microsoft Defender for O365 P2, and you're running Sentinel or Defender XDR as your SIEM/XDR layer, adding a second email-security vendor may add operational overhead (two consoles, two alert streams, two vendor relationships) without commensurate detection uplift. Do a genuine PoC before you commit — the marginal detection improvement from adding FortiMail on top of Defender P2 is real but smaller than the marginal improvement from adding FortiMail on top of EOP-only.

Where Ogma fitsHonest, brief, not the whole point of the article

Ogma is a Fortinet authorised partner in India across the FortiMail product line — both the Cloud Hosted (gateway) variant and the Cloud SaaS (API / out-of-band) variant covered in this article. We've deployed both shapes across Indian mid-market and enterprise M365 tenants over the last three years and have specific opinions about which shape fits which customer profile, which the framework in this article summarises.

Where we tend to add real value is in the operational-choice layer: helping customers pick between the two deployment shapes on the basis of their actual data-residency posture, their existing M365 licensing (E3 vs E5), their DLP overlap with Purview, and whether their compliance interpretation requires pre-delivery block. The 90-minute architecture review is genuinely useful even for customers who don't end up buying FortiMail from us; we'd rather guide the right buyer to the right shape than pretend a single deployment model fits every use case. Contact details at the bottom.

Common questionsFAQ

ReferencesSources — Fortinet + Microsoft docs