Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Acoustic Campaign distinguishes a custom domain from an additional From domain. A custom domain can include branded links and related sending infrastructure; a From-only configuration does not carry all of that branding. Choose the intended architecture before asking a DNS administrator to publish records. This guide covers Campaign provisioning, not every product carrying the Acoustic name.
Start with the provisioning case
The From-domain guide requires a custom domain to exist first and a support case for the additional From domain. It also warns against performing its provisioning changes until the account representative or client success director has placed the order and a specialist directs the work. Follow that boundary rather than treating published examples as a self-service recipe.
Prepare the Campaign organization name, pod, proposed domain and the intended reply-handling arrangement. Acoustic accepts only subdomains for custom email domains. Neither the custom email domain nor a From domain may reuse the domain assigned to a custom landing page. Record whether this is a new custom domain or an additional sender identity. Identify the existing DNS owner and preserve the current zone before any delegation is considered.
Choose the DNS responsibility model
References: RFC 1034 §4.2.
According to the custom-domain provisioning guide, Acoustic supplies the appropriate DNS instructions. In an Acoustic-hosted arrangement, the customer implements supplied nameserver records and Acoustic manages the relevant SPF, MX, bounce, reply and DKIM records. In an externally hosted arrangement, the customer publishes the supplied record set. The From-domain guide specifically says multi-client shared IP pools require Acoustic-hosted DNS.
Confirm the exact subdomain being delegated. Changing a parent domain's nameservers can affect websites and corporate email, not just campaigns. Do not delegate a name already carrying unrelated services without a complete migration plan. Keep the provisioning case's ownership decision and record list as the source of truth; no universal Acoustic SPF policy is supplied here. Acoustic warns that a configured custom domain cannot be repurposed or updated. Settle its intended use before provisioning; coordinate a replacement with the specialist rather than planning an in-place identity change.
Implement only the approved record set
References: RFC 7208 §3.2, RFC 1034 §3.6.2.
For external DNS, map each supplied full owner and type into the host's editor, preserving its actual value. Maintain one SPF policy at the relevant envelope owner and preserve legitimate dependencies. A DKIM CNAME must not collide with existing ordinary data at its owner. For hosted DNS, verify delegation and ask the provisioning team to confirm its records after the nameserver change rather than adding duplicate data to an inactive parent-zone editor.
Custom-domain setup also includes a later CNAME step for SSL certificates after initial validation, as described by Acoustic. Keep link certificates and authentication as separate checks: a working HTTPS link does not prove DKIM alignment, and a passing DKIM signature does not prove branded links are ready.
Verify the active selector rather than guessing
References: RFC 6376 §3.6.2, RFC 2308 §5.
Acoustic's deliverability guidance documents spop1024 and spop2048 selector conventions and says the provisioning team determines the selector. Inspect the actual DNS and message signature to learn which is active. Both may be present during a transition; their presence alone is not a reason to delete either.
Query the exact selector owner at the authoritative server, and verify SPF at the actual envelope domain. Capture the delegation, answers, TTLs and provisioning confirmation. A correct record in a non-authoritative editor is not publication. Different recursive answers can reflect caches, including cached absence; persistent authoritative disagreement needs investigation rather than a longer wait.
Send a controlled Campaign message
References: RFC 9989 §4.4.
Use the provisioned From domain and intended VMTA or sending configuration in a harmless test to an approved mailbox. Retain the visible From, Return-Path, DKIM d=/s= values and trusted receiver results. Confirm a passing aligned path under the effective DMARC mode. Check reply handling, bounce behavior and branded links against the agreed configuration, without sending a production campaign merely to test setup.
Illustrative outcome: the new From domain authenticates but links still use the existing custom domain. That can match a From-only design; it is not automatically a DKIM defect. If the business expected newly branded links, revisit the requested architecture instead of changing authentication records at random.
Keep the prior sending route available until acceptance where feasible. Stop expansion if DNS or message identity differs from the provisioning case. Recheck after pod changes, VMTA changes, selector rotation or domain migration. All steps here are documentary guidance; no Acoustic tenant or test message was executed.