Claude and Microsoft 365 Email: Native Connector or Custom MCP?

Claude can now work with Microsoft 365 without you building the custom email bridge described in the original version of this article.

For most organisations, the right starting point is Anthropic's Microsoft 365 connector. It can search Outlook email, calendars, SharePoint, OneDrive and Teams using the signed-in person's existing permissions. If an administrator enables the connector's write tools, Claude can also draft or send email and manage categories, rules and automatic replies.

A custom Model Context Protocol (MCP) server still has a place, but only when you need your own business logic, a private system that the native connector cannot reach, or tighter control over the tools Claude is allowed to call.

That is the important 2026 update: do not build and secure an email integration merely to reproduce a supported native connector.

Fact-checked against current Anthropic documentation and Microsoft Learn on 7 August 2026. Features, licensing and administrator controls can change, so verify the linked product documentation before a production rollout.

The short answer

Requirement	Start here	Why
Search your own Outlook mailbox and Microsoft 365 content	Anthropic's Microsoft 365 connector	Supported setup, user permissions apply
Draft email with a human reviewing it	Native connector with the appropriate write tool enabled	Less custom infrastructure and a visible review step
Send or organise email from Claude	Native write tools, if approved by your administrator	Anthropic documents email, category, rule and automatic-reply tools
Use a personal Outlook.com account	Neither route as described here	Anthropic says its Microsoft 365 connector requires a work account
Join email to a private CRM, ticketing system or specialist workflow	Custom MCP server	Your server can expose only the business-specific tools you design
Run an unattended background mailbox process	Power Automate, Logic Apps or a properly governed service	Anthropic says the connector works on demand, not as a background monitor

If all you want is “find the messages about Project Falcon and help me draft a reply”, use the native connector. If you need “find the customer, check our private support system, calculate their service entitlement and create a proposed response without sending it”, a custom integration may be justified.

What changed since the original article?

The first version documented an experimental MCP server that connected Claude to Microsoft Graph. It proved the idea, but it also left the reader responsible for hosting code, registering an application, implementing OAuth, protecting credentials and designing every read and write tool safely.

Anthropic now publishes a Microsoft 365 connector made by Anthropic. Its setup documentation covers Outlook, SharePoint, OneDrive, Teams and calendar access, along with administrator consent and write-tool controls.

That makes the old custom-server-first advice obsolete. The rest of this guide separates the supported native route from the custom route so you can choose deliberately.

Route A: use Claude's Microsoft 365 connector

What you need

Anthropic's current documentation says the connector requires a Microsoft 365 work account; personal Microsoft accounts are not supported. In a managed organisation, a Claude Team or Enterprise owner and a Microsoft Entra Global Administrator are involved in the one-time organisation setup and consent.

Do not treat that consent screen as an administrative formality. It is the point at which your organisation decides which connection it is willing to make between Claude and Microsoft 365.

After the organisation setup, an eligible user connects Microsoft 365 from Claude's connector settings and signs in with their work account. The connector then works within the content that user is already allowed to access.

Begin with read-only work

The safest first use is search and summarisation:

• Find messages from a named customer during a defined date range.
• Summarise a long thread and cite the messages used.
• Compare an email request with a relevant SharePoint document.
• Identify messages that appear to need a reply, without changing them.
• Draft a response in the conversation for a person to review.

Use bounded prompts. “Review every email and clean up my mailbox” hides too many decisions in one instruction. A better prompt is:

Search my Inbox for messages received in the last 14 days from @contoso.com. Return the subject, sender, received time and a one-sentence summary. Do not move, delete, categorise, reply to or send anything.

That prompt defines the mailbox area, time period, output and forbidden actions. It is easier to inspect and harder to misunderstand.

Add write tools one decision at a time

Anthropic documents optional Microsoft 365 write tools for actions including drafting or sending email, managing folders and categories, creating inbox rules and setting automatic replies. Those tools must be enabled by an administrator and can be controlled individually.

Do not jump from read access to every available write action. A sensible rollout is:

1. Search and summarise.
2. Produce a draft for human review.
3. Create drafts in Outlook, but do not send.
4. Enable sending only for a defined group and use case.
5. Add mailbox-organisation tools only after testing representative edge cases.

Sending, deleting, moving and creating rules have different consequences. Treat them as separate permissions, not one generic “email access” switch.

Know the current connector boundaries

Anthropic's documentation also records limitations that matter in a real design:

• The connector operates on demand; it does not continuously watch the mailbox in the background.
• Microsoft 365 personal accounts are not supported.
• Email attachments are not currently supported by the write tools.
• The SharePoint connection follows the user's permissions, but Anthropic says it cannot currently be restricted with Microsoft Graph Sites.Selected.
• Shared mailboxes can be searched when the signed-in user already has access.

Those boundaries rule out some projects. For example, if your process must take every new invoice attachment and store it automatically, use an event-driven workflow. This Outlook attachment to SharePoint guide shows the Power Automate pattern.

Route B: build a custom MCP integration

