ACS Email: one accepted send operation delivered twice (same Message-ID, two MIME builds, two egress regions)

We use Azure Communication Services Email with a verified custom domain. Our application submitted one send request and the recipient received two copies of the message.

Our side is certain there was exactly one request: a single POST, one operation id recorded before submission, and our idempotency records show one attempt.

What the two delivered messages showed (compared from the raw .eml files):

• identical Message-ID and identical operation id in both copies
• byte-identical attachment
• different MIME boundaries, different attachment Content-ID and different DKIM signatures, with signing timestamps 89 seconds apart - so the message was composed twice
• both were composed in ACSPROD mailboxes and egressed from two different regions (northeurope and francecentral), 75 seconds apart
• the first copy stalled roughly 89 seconds between injection and entering Exchange transport; the second copy was composed during that stall and reached the mailbox first

This looks like a single accepted operation being internally recomposed and redelivered on the service side.

Questions:

1. Is internal recomposition and redelivery of one accepted send operation expected behaviour?
2. Can a customer prevent it, or is deduplication at the receiving end the only mitigation?
3. We have enabled EmailSendMailOperational and EmailStatusUpdateOperational. Would such a redelivery be visible in either category - for example as two Delivered rows for one operation?

Business impact: the recipient ingests invoices automatically, so the duplicate caused the same invoice to be booked twice and required manual correction.

There is an existing public report with the same profile: azure-sdk-for-net issue #50889 (open, no response).

Identifying details - operation id, sender domain, message headers and exact timestamps - are deliberately not posted publicly. I will share them privately with a Microsoft support engineer on request.