Microsoft Azure SPF, DKIM and DMARC setup, step by step

New Email resources can currently onboard workloads, subject to change; Microsoft recommends migrating existing workloads rather than onboarding new solutions. Use this guide to maintain authentication during that transition, not as an unqualified recommendation for a new platform. Microsoft retirement guidance

To authenticate your own domain in Azure Communication Services Email, first verify ownership in an Email Communication Services resource, then publish its SPF TXT record and both DKIM CNAME records. Confirm Domain, SPF, DKIM and DKIM2 verification, connect the domain to your application's Communication Services resource, and inspect a delivered message. DNS verification alone does not connect the application or prove DMARC alignment. Microsoft custom-domain setup, resource connection

This is the sending-service guide for ACS Email custom domains. It is not a universal “Azure SPF record”: Azure DNS hosts records, Microsoft 365 sends mailbox email, and an Azure-hosted application might use SendGrid or another transport. Authenticate the service that actually sends the message. Azure-managed azurecomm.net domains are a separate option with provider-configured authentication. Domain types

If your task is publishing records in a hosted DNS zone rather than configuring the sender, use the separate Azure DNS publishing guide.

Understand the two Azure resources

The Email Communication Services resource holds the domain and sender-authentication configuration. The Communication Services resource is the application-facing resource to which that verified domain is connected. Writing DNS records for the first does not automatically configure the second. Microsoft's preparation guide also distinguishes the envelope sender, or P1 MAIL FROM identity, from the visible P2 From address. Resource preparation

Before starting, collect:

• An active Azure subscription and administrative access sufficient to manage the relevant resources.
• The intended Email Communication Services resource and Communication Services resource, including subscription, resource group and data location.
• A domain or subdomain your organization controls, plus access to its authoritative public DNS zone.
• The application's real sending route and intended sender address.
• An export of existing SPF, DKIM and DMARC records, their owners and TTLs.
• A controlled external mailbox for a later authorized test, and an owner for reviewing the results.

Choose a domain boundary deliberately. A dedicated application subdomain may simplify authentication ownership, but it still needs sender approval and a DMARC policy assessment. Do not silently move an existing application's From address to a new domain just to make verification easier.

1. Add and verify ownership of the custom domain

In the Email Communication Services resource, open Provision Domains, choose Add domain → Custom domain, enter and confirm the domain, then add it. Open Verify Domain or resume through Configure. Copy the exact ownership TXT name and value into the appropriate public DNS zone, then continue the verification flow. Microsoft domain verification

An ownership TXT token is not an SPF authorization or a DKIM key. Keep those purposes separate when giving instructions to your DNS administrator. Preserve unrelated TXT records at the same owner; multiple ordinary TXT records are allowed, while multiple SPF policies are not.

Check the final hostname after saving. If your sender is a subdomain but you edit the parent zone, the relative record name must include the missing subdomain labels. If you edit a delegated zone for the sender domain itself, the relative name is different. Microsoft shows several zone-depth examples for this reason. Do not copy a tutorial's example domain into your own DNS.

Proceed only once ownership is Verified. Microsoft's guide estimates 15–30 minutes for DNS changes, but cached answers, negative caching, delegation mistakes and DNS-host behavior can take longer. Repeated clicking cannot repair a record published in the wrong zone.

2. Publish SPF with the required ending

Open the verified domain's sender-authentication configuration. Microsoft documents this ACS Email SPF pattern:

v=spf1 include:spf.protection.outlook.com -all

Use the owner and current value shown for your actual domain. ACS Email verification requires -all; Microsoft's troubleshooting guide says ~all fails validation. Do not adopt a softfail example from a generic Microsoft or third-party article for this workflow. Microsoft SPF verification requirements

If that owner already has an SPF policy, merge only missing authorizations into the existing policy. A domain already authorizing spf.protection.outlook.com does not need that same include twice. Preserve all other legitimate sending services and review the impact before changing the policy's final mechanism to -all. If the existing inventory is incomplete, resolve it with the domain administrator before proceeding. Do not publish a second policy to satisfy Azure while leaving the first unchanged.

SPF applies to the envelope MAIL FROM domain, not automatically to the address readers see. Check the receiver's actual smtp.mailfrom identity later; the shared include name does not prove which Microsoft product sent the message or whether it aligned. Keep one SPF policy per owner and no more than 10 evaluated DNS-query-causing terms, including nested includes and redirects. A list of fewer than ten providers can still exceed that limit. SPF standard

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

3. Publish both DKIM records, not the same one twice

Copy the two separate CNAME owner/target pairs shown for DKIM and DKIM2. Keep a worksheet that pairs each owner with its corresponding target:

The official examples use Azure Communication Services selector names, but your portal output is the implementation reference. Do not derive targets from a Microsoft 365 tenant, repeat the first selector as the second record, or paste another organization's key. CNAME publication delegates the public-key lookup; you do not upload a private key into DNS. Microsoft SPF and DKIM record examples

Each CNAME owner must be free of conflicting DNS data. If an owner already serves another purpose, stop and reconcile ownership rather than deleting it blindly. For DNS services with proxying, publish authentication aliases as ordinary DNS records, not web-proxied endpoints. Verify that the final owners resolve to the exact intended targets.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Return to the Azure configuration, complete Next/Done, and check the independent statuses. Require Domain, SPF, DKIM and DKIM2 to verify. A green Domain status establishes ownership only; it does not excuse a failing second key. Microsoft domain troubleshooting

