Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Map the Listrak account and list before branding
Listrak separates a Domain Alias for branded links from a Bounce Domain for bounced-message processing. These settings can be applied at account level and selected within individual lists, so a successful account configuration does not automatically establish the identity used by every list. Record the account, list, intended From domain and selected branding settings before requesting DNS changes. Listrak branding guide.
Choose a marketing owner who can identify live lists, a DNS administrator and a mail-security reviewer. Export the existing records at every proposed owner and note any other application using them. For an account with several brands, create a mapping of list to From domain, alias and bounce domain. Keep previously working settings available until the replacement has passed both application checks and a received-message test. Neither the link brand nor a green account check should substitute for that list-level mapping.
Publish the right records at the right names
The branding documentation specifies a CNAME for the Domain Alias, a dedicated bounce-subdomain MX record, and SPF as a TXT record at that bounce domain. It explicitly warns against putting the bounce MX at the root domain because that can disrupt incoming mail. It also directs customers to contact support with their intended From domain to enable DKIM. Obtain the current account-appropriate records and DKIM instructions before publishing. Branding and authentication settings.
Keep the DNS change request explicit: purpose, owner, type, target or public value, priority where applicable, and prior record. The alias improves link branding; it is not the DKIM selector and is not proof of DMARC alignment. The bounce MX serves delivery-feedback handling, not the company's ordinary staff inbox. Do not copy placeholder keys or malformed spacing from an illustrative table. Use the complete value confirmed for the actual deployment and inspect the resulting authoritative answer after saving it.
SPF must be evaluated at the domain used by the SMTP envelope. Preserve any legitimate existing authorization at that owner while ensuring there is only one applicable SPF record and that the policy stays within RFC7208 §4.6.4’s limit of ten evaluated DNS-causing terms, including nested evaluations. A bounce-domain SPF policy and a corporate root SPF policy serve different identities; do not merge them merely because both contain the company's name. SPF specification.
Apply branding to the intended list
After DNS publication, confirm the account settings and then inspect the list's Branding Settings. Listrak's verification guidance specifically tells administrators to check that the custom Domain Alias and Bounce Domain selections are enabled for the list. It also describes a confirmation-screen branding audit that can be inspected without completing a campaign send; cancel that flow after inspection. A separate live test should be restricted to one controlled address that is subscribed to the list, with the recipient filter checked again on the final confirmation screen. Ensure branding is complete.
These are distinct checkpoints. The configuration audit checks the account's expected setup. The controlled send demonstrates what the chosen list actually emits. Ensure the test uses the same From domain and list settings planned for production rather than a convenient default list. Save the list mapping with the test evidence so a later administrator can reproduce it. For multiple brands, repeat rather than extrapolating from one successful message.
Require aligned evidence as well as a DKIM pass
In the received source, inspect the trusted receiver's Authentication-Results, the visible From domain, Return-Path and every DKIM d=/s= pair. DKIM pass validates a signature; DMARC also requires its signing domain to align with From, or an aligned passing SPF path. The support-enabled DKIM domain should be compared with the actual From domain rather than inferred from a display name or tracking URL. DKIM specification and DMARC specification.
Listrak’s published DMARC guide explicitly requires relaxed DKIM and SPF alignment for its documented setup, explaining that its bounce subdomain differs from the sending domain. Treat this as a provider-specific configuration constraint, not a change to DMARC’s rule that either aligned passing mechanism can suffice. Do not automatically weaken an existing strict domain policy. Ask Listrak to confirm whether the proposed exact-match signing and sending route is supported, or evaluate a separately scoped sending domain and approved policy. Until that compatibility is established, hold the rollout. Listrak alignment requirements, adkim and aspf sections.
An existing DMARC policy may cover other legitimate sending systems. Listrak's DMARC guidance warns that a root or shared subdomain policy affects sources beyond this account. Review that scope before any change; do not replace an established enforcement policy with a generic monitoring example just to remove a setup warning. Use the current DMARC specification to interpret policy and alignment rather than copying historical optional tags from a vendor example. In particular, RFC9989 Appendix A.6 removes pct; do not copy the older vendor example as a current percentage-rollout mechanism. Listrak DMARC guidance.
Record acceptance and keep recovery specific
The original test plan here is unexecuted. Create one identity-table row per tested list and From domain, recording account, list, workflow, time, Domain Alias, Bounce Domain, From, Return-Path, SPF domain/result, all DKIM domains/selectors/results, DMARC result and evidence location. Add functional checks for branded links, replies and bounce processing when those are part of the approved test. Do not claim that audit checkmarks establish inbox placement or every downstream route.
On failure, first compare account settings with list selections, then DNS and support DKIM activation with the received identities. Pause the affected send and revert only the approved changes if recovery is needed. Preserve unrelated mail routing and domain enforcement. No Listrak tenant, live DNS or message was tested here; exact-route evidence, the completed original identity table and human SME approval remain open.