Build a custom server when the native connector cannot express the job or its control model. A support team might need a tool that returns one ticket's approved knowledge, but never exposes a free-form search of the whole ticket database. A regulated workflow might require every proposed send to pass through a separate approval service.

The architecture is:

Claude
  -> trusted remote MCP server
       -> Microsoft Entra OAuth
            -> Microsoft Graph
       -> approved business systems

Anthropic describes custom remote MCP integrations as a beta capability and tells customers to connect only to servers they trust. Your server is part of the security boundary: it defines the tools, validates inputs, holds or exchanges credentials and decides what can reach Microsoft Graph.

Choose Graph permissions from the action backwards

Microsoft Graph separates common mail permissions:

Permission	What Microsoft says it permits	Sensible use
Mail.ReadBasic	Basic mail properties; excludes body, attachments and extended properties	Metadata-only triage
Mail.Read	Read the signed-in user's mail	Search and summarisation that needs message content
Mail.ReadWrite	Create, read, update and delete mail; does not include send	Drafting, moving, categorising or deleting
Mail.Send	Send mail as the user	A separately approved sending tool

Use delegated permissions when the user is present and the task is meant to run with that user's access. Microsoft recommends least privilege and notes that application permissions can give a service access across mailboxes after administrator consent. That is a materially larger blast radius.

Do not request Mail.ReadWrite because it is convenient if the tool only reads. Do not assume Mail.ReadWrite includes sending; Microsoft documents Mail.Send separately.

Separate read tools from consequential tools

A safer MCP tool surface might expose:

search_mail(query, start_date, end_date, folder)
get_message(message_id)
create_draft(message_id, proposed_body)
move_message(message_id, destination_folder)
send_draft(draft_id, confirmation_token)

This is better than a single manage_mailbox(instruction) tool. Narrow tools make the proposed action visible, let you apply different permissions and give your interface a clear confirmation point before a send, delete, rule change or bulk move.

Design for failure too. Graph can reject requests, consent can change, messages can move and two people can act on the same item. A successful natural-language exchange is not evidence that Microsoft 365 accepted the operation; return the Graph result and a stable message or draft identifier.

Implement authentication as a security feature

Microsoft documents the OAuth 2.0 authorisation-code flow with PKCE for applications that sign in users. Public clients must not contain a client secret. For server-side services, Microsoft recommends certificates or managed identities over long-lived client secrets where the hosting model supports them.

Also:

• Validate the tenant and redirect URI.
• Store tokens in an appropriate encrypted secret store.
• Never log access tokens or message bodies by default.
• Keep development and production app registrations separate.
• Record the tool name, user, target and outcome for consequential operations.
• Expire confirmation tokens and make retry behaviour explicit.

The Microsoft Graph Outlook mail overview documents the available mail operations. The Microsoft Graph permissions reference is the source of truth for the permission boundary.

A practical rollout that does not begin with “AI, tidy everything”

Use one low-risk, measurable job:

1. Pick a mailbox and a defined message type.
2. Write five examples of a correct result and five that require a person.
3. Connect read access only.
4. Test retrieval accuracy, missing context and permission behaviour.
5. Add draft creation, keeping send disabled.
6. Review every draft for two weeks.
7. Decide whether the saved time and error rate justify any further permission.

Measure the result that matters: messages correctly found, drafts accepted without material edits, time saved and mistakes caught before action. “Claude answered confidently” is not a control or a success metric.

The Gerald the Duck experiment in the original article remains a useful illustration. Claude could read a fictional email, use project context and produce a relevant reply. What it did not prove was production security, unattended reliability or permission design. A convincing demo and a governed email system are different achievements.

If the actual problem is filing email into SharePoint rather than conversing with it, start with this 2026 guide to Microsoft 365 and third-party email-management options. AI should not be added where a retention label, mailbox rule or proven filing add-in solves the job more predictably.

Questions to answer before enabling send

• Can the user see the exact recipients, subject and body before the message leaves?
• Does the tool distinguish reply, reply all and forward?
• What happens to hidden recipients and sensitivity labels?
• Can the action send externally, or only to approved domains?
• Is there a stable audit record linking the request, draft and Graph result?
• What happens if the same send is retried?
• Who can disable the connector or revoke consent quickly?

If those questions do not have crisp answers, stop at drafts.

Keep up with practical Microsoft 365 AI

The Microsoft Copilot & AI Mastery Space tracks the connectors, controls and working patterns that survive contact with a real tenant.

Primary sources used

• Microsoft 365 connector for Claude
• Connect Claude to Microsoft 365
• About custom integrations using remote MCP
• Building custom integrations with remote MCP servers
• Microsoft Graph Outlook mail overview
• Microsoft Graph permissions reference
• Microsoft identity-platform integration checklist
• OAuth 2.0 authorisation-code flow

Source boundary: Anthropic documents its current connector capabilities and limitations; Microsoft documents Graph operations, permissions and identity patterns. This article does not claim that the old demonstration code is a supported product, that every Claude plan or Microsoft 365 licence has identical availability, or that an AI-generated action is correct without verification.