Microsoft Dynamics 365 SPF, DKIM and DMARC setup, step by step

On this page: Scope: this is Customer Insights – Journeys, not all Dynamics mail · Use the domain-authentication wizard · Publish the DNS records without damaging other services · Understand the SPF owner and the optional compatibility change · Apply DMARC to the visible From identity · Verify the public records · Test the actual journey and business unit · Troubleshooting and frequently asked questions · Completion criteria and evidence boundary

Authenticate the exact From domain in Customer Insights – Journeys, publish the wizard's ownership TXT, two DKIM CNAMEs and Envelope-From CNAME, then select Verify. The Envelope-From record supports SPF and return-path alignment. Do not substitute Microsoft 365 DKIM targets or a generic Dynamics SPF include. Microsoft domain-authentication guide.

Scope: this is Customer Insights – Journeys, not all Dynamics mail

This article covers the Customer Insights – Journeys domain-authentication workflow. A Dynamics 365 Sales mailbox, Exchange Online transport or a third-party marketing extension needs its own route-specific configuration. A familiar Microsoft logo is not enough to identify the sending service.

Before changing DNS, establish which environment, business unit and actual journey sends the message. Record its intended From address and inspect an existing message if available. Do not use the DNS settings of a connected mailbox as a shortcut for the journey service. Conversely, these marketing records should not replace authentication for staff email.

Have an authorized application administrator and the DNS owner coordinate the change. Save current records and identify any existing CNAMEs before publishing. A domain with several mail platforms needs an inventory, not a replacement SPF policy copied from a guide.

Use the domain-authentication wizard

Open Settings → Email marketing → Domain authentication → New and choose email sending. Copy and publish the ownership TXT, both DKIM CNAME rows and Envelope-From CNAME. Review the records and select Verify; expect green checks and Confirmed.

With modernized business units and scoping enabled, Settings → Domains → New offers business-unit selection and Enable across organizations. Choose the intended scope, not blanket access by default. The pre-authenticated dyn365mktg.com instance domain is for testing, not production branding. If an existing CNAME prevents ownership TXT at the domain, Microsoft documents the alternative dynmktown.<domain> owner. Use the generated verification value. Current wizard and scope options.

Use the wizard's actual records, never a tenant value from a screenshot:

Ownership TXT: <issued-owner> -> <issued-verification-value>
DKIM CNAME 1: <issued-owner-1> -> <issued-target-1>
DKIM CNAME 2: <issued-owner-2> -> <issued-target-2>
Envelope-From CNAME: <issued-envelope-owner> -> <issued-envelope-target>

This is a worksheet format, not deployable zone-file syntax. Copy the values into the matching DNS fields. A CNAME target is a hostname, not a URL: do not prefix it with https://, append a path or convert it into a TXT value. Keep an exact copy for comparison after the DNS administrator has saved it.

Publish the DNS records without damaging other services

Determine whether the DNS console expects the complete owner name or a name relative to the zone. For a sending subdomain, the subdomain belongs in the final owner. Microsoft specifically warns that DKIM's host portion must be combined with the full sending domain, and that Envelope-From should be copied directly from the product. Its troubleshooting guide distinguishes TXT ownership checks from CNAME DKIM/envelope checks. Microsoft troubleshooting checklist.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

A CNAME cannot coexist with ordinary TXT, MX or A data at the same owner. If a generated owner already serves another application, stop and identify the conflict; do not delete it to make the wizard pass. The alternate ownership owner is a specific ownership-verification option, not permission to move DKIM or envelope records to arbitrary names. DNS alias constraints.

For authentication CNAMEs, use DNS-only, not a web proxy, and disable CNAME flattening at those owners. Otherwise the public answer may hide the alias the verifier expects. Check the published CNAME response after changing these options. Cloudflare CNAME verification troubleshooting.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Leave Microsoft-managed public-key targets to Microsoft. You publish aliases, not a private signing key and not your own replacement key. Preserve both DKIM rows even if a sampled message currently uses only one selector. Record each selector and target so a later change can be checked against the environment that issued it.

The two layers have different evidence: a CNAME lookup confirms your alias exists; a TXT lookup following that alias checks whether the public key can be resolved. A record visible in the DNS provider's dashboard may still be unavailable from the public authoritative service. DKIM lookup model.

Understand the SPF owner and the optional compatibility change

The wizard is Microsoft's standards-based setup. Its optional From-domain SPF compatibility step uses the sending domain obtained from your own Envelope-From registration, not a universal include copied from another customer. It addresses receivers that check visible From incorrectly. Microsoft SPF note.

Under SPF, authorization is evaluated for the SMTP MAIL FROM domain, normally reflected in Return-Path, not the visible From. Adding a policy to the root does not automatically authorize a subdomain. If an additional SPF edit is justified for your route, preserve the existing legitimate mechanisms and terminal qualifier in a single v=spf1 record at that owner. Include targets must be current and intentional.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

The ten-term lookup limit includes nested lookup-causing mechanisms and modifiers along the evaluated path. It is not simply a count of visible include: strings. A limit error is not repaired by adding another SPF record. Never use bare all or +all as a workaround, and do not flatten service IPs into a static list without an ongoing maintenance plan. SPF standard.

A Microsoft 365 spf.protection.outlook.com include may legitimately exist for employee email. Leave it in place when that service is still authorized, but do not mistake it for proof that Customer Insights – Journeys authentication is complete.

For that separate employee-mail route, use the Microsoft 365 authentication guide; its tenant signing controls do not replace Customer Insights – Journeys authentication.

Apply DMARC to the visible From identity