4. Connect the verified domain to the application resource

In the Communication Services resource, open Email → Domains → Connect domain. Filter by the correct subscription, resource group and Email Service, select the fully verified domain, and connect it. The resources' data locations must be in the same geography. A verified domain missing from this picker can therefore be a resource-selection or geography problem, not a DNS failure. Microsoft connection procedure

Confirm the application uses this Communication Services resource and a sender address configured under the connected domain. Do not assume the application's existing endpoint or credentials point to the resource you just inspected. Keep credentials out of DNS worksheets and support screenshots. Verification and connection are prerequisites, not evidence that a real application has sent correctly.

5. Validate DNS, submission and receiver results

Replace placeholders with actual hostnames. These commands query records; they do not change anything:

dig +short TXT YOUR_CUSTOM_DOMAIN
dig +short CNAME EXACT_FIRST_DKIM_OWNER
dig +short CNAME EXACT_SECOND_DKIM_OWNER
dig +short TXT _dmarc.YOUR_VISIBLE_FROM_DOMAIN

Expected observations are one valid SPF policy at the correct owner, both CNAMEs matching the portal, and the intended DMARC policy where applicable. When a result disagrees with Azure, compare the authoritative nameserver with a public resolver and check the zone delegation. Do not rely solely on the DNS dashboard's saved-record display.

Then trigger an authorized, representative email through the actual application's ACS Email route. Record the resource, domain, sender, timestamp and application operation. Application acceptance or a successful API submission is not the receiver's authentication verdict. Microsoft's resource preparation workflow separately calls for verifying delivery status. Microsoft application responsibilities

At the controlled recipient, inspect the complete original message and the trusted receiver's Authentication-Results:

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

• Compare the visible From domain with smtp.mailfrom for SPF.
• Find the customer-domain DKIM signature and record its d= signing domain and s= selector.
• Require the expected dkim=pass; identify which configured selector was used.
• Read the dmarc result and establish which passing identity aligned.

One aligned passing mechanism is enough for DMARC, but a pass on a provider domain alone is not. Retest every distinct application route rather than generalizing from one successful development message. DMARC alignment, RFC 9989

Complete this branded-DKIM setup only when the intended provider signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. DMARC success through SPF alone does not establish that this DKIM deployment works; neither does an unnoticed provider-domain From rewrite. Diagnose SPF independently at the actual smtp.mailfrom: fail or softfail calls for checking sender authorization, temperror indicates a transient evaluation failure such as DNS availability, and permerror calls for checking invalid syntax, duplicate policies and lookup limits. Investigate these even if aligned DKIM supplies DMARC pass; a passing but unaligned provider envelope is a different outcome. DMARC alignment, SPF result meanings.

DMARC policy and reporting

Preserve any existing policy. If none exists, plan a single DMARC TXT policy at the applicable _dmarc owner and arrange monitoring before enforcement. A first deployment may use p=none; it does not protect by requesting rejection and must not replace an established stricter policy simply because a new ACS sender is being added.

Relaxed alignment compares organizational domains. Strict aspf=s or adkim=s requires the corresponding authenticated domain to match the visible From domain exactly. Check that relationship on real mail before changing alignment modes. Under the current RFC 9989 standard, pct is obsolete; do not plan enforcement around percentage sampling.

Use only an authorized rua destination and complete any external-report authorization it needs. Confirm reports arrive and cover other legitimate senders before tightening policy. Do not add failure-reporting ruf by rote: it can disclose message-related information and needs a separate privacy review. Aggregate reporting, RFC 9990, failure reporting, RFC 9991

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Publish a first policy only after checking inheritance

First query the exact visible From domain's _dmarc name and check whether an organizational-domain policy already applies to this subdomain. An absent child record does not mean there is no policy. Do not create a child p=none record that overrides inherited enforcement without an explicitly reviewed policy change.

Only when no direct or applicable inherited policy exists and the domain owner approves first-time monitoring, provision a reporting mailbox or reporting service your organization authorizes. Obtain its actual rua address and, for an external destination, complete the destination's authorization described in RFC 9990 section 4. Then publish one TXT record with this structural template, substituting every uppercase placeholder:

Full owner: _dmarc.YOUR_EXACT_FROM_DOMAIN
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:YOUR_AUTHORIZED_REPORT_ADDRESS

Use literal semicolons, not escaped backslashes; do not publish the placeholders. In the exact sender-domain DNS zone the relative owner is _dmarc; in a parent zone include the sender's subdomain labels after _dmarc. Preserve any existing DMARC record instead of creating a second one. Query the final full owner, check the effective policy, and confirm aggregate reports arrive before planning enforcement.

For the approved first policy at From example.com, full TXT owner _dmarc.example.com maps to _dmarc in that zone. For From news.example.com, full owner _dmarc.news.example.com maps to _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve any existing direct or inherited policy; this mapping does not authorize a child monitoring override.

Troubleshooting

Documentation and verification limits

Source dates are not implementation-test dates. The current connection procedure governs resource connection rather than older conceptual wording about a single domain.

No account configuration, customer DNS change, test submission or delivered-message inspection was performed. Before production rollout, complete the account, public-DNS and message tests above. Authentication does not guarantee inbox placement.