Use the authoritative public Azure DNS zone, translate each full owner into a relative record-set name, and preserve the sender's exact TXT or CNAME format. Azure DNS publishes records; it does not generate your sending provider's DKIM configuration or activate its signer. Azure Communication Services Email and Microsoft 365 are separate sender workflows, not automatic features of a DNS zone.
This guide covers existing public DNS publishing, not zone migration, private DNS, mailbox setup or DNSSEC changes. No customer portal operation, DNS edit or received-message test was performed.
Establish authority and the permitted change
Record the tenant, subscription, resource group, zone, sender account and approved record packet before editing. Match public delegation to the nameservers of that particular zone. Identically named zones can exist in different Azure resource groups or subscriptions with different assigned servers. A listed zone is not proof of authority. Microsoft explains this distinction in its zones and records overview.
Public email verification needs public answers; a matching private-zone record is insufficient. Check child-zone and _domainkey delegations rather than assuming the parent contains the operative data. If another provider is authoritative, publish there instead of moving nameservers as a shortcut.
Use an already authorized account with permission for the affected records. DNS Zone Contributor applies to public DNS resources, and permissions can be scoped more narrowly. A ReadOnly lock can prevent a write even when the account otherwise has access. Ask the responsible administrator to resolve a permission or lock issue; do not grant broad subscription access or remove safeguards merely to follow this guide. See Microsoft's zone and record protection guidance.
Save existing values, TTLs and dependencies before changing anything. Keep MX, NS, A/AAAA routing, DNSSEC and unrelated TXT tokens untouched. If a sender packet requests a new return-path MX, destination address or delegation, compare it with the separately authorized routing plan. Possessing the packet does not authorize changing inbound delivery or delegating a namespace.
Prepare the complete owner and relative name
Write down the full owner, record type, complete supplied value, purpose and existing value. For a public zone example.com, these are illustrative translations, not account-issued selectors:
example.combecomes@._dmarc.example.combecomes_dmarc.SELECTOR._domainkey.example.combecomesSELECTOR._domainkey.bounce.example.combecomesbounce.SELECTOR._domainkey.mail.example.combecomesSELECTOR._domainkey.mail._dmarc.mail.example.combecomes_dmarc.mail.
If mail.example.com is separately delegated, select that authoritative zone: its apex is @, its selector is SELECTOR._domainkey, and its policy owner is _dmarc. In a delegated _domainkey.example.com zone, SELECTOR._domainkey.example.com becomes SELECTOR. Preserve shared NS delegations and do not create a shadow parent record as a substitute.
Append the zone suffix once on paper and compare the resulting full name with the issued owner. Do not paste a full owner into a field expecting a relative name and accidentally duplicate the suffix. Microsoft's record-name rules establish relative names and @ at the apex.
Add or edit the intended record set
In Azure portal, open DNS zones, select the verified public zone, then Recordsets. For an existing owner/type, use its edit icon, alter only the approved value and select Apply. Preserve every unrelated value in that set. A record set groups records with the same name and type; deleting the whole apex TXT set can remove several independent services. Empty record sets do not provide public answers. See managing record sets.
For a genuinely new set, use Record sets, then + Add. Supply the relative Name, required Type, approved TTL and its correct unit, and the complete data; select Add. Microsoft's portal quickstart documents these creation controls. Its example creates a test A record and later deletes a resource group: neither action belongs in this email-authentication task.
Reopen the affected set after saving and compare it with the worksheet. If concurrent administrators or automation manage the zone, coordinate the change. Automated updates should use a fresh read and appropriate Etag concurrency protection, not a blind overwrite. An Etag mismatch is a reason to reconcile changes, not force through a stale snapshot. Microsoft documents Etags.
Preserve SPF and TXT boundaries
Use TXT for SPF. Maintain one v=spf1 policy at the domain actually evaluated by SMTP MAIL FROM, or HELO where applicable, while retaining unrelated TXT records. Do not automatically authorize at the visible From domain. Reconcile all legitimate sending services before replacing a policy, preserving approved mechanisms and qualifiers.
The SPF limit is ten evaluated DNS-dependent terms, including nested evaluation, not simply ten visible includes. An all mechanism makes redirect ineffective. A -all result means SPF failure, not guaranteed message rejection by every recipient. These behaviors are specified in RFC 7208.
For long DKIM TXT data, enter the complete logical value as one record in the portal. Azure divides long strings into wire-format segments as needed; its REST API instead accepts the component strings separately. Separate strings within one TXT record are not separate TXT records. The documented combined TXT-set string allowance is 4,096 characters across the set, not an allowance for every value. See Azure TXT behavior.
Do not add decorative quotes or split a key into multiple record rows. Preserve the full public tagged value, including p= key data, without inserting spaces into the reconstructed key. Receiver concatenation of key strings is defined in RFC 6376 section 3.6.2.2. Never publish a private key. If a value exceeds a documented limit, stop and obtain supported guidance rather than truncating it.
Keep issued CNAMEs distinct from Azure resource aliases
When the sender supplies a CNAME, use that type and its exact full destination, not a TXT key invented from the hostname. At the owner, do not add competing TXT, A, AAAA, MX or another CNAME. An apex CNAME conflicts with the zone's existing records. Resolve ownership conflicts with the affected services rather than deleting shared data. See CNAME constraints.
For an ordinary sender-issued target, use a conventional CNAME, not the Azure Alias record set feature. Where offered, choose Alias record set No. Azure's special aliases can reference Azure resources or other zone record sets; they are not a request to turn every DKIM CNAME into an Azure resource linkage. Microsoft's alias overview describes the distinction.
Keep authentication records DNS-only, not HTTP-proxied or redirected through a website service. If another DNS layer performs flattening, assess per-record, whole-zone, apex and same-zone effects. When the sender requires a literal CNAME answer, turn off relevant per-record flattening when available and ensure applicable zone behavior retains it. No Azure-specific Flatten toggle is assumed here. If mandatory behavior cannot preserve the required answer, stop and agree on a supported configuration rather than globally disabling settings or deleting delegations.
Publish only the approved DMARC policy
Check the existing direct and applicable inherited policy. Preserve enforcement, alignment modes and authorized reporting destinations; never downgrade an established policy to p=none to make an unverified sender appear ready. Do not add a second DMARC policy.
Only when no direct or applicable inherited policy exists, the domain owner approves monitoring and someone will review reports, this illustrates a first policy:
Full owner: _dmarc.YOUR-DOMAIN.example
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-MAILBOX
Replace the mailbox placeholder with an actual approved address, not another mailto: URI. Map the owner to the correct zone using the rules above. Avoid obsolete pct rollout examples. Current RFC 9989 defines DMARC evaluation and alignment; a policy preference is not a guarantee of recipient handling.
A report destination in a different Organizational Domain from the policy domain requires the report-generating receiver's DNS authorization check. A destination within the same Organizational Domain is excepted, even when its hostname differs. Coordinate required authorization with the report operator and separately obtain owner approval for sharing report data. See RFC 9990 section 4.
Verify DNS, sender activation and actual mail separately
These are read-only test templates, not results. Substitute actual names and use the issued record type:
dig @AUTHORITATIVE-NS.example SELECTOR._domainkey.YOUR-DOMAIN.example TXT +noall +answer
dig @AUTHORITATIVE-NS.example SELECTOR._domainkey.YOUR-DOMAIN.example CNAME +noall +answer
dig @AUTHORITATIVE-NS.example SPF-OWNER.example TXT +noall +answer
dig @AUTHORITATIVE-NS.example _dmarc.YOUR-DOMAIN.example TXT +noall +answer
Check every assigned authoritative server, then recursive answers. Compare full owner, type, target or concatenated TXT value. Distinguish a missing record, stale cache, wrong zone, duplicate policy and broken target. Respect the previous TTL rather than treating every disagreement as a reason to edit again.
Complete the sending provider's verification and signing-activation workflow separately. Then send controlled, non-sensitive mail through each intended route to valid authorized test recipients. Use Authentication-Results produced inside the receiving service's known processing boundary, with its documented handling of externally supplied results confirmed through documentation or its administrator. Header position and matching authserv-id text alone do not establish trust. Ignore forged or untrusted results as described in RFC 8601.
For newly configured branded DKIM, require the intended signature to pass and align with the intended visible From under the active policy, plus trusted dmarc=pass. SPF-only DMARC success does not prove DKIM works. A provider-rewritten From does not authenticate the intended brand.
For example, a passing d=mail.example.com signature with From sender@example.com aligns under relaxed mode when both share Organizational Domain example.com, but not strict mode. A passing d=example.com matches that From domain in both modes. Evaluate the actual envelope identity separately under aspf. These are illustrative identities, not observed results. EmailAuth's raw-versus-aligned DKIM guide explains the distinction.
Troubleshooting and safe recovery
- Saved but absent publicly: confirm public versus private zone, subscription, resource group and assigned nameservers. Do not migrate delegation as a shortcut.
- Key visible but signing fails: verify sender activation, selector and exact key before altering policy.
- SPF permerror: inspect duplicates, syntax and the evaluated DNS-term budget. Temperror calls for temporary-DNS diagnosis; fail means authorization did not pass. Repair SPF defects even if DKIM currently makes DMARC pass.
- CNAME conflict: identify existing dependencies; do not delete the owner or turn the key into another type to bypass validation.
- Write denied: have the authorized administrator review permissions and locks, without unapproved broad access changes.
Restore only the reviewed values implicated in the fault, retaining unrelated records and previous TTL information. Keep old selectors until their senders and in-flight messages no longer depend on them. Never delete the zone or resource group as rollback. Recheck public answers and controlled message authentication after recovery. Authentication does not guarantee inbox placement.