DMARC requires a passing aligned DKIM or SPF identifier. Relaxed alignment compares organizational domains; strict alignment requires exact domain matches. An envelope subdomain sharing your organizational domain can align in relaxed mode but may not satisfy strict SPF alignment. Check the message and current policy rather than assuming that the wizard's success covers every policy choice.

Preserve an existing DMARC policy, including a parent policy that applies to your sending subdomain. If no applicable policy exists and monitoring is the appropriate first step, the following is a placeholder pattern:

Owner: _dmarc.<exact-from-domain>
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:<approved-report-mailbox>

Replace placeholders before use. Do not create competing DMARC records or downgrade quarantine/reject to make onboarding easier. RFC 9989 removed pct, so do not plan enforcement as a percentage slider. Current DMARC specification.

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Review aggregate reports across all legitimate sources. An external report consumer may need to authorize delivery from your domain; follow its current instructions. Aggregate reporting standard. Failure reports can expose message headers and content, so do not add ruf without privacy review and a specific diagnostic need. Failure reporting standard.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify the public records

Use actual full owner names from your worksheet. These commands are examples to run during an authorized implementation, not checks already performed:

dig +short TXT '<ownership-owner>'
dig +short CNAME '<dkim-owner-1>'
dig +short CNAME '<dkim-owner-2>'
dig +short TXT '<dkim-owner-1>'
dig +short CNAME '<envelope-from-owner>'
dig +short TXT '<actual-mail-from-domain>'
dig +short TXT '_dmarc.<from-domain>'
dig +short NS '<dns-zone>'
dig @<authoritative-nameserver> CNAME '<dkim-owner-1>'

Compare each answer to the issued value. Query both DKIM owners, not just the first. For CNAME records, expect the exact intended hostname target; recursive TXT resolution may display an alias followed by the key. For SPF, query the actual envelope domain and inspect the resulting policy rather than guessing it from the account name.

When answers differ, separate authoritative publication from resolver caching. Check every authoritative nameserver and retain the timestamp. A DNS response showing no value, NXDOMAIN or SERVFAIL is an investigation point, not a pass. Return to the product's confirmation check after correcting the specific row.

Test the actual journey and business unit

Send an approved, low-volume message to an external mailbox you control through the actual journey route. Use the intended From domain and business unit. Do not use a test message from another Microsoft product as evidence for this route. Avoid customer content and unnecessary disclosure to public testing services.

At the recipient, open the original message and record:

• Visible From domain and whether it is the intended brand identity.
• Return-Path and smtp.mailfrom domain.
• DKIM signature d= and s=.
• Trusted receiving server's SPF, DKIM and DMARC results.
• Message ID, timestamp, environment and journey identifier.

Require a passing DKIM signature aligned with the intended branded From domain and an overall DMARC pass. For the Envelope-From setup, also verify SPF passes for the actual envelope domain and check its alignment under the published policy. Investigate an actual SPF failure independently: identify the sending IP, evaluated MAIL FROM policy, lookup errors and any forwarding hop. Do not confuse an unaligned SPF pass with an SPF authentication failure. Use the receiving service's own trusted Authentication-Results, not arbitrary headers supplied by a sender. Authentication result interpretation.

At the actual observed Envelope-From domain, diagnose SPF fail or softfail as an authorization mismatch, temperror as a transient evaluation problem such as DNS failure, and permerror as an invalid policy, duplicate SPF records or exceeded evaluated lookup budget. Investigate these separately even when aligned DKIM supplies DMARC success; a generic apex include is not a repair for a different envelope identity. SPF result definitions.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For a fictional example, From news@example.com and MAIL FROM bounce.example.com can align under relaxed SPF when SPF passes. With aspf=s, those two domains are not an exact match; a passing DKIM signature using d=example.com may still satisfy DMARC. This explains why DNS existence, individual protocol passes and overall DMARC results should be recorded separately.

Troubleshooting and frequently asked questions

Why is the domain not Confirmed?

Check ownership TXT, both DKIM aliases and Envelope-From individually. Microsoft identifies missing/updating records and unconfirmed DNS state as typical causes, notes updates can take up to 24 hours, and directs administrators to confirm again. Fix the failed owner rather than recreating every domain. Official troubleshooting.

Why does one team succeed while another cannot use the domain?

Compare the environment and business-unit scope in the change worksheet. A correct DNS configuration is not proof that the domain is available to the team sending the journey. Have an authorized administrator review scope before changing organization-wide access.

Should I publish a universal Dynamics 365 SPF record?

No. Identify the sending product and actual envelope domain. For this workflow, use the generated Envelope-From setup and only a justified, account-derived compatibility update. A historic marketing.dynamics.com example is not a universal replacement for the current wizard.

Can I remove the second DKIM CNAME if my test uses only one?

Keep the full issued configuration. One sampled signature does not show all keys the service may use. Remove or replace a record only through a planned, provider-supported change with a fresh validation test.

Can I enforce DMARC after the wizard turns green?

Not on that evidence alone. Validate delivered journeys and review other senders sharing the policy domain first. Preserve existing enforcement while correcting a new route. Authentication success does not guarantee inbox placement, healthy reputation or recipient consent.

Completion criteria and evidence boundary

The implementation is ready for its operational owner when every public record matches the worksheet, the correct environment confirms the domain, the intended business unit can use it and a representative journey message passes the required alignment checks. Save sanitized evidence and repeat these checks after domain, scope, selector or sending-route changes.

This guide is based on public documentation. No Dynamics tenant configuration, DNS changes or live journey delivery tests were performed. The scope is Customer Insights – Journeys, not every Dynamics 365 mail route. Authentication does not guarantee inbox placement.