Send emails via SMTP relay with Azure Communication Services
We’ve come across multiple cases where customers want to send emails from applications migrated to Azure through some kind of SMTP service. Though we’ve seen customers opting for O365 for SMTP relay, this can create issues due to throttling limitations in Office Service. Also, managing mailbox and license assignment on Office 365 console is a different story; customers would want to have seamless SMTP relay service experience from single console on Azure.
In scenarios where you don’t want to modify code and just change the pointing of your SMTP server to Azure, you can now use SMTP relay built into Azure Communication Services' Email.
Azure Communication Services supports different types of notifications, and this blog post offers simple step by step instructions for how you can quickly test and then migrate from other services you’re using to native to Azure for better operational experience and support.
Create Azure Communication Services Resource
First step you’ll need to do is to create a Communication Services resource from the Azure portal. This is a parent service which has multiple notification services inside it (Chat, SMS, Email, etc). Email is one of them.
Create an Email resource
Add a custom domain
Azure Communication Services Email will provide a default domain that looks like this “GUID.azurecomm.net” and allows for a limited volume of email, so if you need more volume limits, we recommend creating a custom domain. Once you add a custom domain, the UI provides you with a TXT file which you’ll need to create in your Name server. This would take 15 minutes to verify the domain
Once the domain is verified, create SPF and DKIM records so that your email doesn’t land in junk and ownership is maintained.
Once all the records are created the screen would look like this, please ignore the Azure managed domain. You can only have custom domain in the account and doesn’t have to add Azure domain explicitly.
Attach custom domain
Once the custom email domain is validated, we’ll need to attach the Email service to the Azure Communication Services resource.
Create and assign custom RBAC Role for Authentication
We’ll be using 587 port to send email which is authenticated SMTP. For authentication we have Entra ID authentication. Create a service principal by going to Entra ID – App registration page. Register the app and create a client secret. Note down Client ID, Tenant ID and Secret value. This will be used in next stage for authentication. We’ll need to create a custom RBAC role which has permission to send email. We’ll clone reader role.
And we’ll be adding two actions which is present in Azure Communication service resource provider.
Once the Role is created we’ll need to assign this to service principal
Test SMTP Relay via Powershell
That’s all, now you’ll need to find out the sender email. Which is default [email protected]
You’ll need credentials to authenticate to the service.
- Username is < Azure Communication Services Resource name>. < Entra Application ID>. < Entra Tenant ID>
- Password is the client secret which you’ve generated.
- Port that we’ll need to use is 587
- SMTP server address is smtp.azurecomm.net
Now you can use any third party application to send email via the above parameters. To showcase we can use PowerShell with the same parameters to send emails.
Conclusion: I trust this guide helps you in configuring SMTP relay and send emails from your custom application without any change to the application/code.
Happy Learning!
Personal Blog post of SMTP relay:
Send emails via SMTP relay with Azure Communication Service
Find similar tech blog on my personal blog
https://www.azuredoctor.com/
Published on:
Learn moreRelated posts
Automating Business PDFs Using Azure Document Intelligence and Power Automate
In today’s data-driven enterprises, critical business information often arrives in the form of PDFs—bank statements, invoices, policy document...
Azure Developer CLI (azd) Dec 2025 – Extensions Enhancements, Foundry Rebranding, and Azure Pipelines Improvements
This post announces the December release of the Azure Developer CLI (`azd`). The post Azure Developer CLI (azd) Dec 2025 – Extensions En...
Unlock the power of distributed graph databases with JanusGraph and Azure Apache Cassandra
Connecting the Dots: How Graph Databases Drive Innovation In today’s data-rich world, organizations face challenges that go beyond simple tabl...
Azure Boards integration with GitHub Copilot
A few months ago we introduced the Azure Boards integration with GitHub Copilot in private preview. The goal was simple: allow teams to take a...
Microsoft Dataverse – Monitor batch workloads with Azure Monitor Application Insights
We are announcing the ability to monitor batch workload telemetry in Azure Monitor Application Insights for finance and operations apps in Mic...
Copilot Studio: Connect An Azure SQL Database As Knowledge
Copilot Studio can connect to an Azure SQL database and use its structured data as ... The post Copilot Studio: Connect An Azure SQL Database ...
Retirement of Global Personal Access Tokens in Azure DevOps
In the new year, we’ll be retiring the Global Personal Access Token (PAT) type in Azure DevOps. Global PATs allow users to authenticate across...
Azure Cosmos DB vNext Emulator: Query and Observability Enhancements
The Azure Cosmos DB Linux-based vNext emulator (preview) is a local version of the Azure Cosmos DB service that runs as a Docker container on ...