How post-delivery API email security works in Microsoft 365
Learn how API-based email security analyzes Microsoft 365 messages after delivery, what access it requires, and which questions to ask before deployment.
An email security vendor tells you deployment requires no mail exchange (MX) record changes. You approve an application, and the service starts inspecting Microsoft 365 mailboxes without becoming another stop in your mail flow.
That sounds simpler than adding a gateway, but the convenience comes with a trade-off. The application may receive privileged mailbox access, while a malicious message may reach the inbox before analysis and remediation finish.
This article focuses on that post-delivery Microsoft Graph model. Some API products support pre-inbox or hybrid enforcement, and some also protect Google Workspace. Those designs have different timing, permissions, and failure modes.
What post-delivery API email security means
A post-delivery service connects to Microsoft 365 through Microsoft Graph and related security APIs. Microsoft 365 delivers the message first. The external service then retrieves permitted evidence, analyzes it, and may request a response such as moving or deleting the message. The basic flow looks like this:
Sender -> Microsoft 365 -> Mailbox
|
Microsoft Graph
|
Security platform
|
Alert or remediation
Because the service is not another Simple Mail Transfer Protocol (SMTP) hop, it usually does not require an MX record change. However, no mail-flow change does not mean no security risk. Microsoft warns that Graph-based third-party email security may require broad mailbox access.
Microsoft's integration guidance describes this as a supported way to scan messages after delivery and remove messages considered malicious or unwanted. It also recommends reviewing the provider's security and support practices before granting access.
How one Microsoft Graph workflow operates
The exact architecture varies by product. The following sequence shows one common event-driven design for Microsoft 365.
1. Approve the application identity
Your organization first approves a service identity in Microsoft Entra ID. The granted application permissions determine which mailbox data and response actions the platform can use without a person being signed in.
Permission review is part of the security architecture, not an administrative formality. Before approval, answer these questions:
- Which mailboxes can the application access?
- Can it read metadata, message bodies, attachments, or all three?
- Can it update, move, delete, or send messages?
- How will you revoke that access during an incident or offboarding?
Role Based Access Control for Applications in Exchange Online
can grant an application specific operations over a defined mailbox scope. One
detail matters: these assignments are additive with grants in Microsoft Entra
ID. If the application still has an organization-wide Mail.Read grant in
Microsoft Entra ID, adding a scoped Mail.Read assignment in Exchange Online
does not restrict the original grant.
2. Detect a mailbox change
Not every provider uses Microsoft Graph notifications, but they are one common option. An application can subscribe to message changes and receive an event at a secured webhook when a message is created, updated, or deleted. A webhook is the URL the provider exposes to receive those events.
Microsoft Graph change notifications may contain identifiers or selected encrypted resource data. A notification is a trigger, not a verdict. The platform may still need to retrieve the current message and related evidence before analysis.
Subscriptions expire and must be renewed. A resilient service also needs lifecycle notifications, retry handling, duplicate-event protection, and a way to recover changes missed during an outage. Event-driven does not mean instant or exactly once.
3. Analyze the message and its context
After receiving an event, the service gathers the evidence allowed by its permissions. Depending on the product and scope, that evidence may include:
- Sender and recipient identities.
- Subject, body, links, and attachment metadata.
- SPF, DKIM, and DMARC results.
- Message headers and delivery information.
- Previous communication between the identities.
- Similar messages across permitted mailboxes.
- User, mailbox, directory, or identity context from separate integrations.
This context is useful for attacks that contain no malware or known-bad link. For example, business email compromise may come from an authenticated account and ask for a payment through ordinary text. Historical relationships and an unusual request can provide the strongest signals.
Some products also inspect internal or sent messages, calendar invitations, and account activity. These are product capabilities, not automatic benefits of an API connection. Confirm the exact coverage and permissions instead of assuming that every API-based platform sees the same data.
4. Produce an explainable verdict
The platform may classify a message as benign, suspicious, spam, phishing, or malware. A useful verdict explains which evidence changed the assessment.
An analyst should see concrete signals such as an unusual Reply-To address, a
new sending domain, a suspicious redirect, failed authentication alignment, or
a request that conflicts with previous communication. A risk score without
supporting evidence gives your team little to investigate or challenge.
The result may create an incident in the vendor platform or send evidence to an existing case-management or security operations workflow. The integration should preserve the message identifiers and timestamps needed to trace the decision later.
5. Request remediation
Not every analyzed message should be removed. A low-risk message may remain in place, a suspicious message may generate an alert, and a high-confidence threat may trigger an automated response.
Microsoft Graph's analyzed email remediation API
supports moving messages to junk, deleted items, quarantine, or the inbox, as
well as supported deletion actions. The API requires the application permission
SecurityAnalyzedMessage.ReadWrite.All.
The request is asynchronous. Microsoft Graph returns 202 Accepted, and its
status can be tracked through the Action Center in Microsoft Defender. Your runbook
should account for that delay and provide a safe way to restore false positives.
What API access can add
The API model enables useful capabilities, but it does not guarantee that every product implements them well. Evaluate the result rather than the deployment label.
- No mail-flow cutover: You can add a post-delivery layer without routing inbound email through another external gateway.
- Historical and relationship context: The service may compare a message with previous communication, known identities, and similar activity.
- Internal and sent-message visibility: A product may inspect messages that do not cross an external mail gateway, if its permissions and design allow it.
- Post-delivery search and removal: New intelligence can trigger a search for related messages and remediation across affected mailboxes.
- Investigation evidence: Message history, campaign scope, and remediation records can support incident response and forensics.
- Account-compromise context: A separate identity integration may correlate sign-ins, inbox rules, and behavioral changes with suspicious email activity.
Features such as data loss prevention, encryption, security training, URL rewriting, and account-takeover detection are not inherent to API deployment. Treat them as separate product claims that require their own evidence and access.
Where this model can fail
The message may already be visible when a post-delivery platform starts work. That creates a race between the recipient and the detection workflow. A vendor that calls its service "real time" should still provide measured timings.
Ask for the median and 95th-percentile time from delivery to analysis, verdict, and completed remediation. The platform should expose each timestamp so your team can verify those claims in production.
The surrounding API workflow introduces other failure modes. Test each one before deployment:
- Microsoft Graph or the vendor service may be unavailable.
- API throttling can delay retrieval or remediation during a large campaign.
- Subscriptions can expire or lose notifications.
- Events can arrive late, more than once, or out of order.
- Automated remediation can remove legitimate business email.
- A compromised vendor identity can expose or alter mailbox data.
A reliable design needs retry limits, backoff, duplicate-safe processing, subscription renewal, and lifecycle monitoring. It should also search for missed messages after an outage and document how to restore false positives.
Permissions, privacy, and coexistence matter
The integration may process message bodies, attachments, communication history, directory data, or identity signals. Ask where that data is stored, how long it is retained, which subprocessors can access it, and whether it is used to train shared models.
Protect application credentials, scope mailbox access where possible, record every remediation, and test the revocation process. Review the connection like any other privileged cloud application, not as a harmless plug-in.
An API platform can work alongside Microsoft Defender for Office 365 without replacing its native mail-flow controls. Clear ownership of verdicts, remediation, restoration, and user reporting keeps the two layers working as one security process instead of producing duplicate work.
Why API security has an advantage over a gateway
A secure email gateway analyzes messages while they cross the mail path. That is useful for blocking known threats before delivery, but its decision is usually based on the message and context available at that moment.
An API platform remains connected to the cloud email environment. That creates advantages that an external gateway may struggle to provide:
- Cloud-native context: The platform can use mailbox, directory, identity, and historical communication data when the approved integrations provide it.
- Internal and sent-message visibility: It can inspect activity that never crosses an external gateway, including messages from compromised accounts.
- Continuous reassessment: It can revisit delivered email when URLs change, users report messages, or new campaign evidence appears.
- Direct response: It can search affected mailboxes and request remediation through Microsoft Graph without routing mail through another service.
- Simpler deployment: It adds protection without an MX cutover, another mail hop, or a redesign of the existing delivery path.
- Better behavioral detection: It can compare a request with established relationships and activity, helping detect business email compromise and impersonation messages that contain no malicious payload.
The advantage is not the API by itself. It is the combination of cloud context, continuous visibility, and direct response that the API makes possible. This is especially valuable for attacks that look legitimate during a one-time gateway inspection but become suspicious when viewed inside the wider organization.
Questions to ask before deployment
A useful evaluation turns broad promises into testable answers. Ask the provider:
- Coverage: Which inbound, internal, sent, calendar, and identity events can the product inspect?
- Enforcement point: Does analysis happen before delivery, after delivery, or in both places?
- Permissions: Which delegated and application permissions are required, and how are Microsoft Entra ID grants and Exchange Online RBAC scopes combined?
- Speed: What are the median and 95th-percentile analysis and remediation times?
- Reliability: How does the service handle throttling, expired subscriptions, duplicate events, and Microsoft Graph or vendor outages?
- Accuracy: How are false positives and false negatives measured in customer environments, and how can analysts override a verdict?
- Evidence: Can analysts see the headers, relationships, links, model signals, and timestamps behind each decision?
- Data handling: Where is customer data processed and retained, and is it used for model training?
- Operations: Which platform owns quarantine, restoration, user reporting, incident creation, and audit history?
- Offboarding: How are subscriptions, credentials, permissions, stored data, and integrations removed?
API protection is more than easier deployment
Avoiding an MX change is an immediate operational benefit. The larger security advantage is staying connected to Microsoft 365 after delivery, where the platform can use organizational context, monitor changing evidence, and respond across affected mailboxes.
A well-designed API platform combines fast event processing, behavioral analysis, explainable verdicts, controlled permissions, and reliable remediation. That gives your team broader visibility and a faster way to contain the context-driven attacks that a gateway may not recognize on its own.
