Microsoft Azure Communication Services:

Challenges, Solutions, and Best Practices
Introduction
Email remains one of the most widely used communication channels across businesses, enterprises, and service providers. While it is simple to use on the surface, the underlying configurations and authentication mechanisms are highly complex. Misconfigurations in email domains often lead to issues such as delivery failures, security vulnerabilities, or worse—exposure to spoofing and phishing attacks.

Microsoft Azure Communication Services (ACS) provides organizations with an integrated platform to send email, SMS, voice, and other communication services at scale. One of the critical aspects of using ACS for email is setting up a custom domain so that emails appear professional (e.g., from support@companyname.com) instead of generic service domains.

However, configuring a custom domain in ACS for email delivery requires a precise DNS setup. This includes implementing authentication protocols such as SPF, DKIM, and DMARC to ensure mail deliverability and protect against spoofing.

In this report, we will walk through the challenges encountered during the setup of an Azure Communication Service custom domain for email, how these challenges were resolved, and finally, provide a step-by-step solution guide. We will also highlight best practices for long-term reliability and security.

Why Custom Domains Matter

When organizations rely on Azure Communication Services for sending email, using a custom domain has several advantages:

1. Professional Branding – Emails appear to come from yourcompany.com rather than a generic Azure domain.

2. Improved Deliverability – Emails sent with proper DNS authentication (SPF, DKIM, DMARC) are less likely to be flagged as spam.

3. Security – Reduces the risk of spoofing and impersonation attacks targeting your domain.

4. Compliance – Many industries require authenticated custom domains for regulatory compliance.

Initial Setup: The Mistake of Using the Main Domain

The initial setup of the Azure Communication Service custom email domain was configured using the main domain (e.g., companyname.com). While this is technically possible, it is considered bad practice.

Why Using the Main Domain is Risky

• DNS Record Conflicts: The main domain is often tied to multiple services (website hosting, Office 365 email, APIs, etc.). Adding ACS email DNS entries may conflict with existing records.

• Reputation Risk: If ACS sends bulk email and one campaign is flagged as spam, the reputation of the main domain (companyname.com) could be negatively affected across all services.

• Limited Flexibility: Subdomains allow more granular control and isolation of services. For example, transactional emails could come from notify.companyname.com, while marketing emails could come from promo.companyname.com.

The Correct Approach: Subdomain

To avoid these issues, the setup was corrected by moving from the main domain to a dedicated subdomain such as:

• abc.companyname.com

• mail.companyname.com

• notify.companyname.com

This approach isolates email services, prevents conflicts, and protects the primary domain’s reputation.

Authentication Protocols in Focus

When setting up email authentication for Azure Communication Service, three main protocols need to be considered:

1. SPF (Sender Policy Framework)

SPF ensures that only authorized mail servers can send emails on behalf of your domain. It works by checking the SPF DNS TXT record during email delivery.

In our case, the SPF record was configured correctly and the status showed:

SPF Status: Passed

This confirmed that the subdomain was authorized to send mail via Azure Communication Service.

2. DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to each email, allowing the recipient’s server to verify that the message was not altered in transit. It requires publishing a DKIM public key in the domain’s DNS records.

In our case:

DKIM Status: Not Configured

3. DKIM2 (Second DKIM Selector)

Some providers, including Microsoft, require a second DKIM selector (selector2) as a backup or for rolling key changes. This ensures continuous authentication even if the first DKIM key is rotated.

In our case:

DKIM2 Status: Not Configured

4. DMARC (Recommended)

While not explicitly shown in the challenge report, DMARC is the next layer of protection. It works alongside SPF and DKIM, allowing domain owners to specify how mail servers should handle emails that fail authentication (reject, quarantine, or allow).

---

Challenges Encountered

During the setup process, the following challenges were observed:

1. Main Domain Misuse – Initially configured on the main domain, which introduced potential risks and conflicts.

2. SPF Propagation Issues – SPF passed only after updating the DNS records with the correct subdomain entry.

3. DKIM and DKIM2 Missing – Without DKIM signatures, emails may pass SPF but still be flagged as suspicious.

