Azure Email Communication Services sending email via SmtpClient how to set the MessageId?

Question

Azure Email Communication Services sending email via SmtpClient how to set the MessageId?

Andrei B 50

Hello,

We are currently implementing Azure Communication Services in our application via SmtpClient. Everything is working ok but we got to the point where we want to receive events to an webhook endpoint in order to mark the emails as bounced.

The problem is that in the documentation there is no way to set the message id(for example setting a header like: X-Message-Id) or to get it after sending the email.

Is there any way to do this without using the SDK since we have a general implementation for using multiple providers and it is using SmtpClient.

Thanks!

1 answer

Your answer

Answer 1

Hi @Andrei B,

Azure Communication Services' Email feature does support webhooks for events such as delivery, bounce, opened, etc. These are identified using the messageId which is Generated by Azure itself when you send an email. Only accessible when sending emails via the ACS SDK or REST API, because those return the messageId in the response.

Unfortunately, when you send emails via SmtpClient, ACS doesn't expose the generated messageId back to you. Additionally, Custom headers like X-Message-Id are not recognized by ACS for tracking purposes. There’s currently no supported way to explicitly set or retrieve the messageId when using SmtpClient.

If you need to reliably track bounces or other email events via webhooks, you will need to switch to the ACS Email SDK or REST API, at least for sending. Here's why:

Only the SDK/API provides the generated messageId in the response.
That messageId is referenced in all delivery and bounce events, allowing you to correlate sent messages with webhook payloads.

Use ACS Email SDK: This is the most straightforward way:
- After sending the email, you receive the MessageId immediately.
- You can store it and correlate it with incoming webhook events. Send Email using Azure Communication Services
If you want to avoid SDKs, you can call the REST API directly. You’ll still receive the messageId in the JSON response. https://learn.microsoft.com/en-us/rest/api/communication/email/email/send?view=rest-communication-email-2023-03-31&tabs=HTTP

If you're strictly limited to using SmtpClient (and not ACS SDK or API), you won’t be able to capture the messageId and therefore cannot reliably correlate events from webhooks. This is a current limitation of ACS when used via SMTP.

https://learn.microsoft.com/en-us/answers/questions/1464206/question-about-the-message-id-when-sending-service
https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/send-email-smtp/send-email-smtp?tabs=dotnet&pivots=smtp-method-smtpclient

If the answer is helpful, please click Accept Answer and kindly upvote it so that other people who faces similar issue may get benefitted from it.

Let me know if you have any further Queries.

Hanrath, Stefan 26 Reputation points

2025-07-01T13:15:50.45+00:00

Hi, it's a bit puzzling, as without event correlation via SMTP, SMTP really only becomes 'fire and forget' and the use case becomes rather limited.

With SMTP, we can use the special header: x-ms-acsemail-validate-message-id and set a valid message ID according to the RFC for SMTP, i.e.
message.Headers.Add("Message-ID", "<******@blabla.test>");
The mail will arrive in an inbox with the specified message ID as is expected, if we check the message ID on arrival (tested with outlook.com, gmail.com, o365 exchange).

This message is, as you pointed out, distinct from the message ID used in event grid (that is the ID of the emitted event, and is completely different), so I fully understand that is a separate entity reference.

The problem i see is mostly:

The event grid event also populates and specifies InternetMessageId, which is described in the ACS docs as 'The internet message id of the recipient'.

This is populated with the expected 'mail' message ID in event grid events, the one we specify with our SMTP client, unless we send to microsoft email recipients.
(tested with outlook o365 and outlook.com).

In that case we get something random and unrecognizable / meaningless to us (that also does not correspond to the message-id the recipient inbox gets in their mail message headers).

This is the only reason why we are effectively forced away from using SMTP native clients.

If that field is intended to contain the message-id then it does not seem to be behaving consistently depending on the recipient, though the spec of the RFC2822 message-id is somewhat vague here.

Is this a known bug? Or rather, will the behavior of the message-id in the InternetMessageId behaviour field be made consistent with messages sent to i.e. gmail, and the id in messages received by recipients?

Share via

Azure Email Communication Services sending email via SmtpClient how to set the MessageId?

1 answer

Your answer