Username length issue with SMTP in Azure Communication Services

Question

Hi,

I'm testing "Email SMTP as a Service" that is in preview within "Azure Communication Services". I was so excited to hear about it because we've just done an Exchange migration to O365, and this feature will help mop up the remaining SMTP client apps without having to deploy any SMTP relay infrastructure.
It was very easy to set up and get working for 2 test domains.... BUT...

The instructions state that a Service Principal must be used as the user. And with this, the username must be in the following format:
<Azure Communication Services Resource name>|<Entra Application ID>|<Entra Tenant ID>

This makes for a super long username. Mine was 94 characters! It worked in one SMTP client software but others I've tested have character length limits such as 60 characters.

The 2 pipes (or dots), App ID and Tenant ID guids mean that the username has 74 characters before the ACS resource name prefix is added!

I thought it might work with a UPN as username, so I added a user to the IAM Role Assignment, but that didn't work, returning error code "535 5.7.3 Authentication unsuccessful".

Is there a workaround? Because without one, the use of this SMTP feature will be severely limited.

Thanks,

Jonny S

Answer 1

@Jonny Sharp Good news! The product group wants me to gather some information from you so they can look into whether or not it would be possible to address this limitation.

Can you please send me an email to azcommunity@microsoft.com with the subject as ATTN: Bryan. I will then reply with the information we need for the product group to begin their consideration.

Answer 2

Hey Jonny,

Ah, the joys of preview features—where the excitement of cutting-edge tech meets the frustration of "why won’t this just work?!" Your 94-character username is like trying to fit a novel into a tweet some clients just can’t handle the drama.

Sadly, the Service Principal format is non-negotiable (thanks, Azure), and UPNs are a no-go (error 535 says "nice try, though"). For now, you’re stuck with clients that can handle your epic username saga. Maybe it’s time to start a support group for SMTP clients with character limits?

As a workaround, you could try using a proper SMTP relay (I know, I know, it’s like going back to dial-up after fibre) or beg Microsoft to shorten the username in a future update. Fingers crossed they’ll fix it before the feature goes GA!

Keep fighting the good fight, and let me know if you crack it.
Cheers! Alex

Answer 3

Hey Jonny,

Ah, the joys of preview features where the excitement of cutting-edge tech meets the frustration of "why won’t this just work?!" Your 94-character username is like trying to fit a novel into a tweet—some clients just can’t handle the drama.

Sadly, the Service Principal format is non-negotiable (thanks, Azure), and UPNs are a no-go (error 535 says "nice try, though"). For now, you’re stuck with clients that can handle your epic username saga. Maybe it’s time to start a support group for SMTP clients with character limits?

As a workaround, you could try using a proper SMTP relay (I know, I know, it’s like going back to dial-up after fibre) or beg Microsoft to shorten the username in a future update. Fingers crossed they’ll fix it before the feature goes GA!

Keep fighting the good fight, and let me know if you crack it.

Cheers! Alex

Answer 4

I was hoping this would work better as well. I went with the High Volume Email (HVE) Account for my client. I tested it internally and it works, I’ll be implementing it with my client this week. Additionally, it doesn’t require a license. The Azure Communication Services probably works best for apps vs devices. The HVE Account has external limitations but, they should be more than sufficient for devices scanning to email.