Listrak SPF, DKIM and DMARC setup, step by step

On this page: Choose the route and brand before editing DNS · Access and preparation · Publish the documented bounce records at the right owner · Register branding and request the correct DKIM key · DMARC: preserve policy and test alignment · Verify DNS and Listrak activation · Receiver acceptance checklist · Troubleshoot the Listrak-specific failure point · Frequently asked questions

To authenticate Listrak mail, configure the bounce-domain MX and SPF records, register the branding settings in Listrak and obtain the From-domain DKIM record from Listrak Support. Check the list actually sending the campaign, then verify a delivered message. A branded link alone does not authenticate mail. Listrak account branding.

Choose the route and brand before editing DNS

This guide covers Listrak-hosted outbound email using its documented account/list branding workflow. It does not configure employee mailboxes, SMS or an unrelated SMTP service. If an integration uses another provider's transport, establish that route's authentication independently. Do not infer a sending product or plan entitlement solely from access to a marketing account.

If employees also send through Microsoft 365, configure that separate mailbox path using the Microsoft 365 authentication guide. Listrak branding does not authenticate employee mail or authorize replacing its existing mailbox routes.

Map each brand to its account, list, visible From domain and intended bounce domain. An agency with multiple customer domains should obtain approval from each domain owner. Existing working branding is evidence to preserve, not something to overwrite merely to match an example.

Keep these functions separate:

Access and preparation

You need authorized access to the account/list settings, DNS administration and the support channel for the relevant Listrak account. Arrange a controlled recipient mailbox for later testing. Confirm who may approve DNS changes, new reporting destinations and campaign launch. Export existing records and note their TTLs before editing.

Collect the intended From addresses, DNS zone, current list branding and existing DMARC policy. For shared domains, include corporate mail, ecommerce receipts and support tools in the sender inventory. A change to the organization's policy can affect all of those streams even if the immediate task is one marketing list.

Publish the documented bounce records at the right owner

For a dedicated, unused bounce.example.com, Listrak documents MX priority 10 to bounce.esp1.co and TXT v=spf1 include:esp1.co -all. Substitute your chosen bounce domain; keep the two records at that exact owner. Never move the bounce MX to the corporate root domain. Listrak Cloudflare branding instructions.

This two-record example assumes a new dedicated bounce hostname. If it already carries mail or another SPF policy, stop and resolve ownership. Do not replace an existing record blindly or add a second SPF policy. Preserve unrelated DNS and authorized senders.

Before publishing or activating the bounce domain, compare the complete MX routing set, exact owner, numeric priorities and target hostnames with the mail-routing owner’s separately approved plan. The provider’s published example or issued packet is not that approval. Query MX at the exact owner against its authoritative nameserver and a recursive resolver; require the complete approved set, without extra, missing or changed entries. A nonempty answer is insufficient. Preserve the corporate root MX and unrelated routes. Listrak bounce routing.

SPF evaluates the envelope MAIL FROM identity, not the visible From address. Editing example.com does not change SPF evaluation for bounce.example.com. Each owner needs at most one SPF policy; unrelated TXT records are fine. Evaluate nested mechanisms and redirects against the limit of ten DNS-querying terms. SPF specification.

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Register branding and request the correct DKIM key

In Account → Account Settings, enter Domain Alias and Bounce Domain, then Save Changes. Account settings affect all lists; use the appropriate list-level selection for multiple domains. Listrak's standard link alias points to customers.esp1.co.

For DKIM, provide Support with the intended From domain. Request the exact record owner, TXT value and activation confirmation for that account. Account and DKIM setup.

Listrak's Cloudflare guide says Support supplies the TXT name and value; key1._domainkey is likely, not a universal selector to assume. Use DNS-only rather than proxied branding records. Avoid adding literal enclosing quotes when the DNS interface already manages them. Provider-specific DNS details.

In the change ticket, record the full DKIM owner and From domain together. Publishing a valid public key for brand A does nothing for a signature that names brand B's selector owner. Do not copy another account's key, create your own replacement key or publish private signing material.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

For an existing account, request a supported transition if Support issues a new selector. Preserve the working old record until the operator has verified the new signing path and any queued mail is accounted for. A public key's presence does not prove that the service is using its matching private key.

DMARC: preserve policy and test alignment

DMARC passes when either SPF or DKIM both passes and aligns with the visible From domain. Relaxed alignment permits the same Organizational Domain; strict alignment requires an exact domain match. A bounce subdomain can align under relaxed SPF while failing strict SPF alignment. Aligned passing DKIM can still supply the DMARC pass. RFC 9989.

