Outlook.com personal account: Graph createReply/send delivers different Reply-To than stored MIME; Outlook Web works

Question

We are investigating reply routing in our application, Núcleo OS, using Microsoft Graph with delegated permissions for a personal Outlook.com account (an Outlook.pt address). We would appreciate guidance from developers or the Microsoft mail team on the supported approach and the evidence needed to isolate this issue.

All account addresses and message identifiers below are anonymized. This is sending from the authenticated user's own mailbox, not shared-mailbox or Send As delegation.

Observed behavior

The account's primary alias is a normal Outlook.pt address. The Microsoft account alias page confirms it as primary; the generated address outlook_<redacted>@outlook.com is not listed there.

1. Historical Graph test normal02, October 14, 2026: the MIME stored by Microsoft contained the legitimate primary alias in Reply-To. The original email received in Gmail had the generated outlook_<redacted>@outlook.com address in Reply-To. We matched the same RFC Message-ID between these two representations. In this test, From was the generated address. A previous reply attempt to that generated address bounced as unavailable.
2. Historical Graph test normal03, October 14: the received original had the legitimate alias in From but the generated address in Reply-To. Gmail's Reply action selected that generated address. The application's selected strategy and code construction used the legitimate alias for outgoing From/Reply-To, but we do not have an independently retained actual HTTP request and pre-send draft capture for this exact message. A separate experimental draft with correct fields is not evidence for normal03.
3. Outlook Web control, October 19: a message sent directly from the same account arrived with the legitimate alias in From, no Sender header and no Reply-To header. Gmail's Reply action selected the legitimate alias. Its Return-Path was also legitimate, although we understand Return-Path is for bounces, not the normal reply destination.

These controls occurred on different dates and used different constructions. We cannot establish whether the cause is application construction, account state, or Microsoft message processing/delivery. We are not assuming a service regression.

Application flow and authorization

• The app registration supports personal Microsoft accounts and uses the /common authority.
• The existing application authorization includes delegated Mail.ReadWrite and Mail.Send. Graph has successfully sent messages from this mailbox.
• Replies use POST /me/messages/{anchor-id}/createReply, draft preparation/verification, then POST /me/messages/{draft-id}/send.
• The historical reply flow used MIME with explicit From and Reply-To; the own-alias variant also explicitly set Sender equal to From.
• Our read-only audit found no operation copying the incoming message's Reply-To into the outgoing Reply-To. The application does retain historical mailbox identities returned by Graph, so we are separating historical conversation evidence from the current authorized sending identity instead of rewriting history.

Proposed comparison — not yet run

A. Create a reply using JSON, omit From, Sender and additional replyTo, let Graph determine the authenticated mailbox identity, then inspect the draft before sending.

B. If justified by A's results, create a separate reply draft, PATCH the native replyTo property with the current authorized mailbox address, read it back, and compare the stored and delivered representations of that same message. We would not use X-Reply-To.

For each authorized test we intend to retain the redacted actual request, draft fields, stored MIME where accessible, recipient original, matching RFC Message-ID, and the address selected by Reply. We also need to preserve the original conversation, In-Reply-To and References. No further sends are being performed while preparing this comparison.

Questions

1. For a personal Outlook.com mailbox sending as itself, is A the recommended Graph reply flow? Are there documented limitations concerning primary aliases or generated outlook_... identities with createReply/send?
2. Is updating native replyTo on an unsent reply draft the supported way to request a different reply destination, and are there known Outlook.com-specific restrictions compared with Exchange Online?
3. Which additional redacted evidence would distinguish MIME conversion/submission behavior from our application's construction, given the same-Message-ID stored-versus-received difference in normal02?
4. If native reply drafts omit threading headers in a pre-send read, what is the supported way to verify that replying preserves the original thread before submission?
5. Should the explicit Sender in our historical self-send MIME construction be omitted? We understand that Sender and From may legitimately differ in delegated scenarios and do not want an account-specific workaround.

We found the following references:

• https://github.com/microsoftgraph/msgraph-sdk-dotnet/issues/2613 — closed after reports of resolution in August 2024; we are not claiming this is the same incident recurring.
• https://learn.microsoft.com/en-us/answers/questions/1411092/x-reply-to-header-not-changing-reply-to-in-microso — recommendation to use native replyTo rather than a custom header.
• https://learn.microsoft.com/en-us/graph/api/message-update?view=graph-rest-1.0
• https://learn.microsoft.com/en-us/graph/api/message-createreply?view=graph-rest-1.0
• https://learn.microsoft.com/en-us/graph/outlook-send-mail-from-other-user

Separately, a renewed SMTP OAuth authorization followed by one AUTH-only check still produced our application's normalized smtp_auth_disabled outcome, with no email sent. We do not have a retained detailed server response sufficient to identify the internal cause. This question focuses on making the Graph reply route reliable, rather than switching to SMTP.

