Outlook M365 Org Integration

Monitor every Microsoft 365 mailbox in your tenant through the Graph API, with no per-user add-in installs. One setup pulls your directory, assigns seats, and analyzes incoming mail for phishing within seconds of arrival. Results land in the Monitoring Hub, and malicious mail can optionally be auto-quarantined to Junk Email.

Setup is driven end to end by the guided wizard at Account → Integrations. The in-app Outlook Org Integration page has the same steps with copy-ready certificate and PowerShell commands; this page is the reference version.

Requirements

• An active seat plan. Accounts without a seat plan cannot connect org integrations. Members of your monitored group are seated up to your purchased count and unseated mailboxes are not ingested; see Seat Licenses & Pricing.
• An Entra ID administrator to register the app and grant admin consent.
• Recommended, not required: an Exchange administrator to apply an Application Access Policy narrowing which mailboxes the credential can reach. A Blue Lantern account admin can start the wizard and hand these steps to the right people; every value they need is shown copy-ready.

How setup works

1. Start the wizard. Open Integrations, click Add Integration, and choose Microsoft 365 / Outlook. The first step asks one decision up front: whether to allow the optional auto-quarantine action, which adds a write permission.

2. Entra ID: register an app and consent. Register a single-tenant app, add these application permissions (not delegated), and grant admin consent:

   • Mail.Read
   • User.Read.All (directory)
   • GroupMember.Read.All (resolve the monitored group)
   • Mail.ReadWrite (only for auto-quarantine)
   • AuditLog.Read.All (only for the optional daily MFA posture scan)

   Then set Assignment required? → No under Enterprise applications → Properties. Microsoft only signs the change notifications we require when this is set; otherwise it delivers a null token and every notification is rejected. If tenant policy forbids it, assign the Graph Change Tracking service principal (0bf30f3b-4a52-48df-9a82-234910c4a086) a role on the app instead.

3. Create a credential. A certificate is preferred; we read its expiry directly and warn you before it lapses. A client secret works too, but you must supply its expiry date, and Entra caps secrets at 24 months (often less by tenant policy). An expired credential silently stops monitoring, so we track the date and surface a warning on the Integrations page well before it matters.

4. Scope the mailboxes (recommended). Create a mail-enabled security group of the mailboxes to monitor and apply an Application Access Policy restricting the app to it; the wizard generates this PowerShell with your real values. The group is required either way, since it defines who we analyze and seat. The policy narrows what the credential itself can reach. You can connect without the policy after an explicit acknowledgement, which we record.

5. Connect and verify. Enter the tenant id, app id, credential, and group. We authenticate to Graph, confirm consent, and check the scope by proving an in-group mailbox is readable and an out-of-group one is not. If the proof does not pass, your configuration is saved as pending; nothing needs re-entering, and you can verify again later once the policy propagates (Exchange caches policy changes, so allow up to a few hours). Once it passes, your directory is pulled, seats are assigned, and change subscriptions are armed automatically.

Sensitive actions

• Application permissions are tenant-wide by default. Mail.Read as an application permission can read any mailbox in the tenant until an Application Access Policy narrows it. That is why the policy step is strongly recommended, and why skipping it requires a recorded acknowledgement.
• Credential handling. The certificate or secret is sent once over TLS, stored in AWS Secrets Manager (never our database), and never returned by any API. Deleting the app registration or credential in Entra immediately severs our access.
• What we retain. Raw message payloads auto-delete within 24 hours and analysis reports within 90 days. The dedup cache stores only a content hash and run reference, never message content.

Optional: daily identity posture scan

From the integration's Settings you can enable a once-daily scan of who can get into your tenant, reported in the Monitoring Hub under the Identity type:

• MFA registration. Every directory user is checked for a registered MFA method; admins without MFA are critical findings.
• Dormant accounts. Enabled accounts with no sign-in for 90 days (30 days for admins) are flagged; dormant admins are critical.

Both checks require the AuditLog.Read.All application permission with admin consent, and the dormancy check additionally requires an Entra ID P1 or P2 license on the tenant. If the permission was not granted at connect time, grant it in Entra ID and re-run the connect flow; until it verifies, the scan shows "needs permission" and mail monitoring continues unaffected. The scan reads the whole directory, including users whose mailboxes are not monitored.

Optional: daily mail posture scan

Settings also offer a once-daily scan of the ways mail can leak from your org, reported under the Mail Posture type with an exportable report per scan:

• Auto-forwarding. Rules and settings that forward mail to external destinations, the classic BEC persistence move. Admin forwards are critical findings. Requires the MailboxSettings.Read application permission with admin consent; an Exchange Application Access Policy scopes these reads the same way it scopes mail, so restricted tenants get partial coverage (the report states its denominator). Note: admin-set mailbox forwarding configured in Exchange itself is not visible to Graph; pair this check with an Exchange transport rule blocking external auto-forward.
• (Enabling either of the two checks above requires a one-time acknowledgement in Settings: they read and store mailbox forwarding and inbox-rule contents for every directory user, beyond the monitored-group scope. The acknowledgement is recorded with who accepted and when.)
• Suspicious inbox rules. Rules that delete, hide, or divert mail in patterns associated with account compromise. Same MailboxSettings.Read permission.
• Mail authentication. DMARC, SPF, and provider DKIM selector posture of your sending domains. Public DNS lookups only; no permissions involved.

Optional: daily AI exposure scan

Settings also offer a once-daily inventory of the third-party OAuth apps granted access to your tenant's data, reported under the AI Exposure type. It flags AI tools that can reach mail, files, or calendars, and unverified apps holding data scopes (the classic OAuth-phishing shape), and after the first baseline scan it highlights newly appearing risky apps — which can trigger alert rules on the AI Exposure run type.

The scan reads grant metadata only — app identities and scope strings, never message or file content. It requires the Application.Read.All application permission with admin consent; if it was not granted at connect time, grant it in Entra ID and re-run the connect flow. Mail monitoring continues unaffected either way.

Managing the integration

The Integrations page shows connection status, granted scope, credential expiry, and sync results. Settings let you change the monitored group and quarantine rules; changes are merged, so you only submit what changed. Pending connections can be verified from the same page without re-entering configuration. Disconnecting removes the stored credential; revoking consent or deleting the credential on the Microsoft side has the same effect immediately.