Duplicate Email Delivery with Single Graph API sendMail Request

Thank you for the detailed explanation of the asynchronous sendMail pipeline.

Based on your response, we understand that:

• The sendMail operation returns 202 Accepted after draft creation
• Further processing occurs within Exchange Online transport
• There is no explicit idempotency guarantee at the service level

However, we would like to highlight the following observations from our system:

Key Findings:

• Only a single API request is made per execution (confirmed via server logs)
• Only one request-id is generated per send operation
• No retry logic exists in our application
• Only one instance of the service is running (PM2 single process)
• Duplicate emails are received with identical content and near-identical timestamps
• This issue occurs intermittently (not on every execution)

Example Case:

• Request ID: 8abb86da-90a1-4637-9471-f99ee8604b2f
• Timestamp (UTC): Wed, 06 May 2026 05:40:06 GMT
• Endpoint: POST /v1.0/users/{user}/sendMail

Clarification Required: Given that:

• Only one request is issued
• No client-side retries occur

We would like to confirm:

1. Is it possible for Exchange Online transport to internally reprocess the same message and deliver it more than once?
2. Are there known scenarios where a single accepted request may result in duplicate delivery without generating an NDR?
3. Can you verify, using the above request-id, whether the message was processed more than once within the transport pipeline?

Request: We kindly request an internal trace analysis using the provided request-id to confirm:

• Number of times the message entered the transport pipeline
• Whether any internal retry or duplication occurred

As this behavior impacts production reliability, we need to determine whether additional safeguards must be implemented on our side or if this is an issue within the service pipeline.

We are happy to provide additional logs or correlation data if required.

Thank you for your support.Thank you for the detailed explanation of the asynchronous sendMail pipeline.

Based on your response, we understand that:

• The sendMail operation returns 202 Accepted after draft creation
• Further processing occurs within Exchange Online transport
• There is no explicit idempotency guarantee at the service level

However, we would like to highlight the following observations from our system:

Key Findings:

• Only a single API request is made per execution (confirmed via server logs)
• Only one request-id is generated per send operation
• No retry logic exists in our application
• Only one instance of the service is running (PM2 single process)
• Duplicate emails are received with identical content and near-identical timestamps
• This issue occurs intermittently (not on every execution)

Example Case:

• Request ID: 8abb86da-90a1-4637-9471-f99ee8604b2f
• Timestamp (UTC): Wed, 06 May 2026 05:40:06 GMT
• Endpoint: POST /v1.0/users/{user}/sendMail

Clarification Required:
Given that:

• Only one request is issued
• No client-side retries occur

We would like to confirm:

1. Is it possible for Exchange Online transport to internally reprocess the same message and deliver it more than once?
2. Are there known scenarios where a single accepted request may result in duplicate delivery without generating an NDR?
3. Can you verify, using the above request-id, whether the message was processed more than once within the transport pipeline?

Request:
We kindly request an internal trace analysis using the provided request-id to confirm:

• Number of times the message entered the transport pipeline
• Whether any internal retry or duplication occurred

As this behavior impacts production reliability, we need to determine whether additional safeguards must be implemented on our side or if this is an issue within the service pipeline.

We are happy to provide additional logs or correlation data if required.

Thank you for your support.

The sendMail method in Microsoft Graph is an asynchronous operation. A 202 Accepted response only confirms that Exchange Online has accepted the request and created a draft message; subsequent processing and delivery happen inside Exchange Online after the Graph call completes.

From the documented pipeline:

1. Outlook/Exchange creates a new message in the sender’s Drafts folder, copies the JSON or MIME content, and saves it. If successful, the method returns 202 Accepted.
2. Exchange Online then notifies its transport service that a new outbound message is available.
3. The transport service reads the message, converts or copies it to MIME, and injects it into the transport pipeline for delivery.

If any failure occurs after step 1 (for example, in step 3), Exchange constructs a non‑delivery report and places it in the sender’s Inbox, but the documentation does not describe any server‑side idempotency or deduplication behavior for sendMail, nor any guarantee that internal retries will never result in duplicate deliveries.

Given the available documentation, the following can be concluded and recommended:

1. Conditions under which duplicates may appear
   • The send pipeline is multi‑stage and asynchronous. Once the draft is created and 202 Accepted is returned, further processing is handled by Exchange transport. If internal retries or reprocessing occur in the transport pipeline, they could, in principle, re‑use the same draft content, which would appear as a duplicate message to recipients. The documentation explicitly notes that failures in later steps cause NDRs, but does not enumerate all retry conditions or explicitly rule out duplicate deliveries.
2. Whether duplicates are expected behavior due to internal retries
   • The documented behavior for sendMail focuses on: creating the draft, returning 202 Accepted, and then handing off to transport. It does not state that duplicate deliveries are expected or normal, nor does it describe a contract that sendMail is idempotent at the service level. Therefore, duplicate deliveries are not described as expected behavior, but the service also does not provide an idempotency guarantee.
3. Recommended approach for idempotent delivery with sendMail
   • The API itself does not expose an idempotency key or a built‑in deduplication mechanism. To achieve practical idempotency, implement it at the application level, for example:
     • Include a unique message identifier in the subject or body and have downstream systems or recipients treat messages with the same identifier as duplicates.
     • Track sent messages in the sender’s mailbox (Drafts/Sent Items) and in application storage, and avoid re‑issuing sendMail for the same logical message.
   • Because 202 Accepted only confirms acceptance, not final delivery, any retry logic must be carefully designed to avoid issuing a second sendMail call for the same logical message unless there is a clear, application‑level decision to do so.

For deeper investigation of specific duplicate events (such as the example request ID provided), service logs from Exchange/Graph would be required, which are not exposed in this documentation. In such cases, opening a support case with Microsoft and providing the request-id and timestamp is the appropriate next step.

References:

• user: sendMail
• Overview of the Microsoft Graph send mail process