We have also contacted Microsoft support, without a confirmed technical resolution. No tokens, raw account identifiers, private logs or attachments are included in this public question. Thank you for any guidance on the supported flow or the appropriate escalation path.

Answer 1

Create the baseline reply with JSON createReply, omit from, sender, and replyTo, inspect the resulting draft, and send that same draft; this is the cleanest supported test of Graph’s authenticated-mailbox identity and native threading behavior.

Recommended controlled comparison

Your proposed A is the right baseline:

POST https://graph.microsoft.com/v1.0/me/messages/{anchor-id}/createReply
Authorization: Bearer {token}
Content-Type: application/json
client-request-id: {new-guid}

{
  "comment": "Controlled Graph reply test A"
}

createReply supports personal Microsoft accounts with delegated Mail.ReadWrite, creates a native reply draft, and permits later draft updates. Specify either comment or message.body, not both.^1^

Then:

1. Record the returned draft ID and response headers.
2. Read the draft as JSON, retaining at least:
   • id, isDraft, changeKey
   • from, sender, replyTo, toRecipients
   • internetMessageId
   • conversationId, conversationIndex
3. Retrieve its MIME representation before sending:

      GET https://graph.microsoft.com/v1.0/me/messages/{draft-id}/$value
   

   Graph documents $value as the supported way to retrieve a message’s MIME representation.^2^
4. Send that exact draft:

      POST https://graph.microsoft.com/v1.0/me/messages/{draft-id}/send
   

   Sending an existing reply draft is supported and saves the message in Sent Items.^3^
5. Locate the Sent Items copy by internetMessageId, because a draft’s Graph item ID is not guaranteed to remain stable when it is sent.^4^
6. Capture the sent-item JSON/MIME and recipient-side original source, then compare the same RFC Message-ID.

Testing an explicit Reply-To

Your proposed B is also supported at the Graph property level. The native replyTo property is explicitly updatable while isDraft=true; the operation requires delegated Mail.ReadWrite, which you already have.^5^

PATCH https://graph.microsoft.com/v1.0/me/messages/{draft-id}
Authorization: Bearer {token}
Content-Type: application/json

{
  "replyTo": [{
    "emailAddress": {
      "address": "[Email]"
    }
  }]
}

Read back both JSON and $value before sending. This tests the documented native property, not X-Reply-To.

The available documentation does not establish an Outlook.com-specific guarantee that a patched or MIME-supplied Reply-To will be delivered unchanged, nor does it document special createReply rules for generated [Email] identities. Therefore:

• Treat A as the supported identity baseline.
• Treat B as a supported draft-property request whose end-to-end Outlook.com behavior must be demonstrated.
• Do not present the generated identity as an alias-configuration problem: your primary address is already Microsoft-hosted and confirmed, unlike the third-party-sign-in scenarios described in the alias Q&A reports.

Sender and From

Omit explicit sender in this self-mailbox flow. Graph describes sender as the account actually generating the message and documents updating it for shared-mailbox or delegate sending; its value must correspond to the mailbox actually used.^5^

For sending from another user, Microsoft also says the application does not need to set sender; Graph sets it according to mailbox permissions.^6^ Although that page concerns delegation, it reinforces that manually setting sender is unnecessary. In your nondelegated /me test, omit both sender and from so they cannot confound the result.

Verifying threading before submission

A draft created through createReply is itself the supported threading operation. Preserve and compare:

• Anchor conversationId and reply-draft conversationId
• Draft conversationIndex
• Recipient-side In-Reply-To and References after delivery
• Subject and actual reply recipients

Do not treat absent pre-send MIME In-Reply-To or References as proof that threading was lost. The documentation does not promise those transport headers will be materialized in a draft before submission. There is no documented supported PATCH procedure for synthesizing them on a Graph-created native reply.

Escalation evidence

For every Graph operation, generate and log a unique client-request-id, plus the response request-id and Date; Microsoft identifies these as necessary correlation data for support investigation.^7^

Provide Microsoft Support with one compact A/B package containing:

• UTC timestamp for every request
• Redacted request URL, headers, and exact body
• HTTP status and correlation headers
• Anchor JSON and MIME
• Draft JSON and MIME before and after PATCH
• Sent-item JSON and MIME
• Recipient’s unmodified original source
• Matching RFC Message-ID
• Gmail’s selected reply destination
• Whether the mismatch first appears at draft, Sent Items, or recipient delivery

The 2024 SDK issue was labeled a service issue and later closed after reporters confirmed resolution; it does not establish recurrence or personal Outlook.com applicability.^8^ Your historical normal02 is valuable evidence of a stored-versus-delivered mismatch, but normal03 cannot isolate service processing without the retained request and same-draft capture.

---

References

1. message: createReply
2. Get MIME content of a message
3. Send-MgUserMessage-Syntax
4. Use the Outlook mail REST API
5. Update message
6. Send Outlook messages from another user
7. How to debug Microsoft Graph API calls
8. #2613 Specifying 'ReplyTo' is not working