What it does

Proves to receiving mail servers that Customer Insights - Journeys is allowed to send on behalf of the client's domain, by publishing DKIM keys and a Return-Path alias as DNS records the client controls. The same wizard also registers domains used for hosting marketing forms. Without it your mail either gets rewritten to a Microsoft-owned domain or lands in spam.

Key facts

• Configured at Settings > Email marketing > Domain authentication (Settings > Domains when modernised business units are on), one domain at a time. Each needs four DNS records: a TXT to prove ownership, two CNAMEs for DKIM (CNAME1 and CNAME2), and a CNAME for the envelope-from / Return-Path alias that gives you SPF alignment.
• The ownership TXT goes on the root of the domain being authenticated. If existing CNAME records block that, you can instead put the TXT on dynmktown.<domain> — for example dynmktown.contoso.com to validate contoso.com.
• contoso.com and www.contoso.com are separate domains as far as this wizard is concerned. Authenticate the root, because the From address is built as <mailaccount>@<domain> and nobody wants [email protected].
• SPF is handled through Return-Path alignment via the envelope-from CNAME. You can additionally add include: for the Dynamics sending domain to the client's own SPF record.
• Every new instance gets its own instance domain auto-authenticated with DKIM and SPF, plus the shared dyn365mktg.com. Both are for testing and demos only — never production sending.
• If you send from an unauthenticated domain, the From address is silently rewritten to something like [email protected]. Deliverability is fine; the reply-to address is not real.
• Domain authentication is not required for forms or form prefill. External form hosting needs the domain on the allowed-domains list and external hosting enabled, which is a separate step.
• Gmail and Yahoo bulk-sender rules (in force since February 2024, at 5,000+ messages per day) require SPF, DKIM and DMARC, one-click unsubscribe with a List-Unsubscribe-Post: List-Unsubscribe=One-Click header, and a spam rate under 0.30% measured in Google Postmaster Tools. DMARC is not published by this wizard — the client publishes it themselves.
• With modernised business units and business unit scoping enabled, the wizard adds a Business unit lookup and an "Enable across organizations" checkbox that decides whether other business units can send from that domain.
• BIMI is supported and covered by its own article; treat it as a follow-on once DMARC is properly in place.

When to use / skip

Non-negotiable for any environment that sends production email. The only case for skipping is a sandbox or demo environment where the Microsoft-supplied instance domain is genuinely good enough — and even then, authenticate one sandbox domain so you can rehearse the DNS conversation before it matters.

Where there's a real decision is how many domains. A dedicated marketing subdomain (news.contoso.com, mail.contoso.com) keeps marketing reputation separate from corporate mail, which the client's mail team will usually prefer. The cost is that reply-to and From addresses look different from the ones sales use, and some clients hate that.

If the client's corporate domain already has a strict DMARC policy, involve their mail administrator from day one rather than treating this as a marketing task.

Configuration decisions

• Root domain versus a dedicated marketing subdomain, and whether the corporate mail team will accept marketing traffic on the corporate domain's reputation at all.
• Which domains are for sending, which are for form hosting, and which are both — the wizard asks you to declare the purpose per domain.
• The default sending domain to set on the instance, which determines what From address the designer offers by default when someone creates a new email.
• DMARC policy and alignment: what p= value the client publishes, and whether they are ready to move from none to quarantine before high-volume sending starts.
• Per business unit domain ownership, and whether each domain is shared across the organisation or locked to one business unit — only relevant with modernised business units.
• Who owns the DNS zone and what their change lead time is. This is usually the actual constraint on the go-live date.

Gotchas

• The client's DNS is nearly always managed by a team outside the project. Two-week change windows for four records are common. Raise the request in week one, not the week before go-live.
• Some DNS providers auto-append the zone name to record names. Pasting the fully qualified host name the wizard gives you into such a provider produces a record with the domain doubled up, and verification quietly fails with no useful error.
• Silent From-address rewriting means an unauthenticated domain doesn't produce an obvious error at send time. The email arrives, from an address the recipient can't reply to, and nobody notices until a customer complains.
• Copying or restoring an environment does not carry domain authentication across. You have to re-authenticate on the target and update DNS before sending, and you should clear the old records if the source environment is being retired.
• DMARC is required by the bulk-sender rules but is not part of this wizard. Teams that tick off "domain authentication complete" often haven't published DMARC at all.
• Reusing a domain that has previously been used by another ESP without cleaning up old records leads to conflicting SPF includes and lookup-limit failures.

Consultant notes

• Give the client's DNS team a single, complete record sheet with exact names and values copied from the wizard, and ask them to confirm whether their provider appends the zone name. That one question saves a round trip.
• Insist on a proper warm-up plan for a new sending domain. A cold domain sending a full database on day one is the fastest route to a deliverability problem you'll spend months fixing.
• Before go-live, send a test to a Gmail address and check the raw headers for DKIM pass, SPF pass, DMARC pass and the one-click unsubscribe header. That single test covers most of the bulk-sender checklist.
• Get Google Postmaster Tools set up for the sending domain during the build, not after the first complaint — the 0.30% spam rate is measured there and you need history.
• Tell the client that the dyn365mktg.com fallback is not a get-out. It works, it looks wrong, and it will end up in a screenshot in a steering meeting.

---

Worth another look when mailbox providers tighten bulk-sender rules again, or if BIMI moves beyond its current support level.