Email Security report
Ops AI scans each connected Microsoft 365 customer tenant for the mailbox misconfigurations that business email compromise (BEC) actually relies on — external forwarding, hidden inbox rules, delegate sprawl, and shared mailboxes that can still sign in.
The scan runs nightly and appears on the customer's page in the app. It also feeds the QBR PDF your end customer receives, so the wording here is the wording they see.
The scan is read-only. It uses Exchange Online (Get-Mailbox and friends) rather than Microsoft Graph, because the fields that matter — forwarding addresses, mailbox type, account state — are not carried by Graph.
What it checks
Findings fall into a fixed taxonomy at three severities.
High — act on these
| Finding | What it means |
|---|---|
| External forwarding | A mailbox forwards mail to a domain the tenant does not own. The classic exfiltration route, and usually the first thing an attacker sets up. |
| External rule forward | An inbox rule forwards externally. Often paired with a delete-on-arrival action so the mailbox owner never sees the replies. |
| Shared mailbox sign-in enabled | A shared mailbox whose underlying account can still sign in. Shared mailboxes typically have no MFA and no owner watching them, so an enabled one is a credential with nobody minding it. |
Medium — worth reviewing
| Finding | What it means |
|---|---|
| Suspicious rule | An inbox rule that deletes incoming mail outright, or that moves mail into RSS Feeds / Conversation History and has a throwaway name (two characters or fewer, or nothing but punctuation). Both are established hide-the-evidence patterns. |
| SendAs delegate | Someone other than the mailbox owner can send as that mailbox. Legitimate in places, and worth knowing everywhere. |
| FullAccess sprawl | Three or more non-inherited FullAccess delegates on one mailbox. |
| Unverified forwarding | The mailbox forwards to a directory recipient whose real delivery address could not be resolved, so external forwarding cannot be ruled out. Deliberately not reported as safe. |
Info — context, not alarms
| Finding | What it means |
|---|---|
| Internal forwarding | Forwarding to a domain the tenant does own. |
| External auto-reply | An auto-reply that replies to anyone outside the tenant, not just known contacts. See below. |
External auto-reply: enabled vs scheduled
Microsoft's AutoReplyState has three values, not two — Disabled, Enabled, and Scheduled — and the report distinguishes the last two, because they are different situations for a technician:
| State | Reported? | Wording you'll see |
|---|---|---|
Disabled | no | — |
Enabled + audience All | yes | "Always-on external auto-reply enabled for all external senders" |
Scheduled + audience All | yes | "Scheduled external auto-reply configured for all external senders — active during its configured window" |
A scheduled external auto-reply is not switched off — it is switched on during a window. Inside that window the mailbox is replying to the entire internet, which is exactly the behaviour an attacker uses to confirm an address is live and to learn who is away.
We report it without checking whether the window is currently open, and say so in the finding text. That is a deliberate choice: this is an informational finding, so the cost of mentioning a currently-dormant schedule is a little noise, whereas evaluating the window would make the check depend on two further timestamp fields and could go quiet on a mailbox that is actively replying. We would rather tell you it exists and let you judge it.
An auto-reply set to Known senders (contacts only) is not reported — that is not an external exposure.
How the band is decided
Each customer gets a single Green / Amber / Red band, in this order:
- Red — one or more High findings.
- Amber — one or more Medium findings.
- Amber — the scan was incomplete (see below), regardless of what it did find.
- Amber — the mailbox cap was reached, so some mailboxes were not scanned.
- Green — none of the above.
Green is only reachable when there were no High findings, no Medium findings, and nothing prevented us from checking. A scan that could not complete cannot be green, even if every mailbox it managed to read came back clean.
"Some mailboxes could not be fully checked"
The report carries a count of mailboxes it could not check, and any non-zero count floors the band to Amber. This is deliberate: an unchecked mailbox is not a clean mailbox, and the report will not imply otherwise.
A mailbox counts as unchecked when:
- a security-relevant read failed — for example Exchange throttled us, or the delegated permissions do not cover that cmdlet;
- the row read back fine but could not be interpreted — an unrecognised mailbox type, or a shared mailbox whose sign-in state we could not determine;
- the row could not be identified at all — Exchange returned a mailbox with no usable address, so there was nothing to run the per-mailbox checks against;
- a tenant-wide read failed, which taints every mailbox in that scan.
If you see this caveat persistently for one customer, it usually means the GDAP permissions for that tenant are narrower than the scan needs — check the customer's Microsoft connection first.
What it does not do
- It does not change anything. Every check is a read; remediation is yours to perform.
- It does not scan beyond the mailbox cap (500 mailboxes). When the cap is reached the report says so and bands Amber rather than implying full coverage.
- It is not a replacement for Defender or Secure Score. It looks specifically at mailbox configuration — the surface those tools tend not to summarise in a form you can hand to a customer.
Related
- Microsoft 365 overview — connecting a customer tenant
- Copilot — Microsoft Graph reads — asking questions about a tenant in natural language