Many applications rely on authenticated SMTP (SMTP Auth) as the only way to send emails. For example, you might have some applications from which you want to receive email alerts. What many still do, even though this is no longer recommended, is create a user in their domain/tenant and provide this user with an Exchange license (typically something like an Exchange Online Plan 1, 2, or Exchange Online Kiosk license). In any case, for the application to authenticate using this user, you would most likely need to configure it with basic auth (no MFA).

The fact that you are relying exclusively on passwords is a big red flag in and of itself. Microsoft does not allow it when using their Security Defaults (which are recommended when you do not have Microsoft Entra ID P1 licenses). New mailboxes are not allowed by default in Office 365 to use SMTP Auth. On top of that, Microsoft has announced that their SMTP endpoints for Office 365 will be taken offline by September 2025. It is time for you to take a look at what applications are making use of Exchange Mailbox with SMTP Auth and migrate them to the recommended methods.

If your application can use OAuth 2.0, then you are done. Well, not exactly, but almost! Look at the documentation for your application on how to register an application to Entra, get an access token, and how to use that token to authenticate connection requests. It should be the same process for every application, but the application has to support the protocol.

Most likely, your applications are still going to rely on plain SMTP for sending their emails. In that case, I will assume you need to send emails internally and externally and that you do not have an on-prem Exchange server. For these cases, we can use Azure Communication Services (ACS) Email.

What is ACS?

Azure Communication Services offers multichannel communication APIs for adding voice, video, chat, text messaging/SMS, email, and more to all your applications.
Source: https://learn.microsoft.com/en-us/azure/communication-services/overview

These services enable you to integrate communication channels into your applications and, at least in the case of email, also get some powerful analytics.

In this case, we do not wish to develop applications and integrate with the communication services. We simply wish to deploy our own ACS SMTP resource and authenticate against that. Still, you might end up enjoying the other goodies that come with it like email analytics and engagement tracking.

Preparation

Prerequisites

To keep this guide as simple as possible, I will assume you already have the following or are capable of setting them up yourself:

1. An Azure subscription
2. Access to your domain’s DNS settings for verification

Create an Email Communications Service resource

1. Login to the Azure Portal.
2. Search for the Email Communication Services (ECS) resource.
3. Create a new instance of that resource.
4. Create a new resource group and define its location. For the ECS resource, you just need to define a name and where the data should be stored.
5. Wait for the resource to validate the deployment and then click on Create.

Create an Azure Communication Services resource

1. Search for the Communication Services resource.
2. Click on Create.
3. Select the same subscription and resource group as before. Give the instance a name and choose a location for the data storage.
4. Navigate to Review + Create. Wait for the validation to finish and click on Create.

Adding a custom domain to your Email Communication Service

1. Navigate to your ECS resource.
2. Under Settings, find the Provision domains menu.
3. Click on the right option to setup a custom domain.
4. Add the custom subdomain you want to add and click on Confirm.
5. Click on Add and then on Close.
6. Wait for your deployment to finish.
7. Configure the domain to get it verified.
8. Make a note of the TXT value shown. You will have to add a DNS record of TXT type to verify the ownership of the domain.
9. After adding the DNS record, click on Next and let Azure verify. After a few minutes (Azure says it can take up to 20 minutes), you will get a green checkmark.
10. Next, configure SPF and DKIM by clicking on the word Configure under the SPF status column.
11. You will again get a list of values you will need to store as TXT records and as CNAME records. Review this guide if you need more details on how to read or add those records: https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/add-custom-verified-domains?pivots=platform-azp#configure-sender-authentication-for-custom-domain.
12. Wait a few minutes for the DNS settings to propagate and Azure to verify them. If the DNS records match what Azure is expecting, then you will get green checkmarks in all columns.

Connect a verified email domain

1. Navigate to the Communication Service resource you just deployed.
2. Look for the Domain options under the Email section of the navigation pane.
3. Click on Connect domains.
4. From the drop-down menus, select the corresponding options and click on Connect.
5. You should now see your domain with the status Connected.

Registering a new application with Entra ID

1. Go to the Entra administration portal.
2. Navigate to Identity → Applications → App registrations and click on New registration.
3. Give the application a name, for example, SMTP Notifications. Under “Who can use this application?”, select Single tenant.
4. Click on Register.

Using SMTP with an Entra application and Azure Communication Services

After all that preparation, we are finally ready to do the final two steps before testing our new method for sending emails using SMTP:

1. Give our newly created Entra application the permissions to send emails using the Azure Communication Services resource.
2. Generate the client secrets, which will be needed to compose the username and password that we need to provide when setting the SMTP integration of our apps.

Granting the app permissions to send emails through Azure Communication Services

For these next steps, you have two possibilities. The first one would be to go to the ACS resource and give the application (or rather the corresponding service principal) the role of Contributor. If you are fine with that, then you can skip the following set of instructions and continue to the next section. I will define a custom role with only the necessary permissions for the application.

