Microsoft 365 Email Redaction Straight From the Outlook Mailbox

The request usually reaches a Microsoft 365 administrator as a short ticket asking for a redaction tool to be connected to the mailboxes of the custodians named in a records request. Someone then has to decide what that connection may read, what it may change and who approves anything that leaves. In many organizations, Microsoft 365 email redaction still means exporting first and redacting second. Search and hold tools find the responsive mail and then stop at export. The results come out as a PST container, a folder of message files or a PDF package, and a reviewer marks up the files by hand, one request at a time.

Each export leaves a copy of sensitive mail outside the systems that govern it, often with attachments separated from their messages. Working from the mailbox removes that step and puts questions of access, completeness and approval in its place, which the administrator and the records lead have to answer together. Our guide to email redaction across a mailbox covers what a message contains and how to test a release, and our post on redacting email in Outlook covers the single message.

Questions to settle in writing before a tool is connected

Every product connected to a Microsoft 365 tenant for redaction should be able to answer the questions below, and the answers become the configuration the administrator signs off on. Keep them in the procurement file as well, since anyone who later asks how a release was assembled will start from them. The rest of this article explains what sits behind each one.

What Microsoft Graph hands back when a tool reads a mailbox

Any tool that reads Outlook mail through Microsoft Graph receives the same message structure, whether it is a script, an eDiscovery product or a redaction workflow. According to the message resource reference, listing messages returns "all the messages in the signed-in user's mailbox (including the Deleted Items and Clutter folders)." A pull built that way reaches mail a custodian has already moved to Deleted Items, which, as our guide notes, can still fall within a request.

Message identifiers are less stable than they look, and that matters when a request runs for days while custodians keep filing their mail. By default, a message's id "changes when the item is moved from one container (such as a folder or calendar) to another." Only a request that sends the Prefer: IdType="ImmutableId" header gets identifiers that survive a move. A pull that records ids and then meets a custodian filing mail mid-request can count the same message twice or lose track of one. For every message it retrieves, a tool should record the custodian, the folder, the immutable id and the time of the pull. A message filed twice is then recognized as one, and any item can be traced to where it came from.

Bcc recipients appear only in the sender's own copy of a message, so a pull limited to the recipients' mailboxes never sees who else received it. A request that needs them has to reach each sender's Sent Items as well. Recurring requests leave a different gap, since a monthly production in an ongoing matter raises the question of fetching only what changed since the last pull. Graph supports that through delta queries, and each increment then has to be reconciled against what was already released.

Access an administrator can live with

Microsoft's documentation for RBAC for Applications in Exchange Online describes the application role for Mail.Read as one that "Allows the app to read email in all mailboxes without a signed-in user." The same feature lets an administrator pair a grant with "a scope of access (resource scope) to specify which mailboxes an app can access." Microsoft also states that it "replaces Application Access Policies."

Scoping has one trap that catches careful administrators: Microsoft evaluates the two permission systems together rather than letting one override the other. Grants made in Exchange Online act in addition to grants in Microsoft Entra ID, so an application that still holds an unscoped Mail.Read grant in Entra keeps reading every mailbox. Microsoft's FAQ on the feature says the union of the unscoped grant and a scoped one "results in no effective resource scoping."

Write and send permissions are granted separately, and a pull that only gathers messages for redaction needs neither of them. The same page describes Mail.ReadWrite as a role that "Doesn't include permission to send mail," with Mail.Send granted on its own to send "as any user without a signed-in user." A tool that only reads a request's messages should hold read access scoped to the custodians the request names, with sending and deletion kept out of the pull entirely. Where a workflow does need to change a mailbox, each change belongs behind one of the approval steps described in our article on human-in-the-loop approval.

A scope granted for one request also tends to outlive it, which is easy to miss once the release has gone out. Narrow or remove the scope when the request closes, and review the custodian list each time a recurring request runs, so that a standing read on several mailboxes never becomes the default.

A pulled message leaves the tenant's own controls the moment it is copied into another system, so the administrator's job does not end with the grant. They should know where those copies land, who can open them there, how long they are kept and what record shows each redaction made to them. Those answers belong in the same sign-off as the grant itself, since a tightly scoped read that fills a loosely governed store has only moved the exposure somewhere else.

A pull that does not lose messages

Scope the pull by custodian, folder and date range before anything is retrieved. A pull narrower than the request misses mail, and a wider one collects mail nobody should read. Then page through the results until Graph reports that no further pages remain. For each custodian, record how many messages the search reported and how many actually arrived. Keep both numbers with the release, since they are what shows later that nothing was lost between the mailbox and the production.

Throttling is the next place a pull can end early, and it is easy to mistake for a mailbox that simply had nothing more to give. A throttled call fails with a 429 status and a Retry-After header, and Microsoft's throttling guidance is to wait the number of seconds that header specifies before trying again.

The quietest failure of all is a result that stops short of the full set without saying so. We have seen it in agent-driven mail searches, where more messages matched a search than one request is allowed to return. The operation fetched the first batch, said nothing about the rest, and handed back a list that looked complete to the agent and to anyone reviewing its work. A result that hits a cap should say it is partial, say why, and ask for a narrower request, so that the gap announces itself and can be closed while there is still time.

Authorization can also lapse partway through a request, when a token expires or consent is withdrawn. A tool that then skips the mailbox quietly makes that custodian look as if they had nothing responsive, so a lapse should stop the run with a message to reconnect. Treat any mailbox that comes back with a count of zero as a question to answer before the release goes out.

Where the Outlook connection lives in VIDIZMO

In the VIDIZMO setup our guide describes, the Outlook connection lives in AI Intelligence Hub, configured on its integration framework over Microsoft Graph, so reaching a mailbox is configuration rather than code. The workflow pulls messages with their attachments and hands them to VIDIZMO Redactor. There each message is rendered and redacted as a document, and each attachment is redacted by the method its own format calls for.

Every request the integration engine sends is checked so that it cannot be steered to an internal address, redirects are refused, and credentials are presented only to the host they were issued for. When Microsoft throttles a call, the engine honors the Retry-After signal instead of pressing on.

For how mailbox redaction sits alongside Teams recordings and SharePoint documents, see the Microsoft 365 redaction page.