A Complete Guide to Configuring Azure SMTP Server for Reliable Email Delivery

For those with email hosted in M365, you may still have a need for an SMTP server to allow applications to send mail. Some of those applications may not support OAuth authentication or MFA, so a traditional SMTP server is required to allow those applications to send email successfully.

This blog post will show a potential method for setting up an SMTP server using Azure Communication Services. This will use an Entra ID app registration as the authentication mechanism, with a client secret acting as a traditional password.

I recommend putting Azure components for this in their own resource group. This will allow you to segment any charges accrued for the SMTP server solution. A custom Azure RBAC rule is also required. Segmenting the SMTP resources allows this RBAC rule to only apply where it’s needed. You should have the resource group set up prior to proceeding with these steps.

Creating a Custom Role for SMTP Access in Azure

1. From the Azure portal, search for and select the resource group where your SMTP resources will be created.
2. Click Access Control (IAM), click Add, and select Add custom role.

3. Give the custom role a name, something like Send Mail.
4. For Baseline permissions, select Clone a role and select Reader in the drop down.
5. Click Next.
6. Click Add Permissions.
7. Select Azure Communication Services.
8. Under Microsoft.Communication/CommunicationServices, check the box for Read: Gets/Lists communication services.
9. Under Microsoft.Communication/EmailServices, check the box for Write: EmailService_CreateOrUpdate.
10. Click Add.
11. The Permissions tab should now look like this:

12. Click Review + Create, then Create.

Provisioning Azure Communication and Email Services

First, we need to provision an Azure Communication Services resource and an Email Communication Services resource.

1. From the Azure portal, search for and select Communication Services.
2. Click Create.
3. Select the Resource group and type the name of your communication service into the Resource Name box. Note that you’ll need the communication service name when configuring future applications to use the smtp service.
4. Click Review + Create, then Create.
5. From the Azure portal, search for and select Email Communication Services.
6. Click Create.
7. Select the Resource group and type the name of your email communication service into the Name box.
8. Click Review + Create, then Create.

Adding a Domain to Azure Email Communication Services

There are two options for adding a domain to your email communication service. You can use a free Azure subdomain or add a custom domain. I recommend using a custom domain, unless this service will send very few emails. One important note is that your custom domain’s SPF record must be configured with the -all tag. The other SPF options for rejections will fail with this service. If this is an issue for your organization, I suggest putting this service in a subdomain such as smtp1.contoso.com or something similar.

The Azure subdomain severely limits the amount of email that can be sent through the service. As of writing, the limits with an Azure subdomain are 5 emails per minute and 10 emails per 60 minutes. The full list of limits is available at: https://learn.microsoft.com/en-us/azure/communication-services/concepts/service-limits#email.

You can also add both the Azure subdomain and a custom domain. The Azure subdomain is good for testing the service before doing the work of verifying your custom domain.

Configuring an Azure Subdomain for SMTP Email

1. From the Azure portal, open the Email Communication Service you created.
2. Expand Settings and select Provision domains.
3. Click the button 1-click add under Add a free Azure subdomain.

Setting Up a Custom Domain for Reliable Email Delivery

1. From the Azure portal, open the Email Communication Service you created.
2. Expand Settings and select Provision domains.
3. Click Add domain and Custom domain.
4. Enter your domain name in the two text boxes and click Confirm.

Once the custom domain finishes provisioning, follow the wizard to verify the domain. This will involve adding a TXT record to your domain registry.

After your domain is verified, you will need to verify SPF and DKIM. Use the wizard to update these records as needed and verify. Note that if you put this service in a subdomain, the recommended DKIM records provided by the wizard are incorrect. Modify the name field for DKIM and DKIM2 like this:

Wizard value: selector1-azurecomm-prod-net._domainkey

Correct value: selector1-azurecomm-prod-net._domainkey.<subdomain>

Example correct value, assuming subdomain is smtp1.contoso.com: selector1-azurecomm-prod-net._domainkey.smtp1

