Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Resolve what Azure means for this application
Microsoft Azure is a cloud platform, not one universal email-sending configuration. This guide covers Azure Communication Services Email and its custom-domain workflow. It does not configure a virtual machine's mail server, Exchange Online, a third-party service purchased through Azure or Azure DNS hosting alone. Establish the actual outbound dependency before changing authentication. Microsoft distinguishes Azure-managed sending domains from customer-owned custom domains in its email-domain overview.
Record the application, environment, Azure subscription, resource group, Email Communication Service resource and Communication Services resource that the application uses. Identify the intended From address and which component chooses it. Development and production resources can look similar while connecting different domains. Ask the application owner to trace a harmless notification from the triggering event to its outbound service call rather than inferring the sender from the application's hosting location.
An Azure-managed domain is preconfigured for authentication under the supplied azurecomm.net identity. That does not make it authentication for the organization's own From domain. Select the custom-domain path when branded customer-domain sending is the actual requirement. Preserve a baseline message and the application's current sender configuration so the team can distinguish a configuration improvement from an accidental identity change.
Verify ownership and collect the issued authentication records
Open the Email Communication Service resource's Provision Domains workflow, add the intended custom domain and verify its ownership using the issued TXT record. Ownership verification comes before sender-authentication configuration. Once the domain is Verified, use Configure to obtain the SPF TXT and DKIM CNAME records, publish them at the authoritative DNS provider, and check their verification state. Use the actual resource's values rather than reconstructing targets from documentation screenshots. Add a custom verified domain.
Give the DNS administrator a worksheet with the full requested owner name, type, exact value, current answer and change owner. Check whether the DNS panel expects a relative host name. Preserve unrelated TXT entries such as ownership tokens belonging to other services. Where an SPF policy already exists at the required owner, review how the new authorization fits into that policy instead of adding a second one or deleting existing senders.
Copy both issued DKIM and DKIM2 entries, and verify each target independently. Do not place a TXT key at a name where the service requests a CNAME. Conversely, never manufacture a CNAME target merely because a previous Azure deployment used a similar-looking pattern. The active domain resource is the source of account-specific configuration.
Connect the verified domain to the application resource
Domain authentication and application connectivity are separate stages. In the Communication Services resource, open Email, then Domains, and use Connect domain to select the correct verified domain through its subscription, resource group and email service. Microsoft requires the Communication Services and Email Communication Services resources to have matching geography for this connection. Verify the actual resource association before testing the application. Connect a verified email domain.
Do not copy a resource-update example into production without inspecting existing linked domains and other settings. A replacement list can omit dependencies that another application still uses. Review the current state, make the smallest approved change, and reread it afterward. The current connection guide supports up to 100 verified custom domains on one Communication Services resource, while the overview still describes switching a single domain. Follow the current connection workflow and confirm tenant capability; do not disconnect another application’s domain based on the older overview wording.
Record which configured sender address the application is authorized and expected to select. A successful domain connection does not prove that the deployed configuration changed from a test sender. Test each deployment slot or service that chooses its sender independently, and retain correlation identifiers without exposing credentials or connection strings in the article evidence.
Diagnose verification with DNS evidence
When a status does not become verified, compare the portal's requested record with a public DNS query at the exact owner. Check authoritative answers before treating a recursive cache as current. A record in an unused zone or a private DNS namespace cannot satisfy a public verification query. Microsoft provides separate troubleshooting checks for ownership, SPF and DKIM status; keep these failure categories distinct. Domain configuration troubleshooting.
The documented verification interval is an estimate, not a guarantee for every resolver. Save timestamps and previous TTLs, then retry verification after the relevant cache window rather than repeatedly editing correct records. If the public answer matches but service verification still fails, escalate with the resource identifier and sanitized query evidence. Microsoft’s troubleshooting guide specifically requires an SPF policy ending in -all and says ~all fails its verification. This is a product validation requirement, not a claim that SPF forbids softfail. If a shared owner currently uses ~all, inventory every legitimate sender and obtain the DNS/security owner’s approval before changing that ending; do not silently harden the entire domain just to clear a dashboard. Do not broaden domain authorization solely to make a dashboard indicator change color.
Trace the application to its received message
Fill this matrix for each production deployment or slot that selects its own sender. It is a blank test artifact, not tenant evidence. Record resource identifiers in controlled storage and never insert credentials or connection strings.
- Trace field: Application, environment and deployment/slot; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Triggered notification and operation/correlation ID; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Communication Services resource; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Email Communication Service resource; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Resource geography on both sides; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Connected domain and verification states; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Application-configured sender address; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Received From and Return-Path; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Receiver SPF domain and result; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Every DKIM d=, s= and result; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: DMARC mode, result and aligned passing path; Intended mapping: ___; Observed mapping or evidence reference: ___
- Trace field: Timestamp and restricted original-message reference; Intended mapping: ___; Observed mapping or evidence reference: ___
Use a harmless notification to a controlled external mailbox through the real application. Compare resource association first, then sender selection, then the receiving system's results. If the portal domain is verified but the application still selects its old test sender, fix the application mapping rather than republishing correct DNS. If the expected resources are not linked, investigate the connection and geography before debugging DKIM.
Illustrative mapping, not an observed deployment: a production domain is authenticated in one Email Communication Service resource, while a staging application calls a different Communication Services resource. The verified domain's status says nothing about the staging route until its resource connection and configured sender are traced. This is why the matrix records both resource identities instead of only the domain name.
For protocol acceptance, compare actual received identities rather than portal labels. SPF evaluates the envelope domain; DKIM identifies its signer through d= and s=. DMARC requires an aligned passing path under the applicable mode. SPF, DKIM and DMARC specifications.
Classify an incomplete row as ownership/authentication verification, resource association, application sender selection, or received-message alignment. API acceptance is a submission milestone, not an authentication verdict or inbox guarantee. Test bounce and reply handling separately when they are business requirements.
Preserve the deployment and publication gates
If the controlled test fails, pause the affected workflow or restore the previously approved sender configuration. Avoid deleting shared Azure resources as a troubleshooting shortcut. Remove records only after confirming that no other connected domain or application depends on them, and retain prior values for a controlled recovery.
This candidate establishes a first-party setup path for Azure Communication Services Email, but the broad catalogue label Microsoft Azure remains a scope decision for the editor. No authenticated tenant settings, authoritative customer DNS or live message were examined. Publication as a verified implementation remains on hold for explicit product-scope acceptance, tenant-specific values, before-and-after DNS evidence, a received-message identity record and human SME review.