Clarification on whether opening a local .msg file in New Outlook creates or syncs a draft mailbox item

Question

Clarification on whether opening a local .msg file in New Outlook creates or syncs a draft mailbox item

Xiang Zhang 0

Hello Microsoft Support,

We are evaluating a New Outlook integration scenario and would like clarification on the supported and stable platform behavior when opening a local .msg file.

In our local testing, we observed that opening a local .msg file in New Outlook appears to create or sync a corresponding draft item into the signed-in Outlook mailbox.

However, we are not sure whether this behavior is officially supported, documented, and safe to rely on for production integration scenarios.

Our scenario is:

A Windows desktop application has a local Outlook message file on disk (.msg).

The application opens that file in New Outlook.

For some flows, we only need the message to be viewable.

For draft/edit flows, we need the message to become a real mailbox item so that it has a stable item identifier and can be used by an Outlook web add-in and Microsoft Graph.

We would like to confirm the official behavior for the following questions.

Questions

When a local .msg file is opened directly in New Outlook, is the creation or synchronization of a draft mailbox item expected product behavior?

If this behavior is expected, is it officially supported and stable enough to rely on in production scenarios?

If this behavior is supported, is there an official or documented way to obtain the resulting mailbox item ID, Outlook item ID, or Microsoft Graph message ID?

If a draft mailbox item is created implicitly when the local .msg is opened, are Outlook web add-ins expected to activate for that resulting item?

If this behavior is not guaranteed, what is the recommended supported approach for importing a local .msg file as an editable draft mailbox item in New Outlook?

Is explicitly creating the draft through Microsoft Graph the only supported and recommended implementation pattern for this scenario?

Reproduction steps

Prepare a local .msg file on disk.

Open the file directly with New Outlook.

Observe that a draft item appears to be created or synchronized into the mailbox.

Verify whether the resulting item has a stable mailbox identity that can be used by add-ins or Microsoft Graph.

What we need from Microsoft

We would appreciate confirmation of:

whether this observed behavior is officially supported,

whether it is documented and stable across product versions,

whether it is safe to build a production workflow that depends on it, and

what Microsoft recommends as the supported implementation for draft/edit scenarios.

If the supported approach is to:

convert the local message to MIME if needed,

create a draft mailbox item explicitly via Microsoft Graph, and

then open that mailbox item in New Outlook,

please confirm that this is the recommended pattern.

If there is any official documentation, API guidance, or product limitation statement for this scenario, please share it.

Thank you.

0 comments

1 answer

Your answer

Answer 1

Dear @Xiang Zhang,

Thank you for posting your question in the Microsoft Q&A forum.

Based on your description, I am not aware of any Microsoft documentation that guarantees that opening a local.msg file in New Outlook will always create a corresponding mailbox draft item that can be relied upon for production workflows. Microsoft documentation primarily states that New Outlook supports opening local.msg,.eml, and .oft files, but it does not explicitly document or guarantee the creation of a mailbox item with a stable Outlook or Microsoft Graph ID when those files are opened.

For integration scenarios that require a stable mailbox item, Outlook add-in activation, or Microsoft Graph access, the safer and more supported approach is to explicitly create the draft message in the mailbox first and then work with that mailbox item. Microsoft Graph supports creating and saving draft messages, which receive message identifiers that can later be referenced programmatically.

Because your question involves Outlook add-in behavior and Microsoft Graph integration, I recommend posting it in the Microsoft Graph community, where specialists can provide product-specific guidance on supported implementation patterns. I believe they will give you accurate and efficient solution for your concern.

Additionally, if this behavior is critical to your implementation, please submit feedback through Microsoft Feedback Portal or open a Microsoft support case via in the Microsoft 365 Admin Center> Support > Help & Support to obtain official confirmation from the Outlook product team.

Note: Please understand that as forum moderator, my primary goal is to provide helpful guidance and support through general troubleshooting steps. While I don’t have access to internal systems or test devices required to resolve backend issues, I truly appreciate your understanding of these limitations. I genuinely hope the information I share helps guide you in the right direction, and I'm always here to assist as much as I can within my scope.

If you have any other questions, please feel free to reach out.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.