1. Navigate to the Communication Service resource (for me it is DS-ACS-01).
2. Open the Access control menu.
3. Open the Roles tab.
4. Make a clone of the Reader role.
5. Give the role a name and a description (optional). Click on the Permissions tab.
6. Click on Add permissions.
7. Search for Azure Communication Services.
8. Select the permissions:
   • Microsoft.Communication/CommunicationServices/Read
   • Microsoft.Communication/CommunicationServices/Write
   • Microsoft.Communication/EmailServices/Write
9. Click on Add.
10. Remove the read permissions that were cloned from the global read permissions.
    Click on Review + create. Finally, create the role.

Assigning the role to the application

1. Navigate to the ACS resource and open the Access control menu.
2. Click on Add role assignment.
3. Click on the role you wish to assign. In my case, I'm using my custom role ACS SMTP Write. If you did not define your own role, then select the Contributor role.
4. Click on the Members tab.
5. Add the application by clicking on Select members.
6. In the pop-up menu, search for your application and select it by clicking on it. Click on Select. You have to search for your application; by default, you only see users and shared mailboxes.
7. Finally, click on Review + assign.
8. Verify by going to the Role assignments tab and finding the application with the correct role.

Generate credentials for the SMTP Auth

SMTP username

We have already done everything to get our username to send emails. The username consists of three components:

1. The name of the ACS resource (e.g., DS-ACS-01).
2. The Application ID.
3. The Directory ID.
   The username is composed of these three pieces of information separated by dots or pipes:

• username: <Azure Communication Services Resource name>.<Microsoft Entra Application ID>.<Microsoft Entra Tenant ID>
  or
• username: <Azure Communication Services Resource name>|<Microsoft Entra Application ID>|<Microsoft Entra Tenant ID>

SMTP password

The SMTP password is the value of the application's client secret. If you don't have one yet, generate one like this:

1. Inside the application, navigate to Certificates & secrets, click on the Client secrets tab, and then on New client secret.
2. Add a description and expiration date.
3. Click on Add.
4. Copy the value of the secret and keep it safe. It will not be displayed again. If you lose it, you will have to generate a new secret.

Testing

For testing, you need to tell the application what server, what port, and what TLS setting it should use.

There is one last thing you might want to set up. By default, you only get one MailFrom address created (in my case, it was DoNotReply@notifications.dirgosalga.com). You can add more MailFrom addresses in your Email Communication Services resource. This seems to require you to contact support and request that they remove the default limits. I do not need that right now, so I won't do it. But you can read more about it here: https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/add-multiple-senders?pivots=platform-azp

For testing SMTP authentication, I asked my coding partner, ChatGPT, to write a PowerShell script. You can use the same code to verify that everything is configured correctly.

$smtpServer = "smtp.azurecomm.net"
$smtpFrom = "donotreply@your.custom.domain"
$smtpTo = "diego@example.com"
$subject = "SMTP Test"
$body = "This is a test email to verify SMTP credentials."
$smtpUsername = # Put your Username here (string).
$smtpPassword = # Put your password here (string).

$message = New-Object system.net.mail.mailmessage
$message.From = $smtpFrom
$message.To.Add($smtpTo)
$message.Subject = $subject
$message.Body = $body

$smtp = New-Object Net.Mail.SmtpClient($smtpServer, 587)
$smtp.EnableSsl = $true
$smtp.Credentials = New-Object System.Net.NetworkCredential($smtpUsername, $smtpPassword)

try {
    $smtp.Send($message)
    Write-Host "Test email sent successfully."
} catch {
    Write-Host "Failed to send test email. Error: $_"
}

If you get an email, you are done!

Next steps

My next step is to identify every application that uses SMTP and replace the old users with this new method. I will eventually need to increase the limits and define more MailFrom addresses. I plan to test this setup for one or two weeks before making the definitive change.

Conclusion

This process was more complicated than I initially anticipated. It involves several new components, which can be challenging if you are unfamiliar with these services. So, what is the advantage of implementing it this way? Primarily, this is what Microsoft recommends, and we will all need to adopt it eventually if they proceed with removing their SMTP endpoints for Office 365. Regarding security, this approach is indeed an improvement. There is no longer a traditional user that can be compromised to pivot around my environment. However, applications are still authenticating using basic authentication, so at the very least, someone could send emails as that application. Nonetheless, there is certainly much more flexibility in how you handle the credentials of such an application and ways to automate secret rotation using Azure Key Vault, for example.

What about costs? I will be replacing an account that I currently license with an Exchange Online Kiosk license, which costs me €1.87 per month. This provided me with only 2 GB of mailbox storage but was more than enough for my use case. An enterprise is more likely to need Exchange Online Plan 1 or 2 for €3.70 and €7.50 per month, respectively. You would need to be sending more than 13,300 emails at 0.5 MB each to justify the price of those licenses. So if your applications produce fewer emails than that, you should also see a decrease in costs.

Sources

1. https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-retire-basic-auth-for-client-submission-smtp/ba-p/4114750
2. https://learn.microsoft.com/en-gb/azure/communication-services/quickstarts/email/send-email-smtp/smtp-authentication
3. https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth