Graph /me/sendMail: From is always the signed-in user

Symptom

Your app sends notification e-mails via POST /me/sendMail with delegated Mail.Send. The customer asks for them to come from noreply@contoso.com — you set message.from accordingly, and Graph rejects the call (SendAs denied), or you're tempted to "just make it configurable" and it never works.

Cause

With delegated Mail.Send, mail is sent as the signed-in user — that's the whole security model. Graph accepts a different from/sender only when the user genuinely holds SendAs rights on that mailbox. There is no header, property, or permission scope that lets a normal delegated call impersonate an arbitrary address.

Fix

Two honest options:

A. Embrace the personal From (usually right for intranet scenarios — a message from a real colleague gets read) and give admins control over what they can control:

message: {
  subject,
  body,
  toRecipients,
  replyTo: [{ emailAddress: { address: configuredReplyTo } }]
}

Let any "sender address" setting in your app govern Reply-To, footer and branding — never From.

B. Truly need a service address? That's a different architecture: application permissions (Mail.Send as app-only, admin-consented and ideally scoped via an application access policy) sending from a shared mailbox — plus the deliverability homework (SPF/DKIM/DMARC alignment) that comes with it.

Notes

• If you rename a "Sender" setting to "Reply-To" in the UI, users stop filing bugs about it — the setting finally does what it says.
• App-only Mail.Send without an application access policy can send as anyone in the tenant — scope it, or security review will (rightly) flag it.