Wait for SPF and DKIM verification to succeed before proceeding.

Linking Your Domain to Azure Communication Services

Now we need to add the domain to the Azure Communication Service.

1. From the Azure portal, search for and select Communication Services.
2. Open the communication service you created.
3. Expand Email, then click Domains.
4. Click Connect domain.
5. In the Resource Group box, select the resource group that holds your email service.
6. In the Email Service box, select the email service.
7. In the Verified Domain box, select either the Azure subdomain or your custom domain. If you created a custom domain and it doesn’t show up here, check the SPF and DKIM finished verifying.
8. Click Connect.

Registering an Entra ID App for SMTP Authentication

A service principal will be used to provide authentication for the smtp service. We will create an app registration in Entra ID for this.

1. From the Entra ID portal (https://entra.microsoft.com), expand Applications, then select App registrations.
2. Click New Registration.
3. Give the registration a name and click Register. You can keep the defaults, and this doesn’t require a redirect URI.
4. Note the Application (client) ID of the registration. You will use that as part of the username when configuring the SMTP server information in your application that is sending mail.

Add App Registration (Service Principal) To Custom RBAC Role

1. From the Azure portal, search for and select the resource group where your SMTP resources will be created.
2. Click Access Control (IAM), click Add, and select Add role assignment.

3. Select the role that you created and click Next.
4. Click Select Members and select the App Registration.
5. Click Review + Assign.

Generating a Client Secret for SMTP Authentication

When setting up an application to send mail through your smtp rely, you will use a client secret to perform the authentication. You will need to come back to this app registration to create that secret. I recommend creating different secrets for different applications rather than using the same secret across all your apps. Secrets can have different life spans and determining that should be done in accordance with your organization’s policies.

1. Open the app registration
2. Under Manage in the left pane, click Certificates & secrets.
3. Click New client secret.
4. Give the client’s secret a meaningful Description. I recommend the application name where this secret will be used. Set the expiration and click Add.
5. Copy the Value. Once you navigate away from this page, the value will be hidden forever, so store it somewhere safe like in a password vault. You will need this when configuring your application to send mail.

Testing and Using the Azure SMTP Service

To use the service, supply this as the credentials:

• Server name: smtp.azurecomm.net
• Port: 587 (use SSL)
• Username: <Azure Communication Service name>.<App registration client ID>.<Entra tenant ID>
• Example: az-smtp.eac37bc7-4agf-5051-r8y4-615na75d775b.05cae4c3-6591-45b3-865d-b7e4a45424ge
• Password: client secret generated in the app registration

You can test the service with this simple PowerShell script. Replace <domain> in the from parameter and supply a to address. Use the pattern above when prompted for credentials.

$cred = Get-Credential

send-mailmessage -from "donotreply@<domain>" -to "<to address>" -subject "test Az smtp" -body "test body Az smtp" -smtpserver smtp.azurecomm.net -port 587 -usessl -Credential $cred

Note the From address must be donotreply@. To change this or add additional addresses, you will need to open a ticket with Microsoft.

Final Thoughts

This is an easy way to continue to provide basic smtp services after adopting Exchange Online. This service is also cloud-based, so it can be reached by SaaS services that require an SMTP server. This method also provides a fairly secure way to provide this service without MFA.

Disclaimer  

All content provided on this blog is for information purposes only. Windows Management Experts, Inc. makes no representation of the accuracy or completeness of any information on this site. Windows Management Experts, Inc. will not be liable for any errors or omissions in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants if you need further assistance. 

Windows Management Experts

Now A Microsoft Solutions Partner for: 

✓ Data & AI 

✓ Digital and App Innovation 

✓ Infrastructure 

✓ Security 

 The Solutions Partner badge highlights WME’s excellence and commitment. Microsoft’s thorough evaluation ensures we’re skilled, deliver successful projects, and prioritize security over everything. This positions WME in a global tech community, ready to innovate on the cloud for your evolving business needs. 

Contact us: sales@winmgmtexperts.com