Do not weaken an existing policy to make one campaign appear healthy. First correct the list's identity and signing configuration. Do not add a second DMARC record at the same policy owner. If no policy exists, a monitored, approved introduction can use p=none, but inventory all legitimate traffic before enforcing more strongly.

Only when no direct or applicable inherited policy exists and the domain owner approves first-time monitoring, publish one TXT policy with v=DMARC1; p=none at the intended From domain’s DMARC owner. For example.com, the full owner is _dmarc.example.com, entered as _dmarc in that zone. For news.example.com, use full owner _dmarc.news.example.com: _dmarc.news relative to the parent zone, or _dmarc in the separately delegated child zone. Do not create a child monitoring exception to an existing protective policy. The minimal value requests no reports; append ; rua=mailto:APPROVED_REPORT_ADDRESS only after replacing the placeholder with a provisioned, approved destination. DMARC policy publication.

The branding article includes a DMARC example with pct. That tag was removed by RFC 9989, which supersedes RFC 7489 and RFC 9091. Do not copy the old percentage mechanism or an example reporting address into your policy. Likewise, an example p=reject is not authorization to impose rejection before other senders have been assessed.

Use an approved aggregate-report destination and verify external report-receiver authorization when needed. Reports help reveal other lists or routes that a single test missed. Failure reporting can disclose message content and needs a separate privacy decision. RFC 9990 aggregate reporting · RFC 9991 failure reporting.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS and Listrak activation

Replace all uppercase placeholders below with the actual names in your implementation worksheet. These are read-only commands, not configuration values:

dig +short MX EXACT_BOUNCE_DOMAIN
dig +short TXT EXACT_BOUNCE_DOMAIN
dig +short TXT EXACT_SELECTOR._domainkey.EXACT_SIGNING_DOMAIN
dig +short CNAME EXACT_LINK_DOMAIN
dig +short TXT _dmarc.EXACT_FROM_DOMAIN

The bounce MX must match the approved destination and priority. SPF must be a single valid policy at the same bounce owner. DKIM must contain the exact support-issued public data. For link branding, inspect the intended CNAME separately. A CNAME cannot coexist with ordinary TXT or MX data at that same owner; link and bounce names must not be collapsed into one hostname. DNS alias rules.

Query the authoritative nameserver as well as a recursive resolver. If names differ, investigate the DNS editor's automatically appended zone. For example, a relative-name field normally needs bounce, not a full name that will become bounce.example.com.example.com. Wait according to TTL and negative caching, then recheck; an arbitrary delay alone proves nothing.

For aliases used in setup or verification, retain an ordinary, unflattened CNAME response. Cloudflare warns that flattening can prevent third-party verification because the CNAME itself is not returned. Check the exact alias with a CNAME query rather than accepting an address response as equivalent. Cloudflare CNAME flattening.

For branding or verification records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, 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 DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Confirm the selected list retains the intended branding and Support has enabled the intended DKIM configuration. Keep a record of those confirmations. No generic success screen substitutes for a received-message check.

Receiver acceptance checklist

An authorized operator should send a representative message through each materially different list/From route to a controlled mailbox. Obtain the original received headers. Trust the Authentication-Results added by that receiving system, not a copied or sender-supplied assertion. RFC 8601.

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Record these results together:

• Expected visible From domain and list identity.
• spf=pass for the intended smtp.mailfrom bounce domain.
• dkim=pass for the intended customer signing domain, aligned under the applicable adkim mode, with the selector recorded.
• dmarc=pass, identifying which aligned mechanism supplied it.
• Message timestamp, receiving service and any forwarding or gateway path.

If a direct message passes but a forwarded message fails SPF, investigate the new connecting server and whether aligned DKIM survived. Do not add a forwarder's addresses to the marketing SPF policy as a reflex. Authentication also does not certify consent, reputation or inbox placement.

A DMARC pass supplied only by SPF does not complete the DKIM task. Likewise, investigate SPF fail, permerror or temperror even if aligned DKIM carries DMARC: check actual sender authorization, duplicate policies or lookup limits, and DNS errors respectively. Separate a direct-route defect from forwarding effects before changing the policy.

Troubleshoot the Listrak-specific failure point

A useful diagnosis is specific: “List B used the old bounce identity at this timestamp” is actionable. “The domain passed a checker” is not enough to locate a list-level mismatch.