4. Testing and Verification Delays – DNS changes often take hours to propagate globally, making troubleshooting slower.

Solution: Step-by-Step Guide

Here is the complete step-by-step solution to properly configure a custom domain with subdomain in Azure Communication Service for email, including SPF, DKIM, and DKIM2.

Step 1: Prepare Your Subdomain

1. Choose a dedicated subdomain for email (e.g., abc.companyname.com).

2. In Azure Communication Service, add this subdomain under Custom Domains for Email.

3. Azure will generate the required DNS records for verification.

Step 2: Configure SPF Record

1. Log in to your DNS provider (e.g., GoDaddy, Cloudflare, Azure DNS).

2. Create or update the SPF TXT record for the subdomain. Example:

   Name: abc.companyname.com
   Type: TXT
   Value: v=spf1 include:spf.protection.outlook.com include:spf.acs.azure.com -all
   TTL: 3600

3. Wait for DNS propagation (usually 30 minutes to a few hours).

4. Test SPF configuration using tools like:

   • MXToolbox (https://mxtoolbox.com/spf.aspx)

   • Microsoft Remote Connectivity Analyzer

Once done, SPF should show Passed.

Step 3: Configure DKIM Record

1. In Azure, locate the DKIM keys generated for your subdomain. They will look like:

   • selector1._domainkey.abc.companyname.com

   • selector2._domainkey.abc.companyname.com

2. Add CNAME records in your DNS provider:

   Name: selector1._domainkey.abc.companyname.com
   Type: CNAME
   Value: selector1-abc-companyname-com._domainkey.<region>.azurecomm.net
   TTL: 3600

   Name: selector2._domainkey.abc.companyname.com
   Type: CNAME
   Value: selector2-abc-companyname-com._domainkey.<region>.azurecomm.net
   TTL: 3600

3. Save changes and wait for propagation.

4. Enable DKIM in Azure Communication Service portal for the subdomain.

Once complete, both DKIM and DKIM2 should show as Configured.

Step 4: (Optional but Recommended) Configure DMARC

1. Create a new TXT record in DNS:

   Name: _dmarc.abc.companyname.com
   Type: TXT
   Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@companyname.com; ruf=mailto:dmarc-failures@companyname.com; sp=quarantine; aspf=s
   TTL: 3600

2. Adjust the policy (p=) as needed:

   • none → Monitor only

   • quarantine → Send suspicious emails to spam

   • reject → Block suspicious emails completely

With DMARC in place, you gain full visibility into authentication failures.

Step 5: Verify Configuration

• Use MXToolbox DKIM Lookup to verify DKIM keys.

• Use nslookup or dig commands to check DNS entries.

• Send test emails to Gmail, Outlook, and Yahoo to confirm inbox placement.

Step 6: Monitor and Maintain

• Regularly review SPF and DKIM logs.

• Rotate DKIM keys at least once a year.

• Update SPF records if you add/remove mail services.

• Monitor DMARC reports for spoofing attempts.

Best Practices

1. Always Use Subdomains – Never risk your main domain reputation.

2. Keep SPF Records Clean – Avoid “too many lookups” errors (max 10).

3. Rotate DKIM Keys – Rotate every 6–12 months.

4. Start with DMARC “none” – Gradually move to “reject” after monitoring.

5. Test Before Production – Use sandbox/test accounts before live rollout.

Conclusion

Configuring Azure Communication Service with a custom subdomain for email is crucial for deliverability, security, and brand reputation. While the initial setup mistakenly used the main domain, moving to a subdomain (abc.companyname.com) solved multiple risks.

The solution required:

• Adding SPF records ( Passed).

• Configuring DKIM and DKIM2 records ( Initially missing, fixed via DNS CNAMEs).

• Adding DMARC for long-term protection.

By following the step-by-step guide above, organizations can ensure that their Azure-hosted email is properly authenticated, trusted by recipients, and safeguarded against spoofing.

Ultimately, good email hygiene with SPF, DKIM, and DMARC not only prevents fraud but also ensures your emails reliably reach the inbox—protecting your brand and your customers.