Offloading CRM Messaging in GCC High with Azure Communication Services — A Relay Architecture

How a CRM system leveraged Azure Communication Services and Microsoft Graph to scale outbound messaging beyond traditional Exchange constraints while preserving compliance, encryption, and CUI protections.

The real problem: Exchange is not a bulk messaging engine

In many environments, Exchange is expected to handle far more than it was designed for. It excels at user-driven messaging but can become a bottleneck when a system-of-record CRM begins generating large volumes of event-driven communications.

In this case, a CRM platform was responsible for generating outbound communications based on transaction events, workflow state changes, customer activity, and operational notifications. The required delivery volume and speed exceeded what Exchange Online could reliably sustain when combined with compliance, auditing, and protection requirements.

The objective was not simply to send messages. The solution needed to:

Support high-volume CRM-generated messaging workloads
Handle burst traffic from workflow automation and transactional events
Maintain compliance controls for Controlled Unclassified Information (CUI)
Preserve Exchange Online as the authoritative compliance platform when required
Eliminate reliance on legacy SMTP authentication methods

The solution: a dual-path relay model

Rather than forcing all communications through a single transport, the architecture separated message delivery into two distinct paths based on classification and policy requirements.

High-speed path: Azure Communication Services (ACS) for non-CUI and high-volume communications that did not require Exchange compliance processing
Protected path: CRM → Microsoft Graph → Exchange Online with IRM, encryption, and compliance controls for CUI or regulated messaging

The CRM dynamically selected the appropriate delivery path using classification logic and organizational policy requirements.

Why Azure Communication Services?

Azure Communication Services acted as a scalable outbound relay for messages that did not require Exchange Online compliance controls, encryption enforcement, retention processing, or protected message handling.

API-driven, high-throughput messaging
Decoupled from mailbox limits and Exchange throttling controls
Better suited for system-generated communications
Reduced load on Exchange infrastructure
Support for burst-driven CRM workflow messaging

In effect, ACS became the bulk transport layer, while Exchange Online remained the compliance enforcement layer for protected communications.

Dynamic routing logic (the key to the design)

The most important component was not the transport itself. The critical capability was the decision engine that determined the correct route before a message was transmitted.


1. CRM event is triggered
2. Message payload is constructed
3. Classification check:
   - Is this CUI or regulated data?
   - Does this require IRM protection?
   - Are compliance controls required?
4. If YES:
   → Route through Microsoft Graph
   → Deliver through Exchange Online
   → Apply IRM / Encryption / Compliance controls
5. If NO:
   → Route to Azure Function relay
   → Send via Azure Communication Services
6. Log decision + delivery outcome

This ensured compliance requirements were never bypassed while allowing the platform to scale efficiently.

Compliance Guardrail: Message classification occurred before transport selection. Communications requiring compliance controls, encryption, retention, auditing, CUI protections, or IRM processing remained within Exchange Online delivery paths. Azure Communication Services was used only for communications that satisfied organizational policy requirements for alternate delivery methods.

Where Microsoft Graph fits

Because SMTP Authentication was not available within the target environment, the CRM system used Microsoft Graph API calls to submit message payloads for Exchange Online delivery.

Microsoft Graph therefore served two important functions within the architecture:

Identity and directory lookups through Microsoft Entra ID
Programmatic message submission into Exchange Online or the ACS Relay

The CRM leveraged Graph APIs to dynamically resolve recipient information, validate routing decisions, and submit protected communications into Exchange Online when compliance controls were required.

This approach eliminated dependency on legacy SMTP authentication while aligning with Microsoft's modern authentication model and API-driven messaging architecture.

In this implementation, Graph functioned both as an intelligence layer and as the Exchange message-submission mechanism used by the CRM application.

Compliance stays intact

A critical requirement was ensuring that Controlled Unclassified Information (CUI) never bypassed established protection mechanisms.

By maintaining Exchange Online as the processing platform for protected communications:

Sensitivity labels and encryption policies remained enforceable
IRM protections remained intact
Audit trails aligned with compliance obligations
Retention and investigation workflows remained available
The CRM could initiate protected communications without reimplementing Microsoft 365 compliance controls

The architecture avoided a common pitfall: attempting to recreate compliance and protection capabilities outside of Microsoft 365.

Operational lessons learned

Exchange throttling is not a bug — it is a design boundary
Not all messages belong in a mailbox system
Classification must happen before transport selection
Transport selection should be driven by data classification and policy, not performance requirements alone
Bulk messaging and compliant messaging are fundamentally different workloads
Relays should enforce decisions, not make assumptions
Modern API-driven delivery methods provide greater flexibility than legacy SMTP-based integrations

The takeaway

The successful outcome was not achieved by replacing Exchange Online. It was achieved by assigning the appropriate technology to the appropriate workload.

Azure Communication Services provided scalability and performance for approved high-volume communications. Microsoft Graph enabled secure, modern application integration. Exchange Online continued to provide compliance, encryption, auditing, and information protection for regulated communications.

The CRM orchestrated both paths through intelligent classification and routing decisions.

In regulated environments such as GCC High, successful architectures typically separate:

Transport from compliance enforcement
Performance requirements from protection requirements
System-generated messaging from user-driven messaging
Bulk communications from regulated communications

When those boundaries are clearly defined, organizations can improve scalability while maintaining the governance, auditability, and data protection controls that regulated environments demand.