Acoustic SPF, DKIM and DMARC setup, step by step

Acoustic Campaign authentication is a provisioning-led setup, not a universal SPF include to paste at your root domain. Confirm the Campaign organization and sending route, obtain the approved DNS records through the provisioning case, publish or delegate only the specified domain, and complete Acoustic's validation. Then check a delivered message for aligned branded DKIM and DMARC. Set up From domains

This guide covers Acoustic Campaign’s custom-domain and From-domain workflows. No customer account configuration, DNS change, delegation or test send was performed.

Confirm Campaign rather than another Acoustic product

Silverpop is part of Acoustic Campaign's heritage, but the current Acoustic brand also includes other products. Do not apply Campaign instructions automatically to Acoustic Connect or Tealeaf simply because they share a company name. Confirm the actual product, pod, Campaign organization and sending path with your account owner. Campaign's Silverpop heritage · Acoustic Connect product context

The workflow below concerns mail sent through the provisioned Campaign domain and VMTA, the sending configuration associated with an IP. It does not configure your corporate mailbox provider. A separate SMTP or transactional integration must be mapped to its actual Campaign configuration before these checks can be treated as evidence for it.

Employee mail through Microsoft 365 is a separate sending route; retain its configuration and use the Microsoft 365 authentication guide for that service rather than treating these application records as its configuration.

Inventory each visible From domain, sending organization, pod, VMTA/IP selection, current DNS host, reply destination and link domain. Keep records of existing mail and website uses. Domain authentication is not permission to move a company's entire DNS zone.

Choose a custom domain or an additional From domain

A custom domain provides branded email infrastructure, including link-related identities. An additional From domain provides an authenticated sender but can use the existing custom domain's link branding. The From-domain documentation requires an existing custom domain first and excludes using the same domain as a custom landing-page domain. From-domain scope

The custom-domain procedure asks for a subdomain and requires a provisioning case or applicable order before work begins. It warns against repurposing a configured custom domain. Entitlement and charges depend on the existing order; the public procedure is not a promise that all plans include new domains or IPs. Custom-domain provisioning

Choose a dedicated unused name with the domain administrator. Record what depends on it today, even if it looks unused in a marketing dashboard. For an established account, recover the original provisioning case before rebuilding working DNS.

Establish who hosts the authentication records

The official pages require careful reading. The custom-domain overview describes delegation to Acoustic. The more detailed provisioning procedure also describes customer-hosted records. The From-domain page specifically requires Acoustic-hosted DNS for a multi-client shared IP pool. Do not infer that every account can self-host or that every customer must delegate a corporate root. Have provisioning confirm the applicable hosting arrangement in the case. Custom-domain overview · From-domain hosting condition

If Acoustic hosts the approved subdomain, apply only the issued delegation at that boundary and let Acoustic manage its records. If you host it, obtain the complete SPF, DKIM, MX and related routing records. Never combine both approaches by publishing conflicting local records beneath a delegated child and assuming receivers will see them. Hosting alternatives

DNS delegation changes which servers answer for the child zone. Before implementation, establish who retains control, who approves later changes and how rollback would work. Do not remove existing corporate MX, unrelated TXT records or website aliases. The choice of DNS host is operationally consequential, not merely a different way to enter a key.

Before publication or activation, obtain the DNS/routing owner’s separate approval for the exact child NS owner and complete nameserver set, every issued A owner and destination IP, and every mail/bounce/reply MX owner with its complete numeric-priority/target set. Also approve the actual reply-forwarding recipient and its data exposure. The provider’s packet is not itself this authorization. Verify the complete approved sets at authoritative and recursive DNS, including delegated-child authority, and stop on missing, extra or unexpected destinations. Preserve root mailbox delivery and unrelated services.

Obtain, publish and activate the exact records

Provide the organization, pod, requested domain and IP setup to provisioning. Wait for the approved record set. Publish it through the authoritative DNS administrator, report completion in the case and complete the requested message validation from the actual domain/VMTA. Custom-domain provisioning also has a later certificate/link-security CNAME stage. Complete that stage rather than treating the first DNS check as the end. Provisioning sequence

For an additional From domain, the case supplies records and the team validates them before the sender is used. If reply handling is included, confirm the response settings and forwarding destination. From-domain procedure

For both new custom domains and additional From domains, follow the provisioning case and specialist’s instructions before changing the sending identity. Do not treat the From-domain request as approval to switch an application prematurely.

Use a change worksheet with one line for every record: purpose, full owner, type, issued value, TTL, DNS administrator and verification result. Compare the actual published owner with the approved owner. DNS panels may append a zone suffix automatically; adding a fully qualified name to such a field can duplicate the domain.

For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com zone uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use relative SELECTOR in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.

For DKIM, publish only the supplied public record or alias. Obtain the actual selector and target/key from the case. Do not use a generic key generator, another organization's values or an old Silverpop selector recipe. Acoustic controls the signing private key. For a CNAME, preserve DNS-only alias behavior; do not HTTP-proxy or flatten it into A/AAAA records. A CNAME cannot share its owner with other record types.

Acoustic’s current deliverability guidance names spop1024 and spop2048 as provisioned selectors and notes that both may coexist during a transition. These are clues for finding a configuration, not instructions to create either key or select a key length. The provisioning team determines the active setup; reconcile the case with the actual message’s d= and s=, and retain selectors still needed by queued mail or a managed transition. Acoustic selector guidance

For a TXT key, preserve the complete issued value. A DNS provider may split a long value into quoted character strings within one TXT record; do not turn those pieces into multiple independent key records. Ask the DNS host or provisioning team to confirm an ambiguous representation before activation.

SPF: authorize the observed envelope identity

