Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Choose the ownership model first
Dialog Insight documents two different workflows. Delegation hands a dedicated subdomain's DNS administration to Dialog Insight; self-management leaves the relevant records with your DNS team. Do not mix their instructions. Before starting, identify your current authoritative DNS host, the person able to change it, the Dialog Insight account owner, and the business owner of the campaign. Inventory existing mail, web and tracking services on the proposed names. A subdomain already used for another application is not an empty namespace.
The delegated route is appropriate when the team wants provider assistance and can authorize the necessary subdomain delegation. The self-managed route requires DNS and authentication expertise. Neither route should be presented as a verified production configuration until you have inspected a message from the resulting workflow.
Configure the delegated route
References: RFC 1034 §4.2.
Choose a subdomain dedicated to mailings, including the sender and hyperlinks. Dialog Insight gives c.yourdomainname.com as an example; use your own approved namespace rather than treating that example as a required label. Choose an existing generic mailbox for customer replies. The documentation says replies pass through Dialog Insight and are forwarded to this return address, which should not be the sending address or a personal mailbox.
Provide the chosen subdomain to Dialog Insight support under its subdomain-delegation process. The provider supplies four NS entries; obtain those exact entries rather than copying nameservers from an unrelated account. Your DNS team must confirm that the host supports NS records, apply the supplied delegation at the correct parent, and notify support when it is present. This gives the provider authority over that subdomain, so check existing records and dependent services before approving the change.
Dialog Insight says its team then configures SPF, DKIM, DMARC and the custom sending/tracking domains. Its documented default is shared IP addresses, with separate instructions for a dedicated IP. Verify the resulting configuration rather than inferring the signing domain or policy from this service description. Check the delegation and the child's authoritative answers, not only records still visible in a parent-zone editor.
Configure the self-managed route
Start in Domain management and add each domain or subdomain. Select each entry in Domains to validate and use Validate. The minimum configuration consists of a From sender domain, a custom tracking subdomain, and a Mail-From domain. A landing-page subdomain is optional and must not be confused with authentication.
In Sender domains, add the validated sender domain and follow the supplied DKIM instructions. Dialog Insight explicitly leaves DMARC configuration to you on this route. If needed, add the domain to the account's authorized senders. Under Custom domains, open Custom trackers and add a validated subdomain, choosing Custom Trackers in the setup dialog. Follow its DNS, SSL certificate and HSTS requirements. A working tracker is operationally important, but its successful configuration does not itself establish DMARC alignment.
After the sender and tracker are configured, request the Mail-From DNS entries from Dialog Insight support and publish the exact returned values. Do not substitute a guessed SPF include or infer the envelope identity from the visible sender. If adding a custom landing-page domain, use its separate configuration and certificate process; the documentation permits one such custom domain per project.
Verify the sending identity, not just the dashboard
References: RFC 9989 §4.4, RFC 6376 §6.
A green setup indicator establishes only the check that the product performed. For acceptance, send a controlled message through the actual workflow to a mailbox whose received headers you can inspect. Preserve the original message rather than a screenshot of a successful DNS lookup. Record the visible From domain, the SMTP envelope domain shown by the receiving system, each DKIM signature's d= signing domain and s= selector, and the receiving system's Authentication-Results. Do not trust an Authentication-Results field simply because a sender inserted one.
SPF authenticates the envelope identity, not automatically the visible From address. DKIM verifies a signature for its signing domain. DMARC requires a passing path that aligns with the visible From domain under the applicable alignment mode. A provider-owned envelope can pass SPF without producing aligned SPF for your brand. Conversely, a valid aligned DKIM signature can provide the passing DMARC path even when SPF does not align. Inspect the actual identities before changing DNS.
Use this illustrative acceptance case, not as a claim about a provider's default: a message has From learning@example.com, envelope bounce@vendor.example.net, and a verified DKIM signature with d=example.com. SPF success for vendor.example.net alone is not aligned to example.com; the valid signature with d=example.com supplies exact DKIM alignment. If the receiver instead reports an invalid signature, the example no longer has that passing aligned path. Record both the authentication result and the domain it applies to.
Diagnose failures in a fixed order
References: RFC 1034 §3.6.2.
First confirm that the nameservers delegated for the exact domain are the servers you edited. Query the authoritative servers for the expected owner name and record type. Compare their answers with the account's supplied values, checking accidental domain suffix duplication, missing selector labels, truncated keys, and CNAME conflicts. Only after the authoritative answer is correct should you investigate recursive caching or wait for an earlier TTL to expire. There is no single guaranteed worldwide propagation deadline.
Next repeat the message test on the failing route. A web application can use a different transport from a human mailbox, and a successful preview is not proof that production notifications use the same identity. If DNS is right but the signature is missing, investigate the sending transport and product configuration rather than adding unrelated SPF permissions. If authentication passes but mail is placed in spam, retain the headers and investigate reputation, content and recipient handling separately. Authentication does not guarantee inbox placement.
Change control and completion evidence
References: RFC 7208 §3.2, RFC 7208 §4.6.4.
Keep the previous record sets, the approved new values, the domain owner, the business owner of each affected workflow, and a specific recovery decision before making changes. Never create a second SPF policy at the same owner to add a sender. Review one combined policy and its DNS-lookup dependencies; unrelated TXT records can coexist, but multiple candidate SPF policies are an error. Do not overwrite another sender's selector. Do not weaken the entire domain's DMARC policy to disguise one failing integration.
Acceptance requires authoritative DNS evidence, product validation, and a received-message identity record for every in-scope sending route. Test replies separately where the workflow expects them. These are proposed checks, not completed tests: this guide is based on retained documentation and synthetic reasoning, with no live tenant changes, DNS measurements, or delivered-message results. A human owner must review the evidence and approve any production rollout. Keep existing working routes available until the replacement is demonstrated, and remove obsolete permissions only after confirming no remaining dependency uses them.