| ACS Email Series – Part 2 of 5 This is Part 2 of our Azure Communication Services Email series. In Part 1, we covered why SMTP relay is breaking down and why ACS Email is the modern alternative. In this article, we’ll walk through using the Azure portal to complete setup from zero to sending your first email. Parts 3 and 4 will cover DNS configuration (SPF, DKIM, DMARC) and managing sender identities with real-world automation. Part 5 will show you how to automate ACS deployment and tracing with the ACS Email PowerShell Toolkit! |
It’s Monday morning. Your helpdesk queue has three tickets that all say the same thing: “Scan to email stopped working.”
You check Exchange Online. Microsoft tightened SMTP authentication again. The shared service account your copiers use is locked out. The app password expired. Or maybe Basic Auth was finally disabled on your tenant and nobody got the memo.
Sound familiar? It should – this scenario plays out in organizations everywhere, and it’s only getting worse as Microsoft continues to deprecate legacy authentication methods. The good news: you can fix this permanently in about 30 minutes with Azure Communication Services Email.
In this walkthrough, I’ll take you from zero to a fully functional ACS Email setup, complete with a custom domain, SMTP authentication, and a working copier configuration. No Exchange dependency. No shared mailbox credentials. No more Monday morning scan-to-email fires.
What You’ll Need Before You Start
Before we dive in, make sure you have these ready to go. There’s nothing worse than getting halfway through a setup and realizing you don’t have DNS access.
- An active Azure subscription with permissions to create resources
- A custom domain you control (e.g., somedomainsomewhere.com) with access to your DNS provider
- Global Administrator or Privileged Role Administrator access in Microsoft Entra ID
- About 30 minutes of uninterrupted time (DNS propagation may add a few minutes)
| Tip: Start with the Azure-Managed Domain If you want to test ACS Email before configuring your custom domain, Azure provides a free managed subdomain (something like DoNotReply@xxxxxxxx.azurecomm.net). It has strict sending limits (5 emails/minute, 10 per hour), but it’s perfect for validating your setup before investing time in DNS configuration. You can always add your custom domain later. |
Step-by-Step Setup
Here’s the thing that confuses almost everyone the first time: ACS Email requires two separate Azure resources that work together. You need an Email Communication Service (which handles domains and email delivery) and a Communication Service (which provides the SMTP endpoint and connection strings). Think of it like this: the Email Communication Service is the engine, and the Communication Service is the steering wheel.
Let’s build both.
Stage 1: Create the Email Communication Service
- Log into the Azure Portal (portal.azure.com)
- Click “Create a resource” and search for Email Communication Services
- Select it from the results and click Create
- Choose your Subscription and Resource Group (I recommend creating a dedicated resource group like rg-acs-email-prod to keep things organized)
- Give it a descriptive name (e.g., acs-email-somedomainsomewhere-prod)
- Set the Data Location to United States (or your region)
- Click Review + Create, then Create. Deployment takes about 1-2 minutes
[Screenshot: Email Communication Service creation blade]
Stage 2: Create the Communication Service
This is the resource that ties everything together and provides your SMTP endpoint.
- Back in the Azure Portal, click “Create a resource” again
- Search for Communication Services (not Email Communication Services – this is a different resource)
- Select the same Resource Group you used in Stage 1
- Name it something clear like acs-somedomainsomewhere-prod – keep this name short because it becomes part of your SMTP username later
- Click Review + Create, then Create
| Important: Keep the Communication Service Name Short Your SMTP username format includes the Communication Service resource name. If you name it something long like “acs-email-communication-service-somedomainsomewhere-production-eastus” you’ll eat up character space that matters when configuring printers and copiers with 50-64 character username limits. Keep it concise – something like “acs-somedomainsomewhere” works perfectly. |
| Know Your Two Resources This is the most common source of confusion throughout the setup process. Remember: Provision Domains and MailFrom Addresses live on the Email Communication Service. SMTP Usernames, Domain Linking, and IAM Role Assignment live on the Communication Service. If you can’t find a setting, you’re probably looking at the wrong resource. |
Stage 3: Add and Verify Your Custom Domain
Now let’s add your domain to the Email Communication Service so you can send from your own email addresses instead of the generic Azure subdomain.
- Open your Email Communication Service resource
- Click Provision Domains in the left navigation
- Click Add Domain and select Custom Domain
- Enter your domain name (e.g., somedomainsomewhere.com)
- Azure will provide a TXT record for domain verification. Add this to your DNS provider
- Click Verify. DNS propagation typically takes 5-15 minutes, but can take up to 48 hours in rare cases
- Once verified, Azure will also prompt you to add SPF and DKIM records. Add these now – we’ll cover what they do in detail in Part 3
Pro tip: Consider using a subdomain like notify.somedomainsomewhere.com instead of your root domain. This isolates your ACS email reputation from your primary domain’s reputation. If something goes wrong with automated email, your main domain’s deliverability stays untouched.
[Screenshot: Provision Domains page showing verification status]
Stage 4: Configure MailFrom Sender Addresses
MailFrom addresses are the sender identities ACS uses when sending email. Every email must come from an authorized MailFrom address – this is how ACS enforces governance.
- In your Email Communication Service, click on your verified domain
- Click MailFrom Addresses
- By default you’ll have a DoNotReply address. Add any additional senders you need, such as alerts@somedomainsomewhere.com, scanner@somedomainsomewhere.com, or noreply@somedomainsomewhere.com
Keep your sender list intentional. Every address you add is an address that can send email through your ACS infrastructure. Fewer addresses means tighter control and easier auditing.
Stage 5: Connect Email Service to Communication Service
This is the step that links the two resources together.
- Open your Communication Service resource (not the Email Communication Service)
- In the left navigation under Email, click Domains
- Click Connect Domain
- Select your Subscription, Resource Group, Email Service, and verified domain, then click Connect
That’s it. Your email pipeline is now connected. But we still need to set up authentication before anything can actually send.
Stage 6: Set Up SMTP Authentication
This is the part where most guides lose people, so I’m going to be extra clear. ACS SMTP authentication uses Microsoft Entra ID (formerly Azure AD) app registrations. You create an app, give it permissions, generate a client secret, and then configure an SMTP Username that maps to that app.
Step 1: Register an Entra ID Application
- Go to the Microsoft Entra admin center (entra.microsoft.com)
- Navigate to Identity > Applications > App registrations
- Click New registration
- Name it something descriptive like acs-smtp-relay
- Set to Single tenant. No Redirect URI needed
- Click Register and note the Application (client) ID and Directory (tenant) ID
Step 2: Create a Client Secret
- In your app registration, go to Certificates & secrets
- Click New client secret, set an appropriate expiration (I recommend 12 months and adding a calendar reminder to rotate it)
- Copy the secret value immediately – you won’t be able to see it again once you navigate away. This is your SMTP password
Step 3: Assign the IAM Role
- Navigate to your Communication Service resource (not the Email Communication Service, not the Resource Group – this is important)
- Click Access control (IAM) > Add > Add role assignment
- Select the Communication and Email Service Owner role
- Under Members, choose User, group, or service principal, search for your app registration, select it, and click Review + assign
| Critical: Assign the Role Directly on the Communication Service Do not assign the role at the Resource Group or Subscription level and rely on inheritance. Multiple community reports confirm that IAM inheritance to the Communication Service resource either takes an unpredictable amount of time or doesn’t work at all. Always assign the role directly on the Communication Service resource itself. This is a known gotcha that will save you hours of troubleshooting. |
Step 4: Create an SMTP Username
- In your Communication Service resource, click SMTP Usernames in the left navigation
- Click +Add SMTP Username
- Select your Entra application from the dropdown
- For Username Type, select Email – this creates a username in the format username@yourdomain.com which works with all copiers and printers
- Enter a short username like acs-smtp or scanner-smtp
- Verify the status shows Ready to use
This custom SMTP Username feature is a game-changer. The legacy username format was ResourceName.ApplicationID.TenantID, which easily exceeds 80-100 characters. Most copiers and printers have a username field limit of 50-64 characters. The custom SMTP Username lets you use something like “scanner-smtp@somedomainsomewhere.com” instead, which fits on any device.
Your SMTP Settings at a Glance
| Setting | Value |
| SMTP Server | smtp.azurecomm.net |
| Port | 587 |
| Encryption | STARTTLS (Required) |
| Authentication | Username and Password |
| Username | Your custom SMTP Username (e.g., scanner-smtp@somedomainsomewhere.com) |
| Password | Entra app client secret value |
| From Address | Must match a configured MailFrom address |
Test It with PowerShell
Before touching any copiers or devices, let’s verify the setup works. PowerShell’s Send-MailMessage cmdlet is the quickest way to confirm.
Open a PowerShell terminal and run the following (replacing the placeholder values with your actual credentials):
| # Store credentials securely $Secret = ConvertTo-SecureString ‘<YourClientSecret>’ ` -AsPlainText -Force $Cred = New-Object PSCredential ‘<YourSMTPUsername>’, ` $Secret # Send test email Send-MailMessage ` -SmtpServer ‘smtp.azurecomm.net’ ` -Port 587 ` -UseSsl ` -Credential $Cred ` -From ‘scanner@somedomainsomewhere.com’ ` -To ‘you@somedomainsomewhere.com’ ` -Subject ‘ACS Email Test’ ` -Body ‘ACS Email is working!’ |
| Note on Send-MailMessage PowerShell displays a deprecation warning when you use this cmdlet. It still works and will continue to work – Microsoft deprecated it because it can’t guarantee TLS enforcement, but ACS requires STARTTLS on port 587 anyway, so the security concern doesn’t apply here. For a production-ready test tool with retry logic and troubleshooting output, check out the ACS Email Toolkit’s -TestEmailOnly mode in Part 5 of this series. |
If this works, you’ll get a test email in your inbox within seconds. If it doesn’t, jump to the Troubleshooting section below – the most common issues are username formatting and IAM permissions.
Real-World Copier Configuration
This is where the rubber meets the road. Here’s how to configure the most common enterprise copier brands to send scan-to-email through ACS.
The SMTP settings are identical across brands – what changes is where each manufacturer hides the configuration in their admin panel.
Common SMTP Settings for All Copiers
| Setting | Value |
| SMTP Server | smtp.azurecomm.net |
| Port | 587 |
| Authentication | SMTP-AUTH (username/password) |
| Encryption | STARTTLS or SSL/TLS |
| Username | Your custom SMTP Username |
| Password | Entra app client secret |
| From Address | Must match a configured MailFrom address (e.g., scanner@somedomainsomewhere.com) |
Sharp Copiers
Navigate to System Settings > Network Settings > Email Settings > SMTP Setup in the Sharp web admin panel. Enter the SMTP server, port, and credentials. Sharp copiers generally handle long usernames well but test to confirm. Set the Device Email Address to match your configured MailFrom address exactly.
Canon Copiers
Access the Remote UI, then go to Settings/Registration > TX Settings > E-Mail/I-Fax Settings > SMTP Server. Canon devices can be finicky with TLS settings – make sure you select STARTTLS rather than SSL for port 587. If your Canon model has a username character limit, the custom SMTP Username feature is critical here.
Ricoh Copiers
Open the Ricoh web interface, navigate to Device Management > Configuration > Email > SMTP. Ricoh copiers are generally straightforward with SMTP configuration. Enable SMTP Authentication and set the encryption method to STARTTLS. One Ricoh-specific note: some models require you to set the “SMTP Server Name” using the DNS name smtp.azurecomm.net – IP addresses are not accepted by ACS.
| Tip: Test with One Device First Configure a single copier as your pilot device. Verify it can send scan-to-email successfully before rolling out the configuration to your entire fleet. This catches any device-specific issues (username length limits, TLS compatibility, special character handling in passwords) before they become a fleet-wide problem. |
Troubleshooting Common Issues
After setting up ACS Email for multiple clients, I can tell you the same issues come up almost every time. Here are the most common problems and how to fix them.
Authentication Failures
This is the #1 issue, and it’s almost always the SMTP username. If you’re using the legacy format (ResourceName.AppID.TenantID), double-check that you’re using the Communication Service resource name – not the Email Communication Service name. These are two different resources and using the wrong one causes immediate authentication failure. Better yet, switch to the custom SMTP Username feature and avoid this ambiguity entirely.
Also verify that the client secret hasn’t expired and that you copied the secret value (not the secret ID). If you regenerated the SMTP Username, the old password is immediately revoked – even if you just created it seconds ago.
TLS Errors
ACS requires STARTTLS on port 587. If your device only supports SSL/TLS (not STARTTLS), you may need a firmware update or an intermediary relay. Also confirm the device is using the DNS hostname smtp.azurecomm.net – ACS does not accept connections via IP address.
Sender Authorization Errors
If you see a “MailFrom address not authorized” error, the From address in your email doesn’t match any configured MailFrom address in your Email Communication Service. The address must match exactly – including case. Check your MailFrom Addresses under your domain in the Email Communication Service.
IAM Permission Delays
If authentication fails immediately after assigning the IAM role, wait a few minutes. Azure RBAC propagation can take up to 10 minutes. If it still doesn’t work after 15 minutes, verify the role is assigned directly on the Communication Service resource and not inherited from the Resource Group or Subscription.
Best Practices
Use a dedicated Entra app per use case. Don’t share one app registration across copiers, monitoring scripts, and web applications. Create separate registrations so you can rotate secrets independently and track usage per system. If a copier is decommissioned, you revoke its specific app without affecting anything else.
Adopt a naming convention. Consistency matters as your ACS deployment grows. I recommend naming resources with a pattern like acs-[company]-[purpose]-[env] (e.g., acs-somedomainsomewhere-scanner-prod). For MailFrom addresses, use function-based names like scanner@, alerts@, noreply@ rather than device-specific names like ricoh-3rdfloor@.
Set secret expiration reminders. Client secrets expire. When they do, every device using that secret stops sending email. Set a calendar reminder 30 days before expiration, and document your rotation procedure so whoever handles it next year knows exactly what to update and where.
Monitor with Azure Insights. ACS provides an Insights dashboard in the Azure Portal that shows email analytics including delivery status, bounce rates, and blocked messages. Check this regularly – it’ll catch issues before users report them. You can also set up Azure Monitor alerts for failed sends.
Document everything. Keep a record of which devices and applications use which Entra app registration, which MailFrom address, and when the client secret expires. A simple spreadsheet or entry in your IT documentation system saves massive headaches during troubleshooting and audits.
The Bottom Line
That’s it. You just went from zero to a fully functional ACS Email setup with a verified domain, authenticated SMTP endpoint, and a tested configuration. The whole thing takes about 30 minutes (assuming DNS propagation cooperates).
No more Exchange dependency for system email. No more shared service accounts with passwords in config files. No more Monday morning scan-to-email fires. ACS Email gives your devices and applications a dedicated, secure, cloud-native email pipeline that just works.
Next time a copier vendor asks you for SMTP settings, you’ll hand them a server address, a short username, and a password. Done.
| Up Next in This Series In Part 3, we’ll dive deep into DNS configuration for ACS Email – SPF, DKIM, and DMARC. You’ll learn exactly what each record does, how to configure them for maximum deliverability, and how to avoid the common mistakes that land your emails in spam folders. If you set up ACS in this article, Part 3 ensures your emails actually get delivered. |
Need help setting up ACS Email for your organization? Contact Azure Innovators – we’ve deployed ACS Email for clients ranging from 5 copiers to enterprise-wide application messaging platforms.