A Modern SMTP Relay for Post-Exchange Environments

As more organizations retire their last on-premises Exchange server, and as Microsoft Defender for Office 365 introduces more aggressive email throttling, many customers are facing the challenge of finding a new reliable SMTP relay.

Azure Communication Services (ACS) with Email capabilities is emerging as a modern, scalable alternative.

In this article, I will walk you through the setup of an SMTP relay using ACS, correcting a key mistake in earlier community guides, and focusing on two primary use cases:

• Organizations decomissioning Exchange Hybrid SMTP relays
• Organizations hitting outbound email limits in Microsoft 365

---

Why Azure Communication Services (ACS)?

ACS provides:

• SMTP relay access over port 587 (STARTTLS)
• Simple authentication via username and client secret
• Support for verified custom domains, so you can add any of your existing domains
• High-volume email capabilities beyond Defender limits

---

Step-by-Step Setup

1. Create the ACS Communication Service Resource

Create an ACS Communication Service. This resource supports telephony and messaging features, but we also need a separate resource for Email capabilities.

2. Create the Email Communication Service

This is a separate type of Azure resource that powers email delivery.

Important: This is the step that is missing or wrong in some guides. You need both resources: one for core ACS, and one explicitly for Email.

---

3. Add Your Domain

You can use either a free Azure subdomain or your own custom domain. For production scenarios, always go with a verified custom domain.

4. Set Up SPF and DKIM

Once added, you must configure SPF and DKIM to ensure your emails aren’t marked as spam.

There is a built in easy to follow guide for this, that even provides you with the DKIM keys.

If you want more in-depth info on DKIM,DMARC etc check out my other article: https://www.thomasjuhlolesen.dk/2023/08/understand-dmarc-and-use-it-now.html

After you configured everything make sure it lights up as verified.

---

5. Create Service Principal

Create a Service Principal for SMTP Relay Authentication

Before assigning roles, you must create an App Registration in Microsoft Entra ID (formerly Azure AD), which acts as your service principal.

1. Go to Azure Portal → Microsoft Entra ID → App registrations → New registration.
2. Give the app a name (e.g., acs-smtprelay-tjo).
3. Choose the supported account type (usually single tenant).
4. Redirect URI is not needed for SMTP use cases, leave it blank or set to https://localhost.
5. Click Register.

Once created:

• Note the Application (client) ID and Directory (tenant) ID — you’ll need these for the SMTP username.
• Go to Certificates & secrets → New client secret → Create and copy the value immediately.

You now have:

• App ID = part of the SMTP username
• Tenant ID = part of the SMTP username
• Client Secret = your SMTP password

6. Assign Permissions for SMTP Credential Access

To allow a service principal or app to access and send through the SMTP endpoint, create a custom role.

a) Create a Custom Role

Clone the built-in “Reader” role and add permissions for:

• Microsoft.Communication/CommunicationServices/Read
• Microsoft.Communication/EmailServices/Write
• Microsoft.Communication/CommunicationServices/Write

Now add the 3 custom permissions

b) Assign Role to Application

Find your app registration (Service principal) and assign the new custom role.

---

7. Add MailFrom Address

The approved sender addresses is enforced by ACS and gives you a noreply that can be used with your domain.

Note: As you can see in the screenshot Add button is greyed out. You can add custom sender email by sending couple of emails from the default email address and then raising support case. support engineer can help you change the tier to higher which will allow you to add more custom email address.

---

8. Link Domain to Communication Resource

Ensure the domain is linked to your Communication Service so it can relay emails.

This is a simple but mandatory step.

---

9. Generate Your SMTP Credentials

Once the app registration and role assignment is done, generate your SMTP credentials using the format:

<resource name>.<app id>.<tenant id>

In my examples – its ACSSMTPtjo.apid.tenantid – so the ACS ressource name NOT the Email ressource, this han many people confused – you can also separate with pipes |

And use the client secret as your SMTP password.

SMTP server: smtp.azurecomm.net
Port: 587
TLS: Required

---

9. Test It with PowerShell

Now you are more or less done, and time to celebrate and test with the mandatory Hello World ! 🙂

Use the following script to verify mail delivery:

$smtpServer = "smtp.azurecomm.net"
$smtpPort = 587
$from = "donotreply@mail.domain.dk"
$to = "tjo@domain.com"
$subject = "SMTP Relay Test via ACS"
$body = "Hello World! -this is a testmail via ACS SMTP Relay."

$username = "ACSSMTPtjo.<appId>.<tenantId>"
$password = "<client-secret>"
$securePassword = ConvertTo-SecureString $password -AsPlainText -Force
$cred = New-Object System.Net.NetworkCredential($username, $securePassword)

$mailMessage = New-Object system.net.mail.mailmessage
$mailMessage.from = $from
$mailMessage.To.add($to)
$mailMessage.Subject = $subject
$mailMessage.Body = $body
$mailMessage.IsBodyHtml = $false

$smtpClient = New-Object Net.Mail.SmtpClient($smtpServer, $smtpPort)
$smtpClient.EnableSsl = $true
$smtpClient.Credentials = $cred

try {
    $smtpClient.Send($mailMessage)
    Write-Host "Mail sent successfully"
} catch {
    Write-Error "Send failed: $_"
}

---

Conclusion

Azure Communication Services is not only a future-ready way to handle telephony and SMS — it now offers a production-grade SMTP relay that is ideal for customers migrating off Exchange or those being throttled by Microsoft Defender limits.

By using the correct combination of Email Communication Services, verified domains, custom MailFrom addresses, and role-based access.

In my experience you can implement a reliable and scalable SMTP relay in less than an hour