Why is Mail.ReadWrite required for sending emails via Microsoft Graph API?

Question and Answers
1

Hi Nylas Team,

I recently set up Microsoft email integration using the Nylas v3 API for sending emails only (no reading/syncing). Following the documentation, I configured my Azure AD app with the Mail.Send delegated permission as recommended.

However, when attempting to send emails using the /messages/send endpoint, I consistently received a 403 error:

{
  "error": {
    "type": "api.insufficient_scopes",
    "message": "missing scope required to send email",
    "provider_error": {
      "error": {
        "code": 403,
        "message": "Access is denied. Check credentials and try again."
      }
    }
  }
}

After extensive troubleshooting, I discovered that adding Mail.ReadWrite to both the Azure AD app permissions AND the Nylas connector scopes resolved the issue. Email sending now works perfectly.

My questions:

  1. Why is Mail.ReadWrite required for sending emails? Is this because Nylas creates a draft message (POST /me/messages) before sending it, rather than using the POST /me/sendMail endpoint directly?

  2. Should the documentation be updated to include Mail.ReadWrite as a required permission for email sending functionality?

  3. Is there a way to send emails with only Mail.Send (without Mail.ReadWrite) for organizations that have strict permission policies?

Environment:

  • Nylas API v3
  • Microsoft Graph API (Microsoft 365 accounts)
  • Azure AD app with delegated permissions
2

Hi Dishant,

Thanks for your thoughtful questions — happy to clarify.

Why is Mail.ReadWrite required for sending emails?

Yes, your understanding is correct. Nylas creates and manages a message object (for example, creating a draft) before sending it. These actions require Microsoft Graph permissions that go beyond Mail.Send, which is why Mail.ReadWrite is needed.

Should the documentation be updated?

The current documentation does list Mail.ReadWrite as the required scope for the /messages/send endpoint, but we agree this can be easy to miss. We’ll share your feedback with our docs team to help make this clearer.

Can emails be sent with only Mail.Send?

Based on the scopes table, there isn’t a way to send emails through Nylas v3 with only Mail.Send. The minimum required Microsoft scope for the send endpoint is Mail.ReadWrite.

Here’s the documentation outlining the Microsoft scopes required for sending messages via the Nylas API:
Using granular scopes to request user data | Docs..#messages-api-scopes

Please let us know if you have any other questions.

Thanks,

Pracheta Munje.

Support Engineer, Nylas

Screenshot 2026-01-15 at 18.36.15
Screenshot 2026-01-15 at 18.36.151830×1208 263 KB

3

Hi Pracheta,

Thanks for the explanation.

I did some digging into the Microsoft Graph docs, and it seems that the Mail.ReadWrite requirement comes from Nylas’ implementation rather than Microsoft itself.

Microsoft supports sending mail directly via POST /me/sendMail, and the least-privileged permission for that endpoint is Mail.Send. Mail.ReadWrite is only needed if you create or manage draft messages (POST /me/messages), which is what you say Nylas appears to be doing internally.

Would it be possible for Nylas to support a “send-only” flow for Microsoft accounts? For example:

  • If the grant only has Mail.Send, call /me/sendMail directly.

  • Only require Mail.ReadWrite for features that actually need drafts (such as draft management or large attachment uploads).

Many enterprise customers have strict least-privilege policies and cannot approve Mail.ReadWrite for an integration that only needs to send emails. Supporting a Mail.Send-only path would make Nylas much easier to adopt in those environments.

Is this something the team would consider adding to the roadmap?

Thanks!

4

Hi Aleksey,

Thanks for the thoughtful follow-up. We understand the appeal of a Mail.Send-only flow, so we want to be transparent about what a “direct send” option (via /me/sendMail) would mean for you in practice.

Sending without first creating the message object would change the behavior you rely on today:

  • No message ID at send time. A direct send doesn’t return a handle to the sent message, so you’d lose the stable Nylas message ID you currently get back. Reconciling a send with the copy in Sent Items would require searching after the fact, which isn’t reliable.
  • Reduced threading guarantees. Replies would still thread based on the headers you provide, but there’d be no way to confirm how the message was threaded into the conversation — so threading becomes best-effort rather than verified.
  • Attachment constraints. Large attachments rely on the draft-based upload flow, so a direct send would have tighter size limits.

Why open and click tracking would break specifically: Nylas tracking works by embedding a unique token into each message — a tracking pixel for opens, and rewritten redirect links for clicks. When a recipient opens or clicks, that token pings our servers. The catch is that our tracking webhooks (message.opened, message.link_clicked) are built around the Nylas message ID — it’s the key that ties an open or click event back to the specific email you sent. Without a message object, there’s no message ID to populate in the webhook and no stored record to attach the event to. So even though a pixel or link ping might technically arrive, you’d have no reliable way to know which message or send it corresponds to. In practice, that makes open and click tracking unusable in a send-only flow.

Because these capabilities — reliable message IDs, threading, and tracking — are core to what most integrations depend on, the current flow requires Mail.ReadWrite to preserve them. We’d rather keep that consistency than offer a lighter path that quietly drops functionality you may be counting on.

Happy to help you get Mail.ReadWrite through your admin consent process if that’s the sticking point.

Many thanks,
Samuel R.
Support Engineer, Nylas