Azure Communication Services (ACS) can be used to send high volume outbound email to Internet recipients, represents an important shift in Microsoft’s messaging architecture. As organizations modernised their cloud communications to Exchange Online (EXO) many of them just kept doing what they were doing with Exchange on-premises, i.e. using that as a bulk mailer to send out high volume email internally and also externally. In ye olden days of cloud. Exchange Online Protection (EOP) and EXO have always had limits, what changed over time is the enforcement of those limits. In the COVID days the enforement ramped up as noted here. Overtime the documented limits were gradually enforced. That continued to evolve with the addition of Tenant-level outbound email limits (TERRL) and Microsoft External Recipient Rate Limit (MERRL) enforcement. The latter applies to new/trial tenants since it is trivial to spin up a tenant and send out junk. That's why tenant admins had to take action to block rubbish from various onmicrosoft.com domains.
All of that to say that EXO is focused on serving as a corporate email and collaboration platform, not as a bulk or application email delivery service. For scenarios such as notifications, marketing messages, or automated system alerts, ACS Email provides a scalable and policy-compliant alternative designed specifically for programmatic outbound delivery.
Azure Communication Server - Caveats
Please review the ACS - Email notes here. A ramp-up period is required, and you should also plan to use your domain(s) rather than the vanilla Microsoft default domain. In the example below f88aceb4-3ce0-42e8-95dc-fa0fd1026b90.azurecomm.net is not a friendly name, and your marketing team would freak out (rightly so) if they saw that being used to send email to customers. That's why the sales.tailspintoys.ca domain was added. Also, higher quotas are only available for custom domains, not the Azure managed ones.
Ensure that you have planned and implemented Sender Authentication for this domain - SPF, DKIM and also DMARC. For DKIM, the process is similar to EOP but slightly different - see this post Azure Communication Service – Enable DKIM Signing.
Diagnostic information and logging is available, but realistically this means using Azure Monitor to get the required information into a Log Analytics Workspace so it can be retained & search etc. Note that a diagnostic setting was enabled here:
This is an area that you must monitor. Before you can actually get a rate increase, the email flow must be solid. If there are a high number of bounces, your rate increase request will be blocked. In order to understand your delivery stats, log this data and analyse it. Fix issues as they emerge and stay on top of the delivery efficiency. This is explicitly stated in the docs:
To enable a high email quota, your email failure rate must be less than one percent (1%). If your failure rate is high, you must resolve the issues before requesting a quota increase. Customers are expected to actively monitor their failure rates.
ACS is designed as a sending solution. It does not receive, so plan how you will manage this. You could add an address with a mailbox in EXO or state this is a DoNotReply sender.
Also - how will you comply with various SPAM legislation? How will you manage the supression list?
Since ACS does not receive email, that means we do not need to create a MX record for the domains added there?
Consultant's answer #1 "It Depends"
ACS MX Record Required
While everything will be sent just fine, some email solutions perform a rudimentary check to see if there is a MX for the sending email domain. Not all do this, there are a handful, but this is an easy thing to fix. Just create the MX record and move on - no need to fight this and it's also not something you have direct influence over. You can't just call up a cloud email provider and make them change how they do things.
Just create a dummy MX record. In this case the A record does not even resolve, and yet that is enough to make this issue go away.
The systems that require a MX typically have the logic that if a domain doesn’t have a MX record, that means:
- The domain is not configured to receive mail
- The domain is not intended for email usage
If we want to be really pedantic, a MX record is not required for a domain to receive email. If we look in the latest version of the SMTP spec (RFC 5321 (Simple Mail Transfer Protocol)) the authoritative specification is RFC 5321, section 5.1 – Locating the Target Host which says:
"If an empty list of MX records is returned, the address is treated as if it contained a single MX record with a preference of 0, pointing to that host."
That means if no MX record exists,
-
The sending MTA should fall back to the domain’s A (IPv4) or AAAA (IPv6) record
-
The message will be delivered directly to the IP resolved from that record
In reality, there are almost zero systems that want to receive email and have NOT configured a MX record. But that's a non-zero number.
Bootnote
As a final point, you may see issues where the SPAM appliance checks the reverse DNS configuration for this sending entity. If this is an issue ensure your reverse DNS matches your sending domain: You might need to contact Azure support to configure the reverse DNS settings correctly. The reverse DNS should point to the same domain as your sending domain.
Cheers,
Rhoderick