SPF checks the SMTP MAIL FROM domain, usually shown in a delivered Return-Path, not the visible From address. A Campaign bounce domain can differ from the branded From domain. Inspect the provisioning records and a real message before deciding which owner needs attention.

At an owner publishing SPF directly, maintain one v=spf1 TXT record and preserve other legitimate senders. Keep its existing terminal policy unless a separate policy change is approved. The ten-term limit covers DNS-triggering terms actually evaluated, including nested include, a, mx, exists, ptr and redirect. Ten top-level includes are not necessarily safe. Root SPF does not automatically apply to a child domain. SPF standard

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

A duplicate-policy or excessive-term permerror needs structural repair, not another include. If you own the policy, reconcile confirmed senders into one valid record and remove only obsolete authorization. If the failing owner is delegated to Acoustic, escalate the precise owner, response and timestamp to provisioning. Do not flatten managed authorization into an unmaintained IP snapshot.

Keep envelope SPF, branded DKIM and link branding separate in the worksheet. An SPF pass for an unrelated provider domain does not prove that your visible brand is authenticated.

Only for the issued CNAME branches, including any separate certificate/link stage: Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

Preserve DMARC across hosted and customer DNS

For Acoustic-hosted domains, establish who controls DMARC and where reports go. Acoustic's DMARC guidance describes support involvement for report destinations. For customer-hosted domains, coordinate the DNS change with the security owner. Do not create a second policy because two teams are working on the same setup. Acoustic DMARC requirements

DMARC passes when at least one passing SPF or DKIM identity aligns with the visible From domain. Relaxed alignment compares organizational domains; strict alignment requires the exact domain. A bounce subdomain may align under relaxed SPF but not strict SPF. A passing branded DKIM signature can independently satisfy DMARC. Current DMARC standard

Inspect both the From-domain policy and applicable inherited policy. Preserve existing enforcement, alignment choices and reporting addresses. Do not downgrade an established policy as part of provisioning.

Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves this first policy and a monitoring/review plan after reviewing legitimate senders, a first TXT policy for fictional From domain example.com may be v=DMARC1; p=none at full owner _dmarc.example.com. The minimal value requests no reports; provision an approved reporting destination and review process before adding rua. Preserve established enforcement and authorized reports.

For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.

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 the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Before a separate domain-wide move to p=reject, follow RFC 9989 section 7.4: legitimate outbound mail needs valid DKIM, and indirect-mail interoperability, including forwarding and mailing lists, needs review. Completing this sender alone does not authorize enforcement for every route.

p=none does not guarantee delivery or disable monitoring. Receivers retain their own filtering decisions. Failure reporting can disclose message-level information and needs a separate privacy assessment rather than automatic ruf publication. Failure reporting

Verify public DNS and receiver acceptance separately

Use actual owners supplied by provisioning in place of these illustrative names. The commands do not change DNS:

dig +short NS email.example.com
dig +short TXT bounce.email.example.com
dig +short MX email.example.com
dig +short MX bounce.email.example.com
dig +short MX reply.email.example.com
dig +short CNAME SELECTOR._domainkey.email.example.com
dig +short TXT SELECTOR._domainkey.email.example.com
dig +short TXT _dmarc.email.example.com

For each provisioned mail, bounce or reply owner, compare MX destinations and priorities with the case. Query only the owners actually assigned; these illustrative names are not a universal routing set. Confirm that corporate mailbox MX remains unchanged, and test reply/bounce handling after activation.

For delegated hosting, confirm the child NS answers match the approved delegation and query its authoritative servers. For self-hosting, compare every owner/type/value to the case. The actual envelope owner and selector may differ from the examples. Follow CNAMEs until the public key or SPF answer is reached; a direct TXT-only lookup is not always enough to understand the chain.

Once provisioning confirms activation, use an authorized representative send from the exact organization/domain/VMTA under review, with harmless synthetic content and controlled valid external test recipients, not a real customer campaign audience. Keep reply and bounce exercises within those approved test identities. Preserve the external receiver's trusted Authentication-Results (receiver trust boundaries) and full headers. Record the visible From, envelope identity, SPF result, each DKIM signing domain and selector, DMARC result, timestamp and message ID.

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

For this branded DKIM setup, require the intended Acoustic Campaign signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate. Also require working SPF for the observed envelope and investigate errors independently. Repeat for each distinct From/VMTA and separately routed transaction stream. If rejected before receipt, preserve the SMTP error and provider logs instead of claiming header evidence.

Check replies, bounce handling and secured links separately. Authentication alone does not prove that replies reach the team, that tracked URLs work or that messages land in the inbox.

SPF must be investigated independently even when aligned DKIM makes DMARC pass. For an actual fail, compare the observed sending IP and MAIL FROM policy; for permerror, inspect syntax, duplicate policies and evaluated DNS terms; for temperror, check transient DNS availability and repeat the same-route test after recovery. Preserve the receiver result and timestamp rather than weakening DMARC to mask the error. SPF result definitions

Troubleshooting by evidence

Send Support the exact failed message identity, time, route, record queries and error. Do not rotate keys or move nameservers before locating the failing layer.

Agree scoped recovery with the sending and provisioning owners before rollout: pause affected workflows when authorized, restore only an approved prior route, and retain records needed by shared senders, queued mail, replies and previously sent links. Recheck provisioning and actual-message acceptance after a pod, VMTA, domain or DNS migration; do not assume a saved zone copy restores account-side state.

Review boundary

Public documentation was reviewed, including the different hosting descriptions. Account-specific records, entitlement, delegation approval, activation and receiver results remain to be verified with the domain owner and Acoustic provisioning. No live implementation or delivery outcome is claimed.