Sailthru SPF, DKIM and DMARC setup, step by step

Sailthru domain authentication requires two DKIM CNAMEs, the applicable SPF authorization, a bounce-domain CNAME and provider-side enablement. Publish the records for the exact From domain, have Sailthru complete activation, verify the sender mailbox, and test a newly delivered message. DNS records alone do not activate DKIM. Sailthru DNS configuration.

This guide covers Sailthru by Zeta, including documentation that uses the Engage by Sailthru name. It is not a Zeta Marketing Platform, Selligent or Cheetah Digital configuration recipe. No account, customer DNS or live email was tested. Current Sailthru product.

Resolve the domain and policy before onboarding

Choose the exact domain after the @ in your intended From address. offers@example.com and offers@news.example.com require different owner names. Record the account, brand, campaign or transactional route and who controls DNS and the sender mailbox.

Involve your Sailthru contact before using a new domain. Its new-domain procedure includes authentication, monitoring and a tailored ramp plan. A domain already configured but dormant also needs a review before resumed sending. Do not interpret old DNS records as evidence of a current sending reputation or an approved volume schedule. New sending-domain requirements.

Check strict DMARC alignment now. Sailthru's current DNS guide says it cannot support strict adkim or aspf. If your existing or inherited policy requires either, pause the domain design and obtain a supported resolution with Sailthru and the security owner. Do not silently remove strict tags or create a weaker child policy. The fact that an individual test might happen to align exactly does not override the provider's documented support restriction. Sailthru's strict-mode limitation.

Understand the three authentication identities

SPF authorization and SPF alignment are separate. A message can be authorized by a provider-owned envelope domain without that domain aligning with your brand. Similarly, any dkim=pass is insufficient if it belongs only to an unrelated provider identity. DMARC requires a successful aligned SPF or DKIM mechanism. SPF, DKIM, DMARC.

For example, a message from offers@news.example.com with envelope domain bounce.news.example.com can have relaxed SPF alignment under example.com. The two domains are not identical, so this relationship alone does not satisfy strict SPF alignment. Do not confuse the DNS CNAME target with the envelope identity used in that comparison.

For a message with multiple signatures, EmailAuth’s DKIM selector guide explains how to keep each signing domain and selector together when deriving its public-key lookup. Do not pair one signature’s selector with another signature’s domain.

1. Review the sending-domain SPF policy

Sailthru's published include is:

include:aspmx.sailthru.com

For a sending domain with no SPF policy and no other authorized senders, the official starting example is:

v=spf1 include:aspmx.sailthru.com ~all

If SPF already exists, merge the authorization into that one record rather than replacing the record. Preserve the other senders and existing final qualifier; do not change -all to ~all simply because an example uses it. Sailthru SPF instructions.

Apply the record at the domain in the approved setup. For example.com, a relative-name DNS panel usually uses @; for news.example.com, it uses news in the parent example.com zone, or @ inside a separately delegated news.example.com zone. SPF does not inherit from the parent. A root-domain change cannot fix an unrelated MAIL FROM policy.

Keep only one v=spf1 record at an owner. Retain unrelated verification TXT records. Evaluate nested DNS-querying terms, including includes and redirects, against the ten-term limit; ten visible include strings is not a safe shortcut. Do not authorize every historical Sailthru IP, add +all, or manually flatten dynamic infrastructure without an approved maintenance design. SPF evaluation and limits.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

The next step provides the custom bounce identity. The sending-domain include and bounce configuration serve distinct purposes: neither a green root-SPF check nor the presence of the include proves the delivered envelope uses your brand.

2. Publish both DKIM CNAMEs and the bounce CNAME

The current official setup requires both selector aliases and a bounce alias. The following are worked examples for example.com, not records to publish unchanged:

sailthru._domainkey.example.com. IN CNAME example.com.sailthrudkim.com.
sailthru2._domainkey.example.com. IN CNAME example.com.sub.sailthrudkim.com.
bounce.example.com. IN CNAME cmf.sailthrudkim.com.

For a From domain of news.example.com, the corresponding example becomes:

sailthru._domainkey.news.example.com. IN CNAME news.example.com.sailthrudkim.com.
sailthru2._domainkey.news.example.com. IN CNAME news.example.com.sub.sailthrudkim.com.
bounce.news.example.com. IN CNAME cmf.sailthrudkim.com.

Confirm these names against the current setup for your account. The two DKIM targets deliberately differ; the second contains .sub.sailthrudkim.com. Do not omit the second selector because the first resolves. Sailthru manages the keys behind these aliases; do not replace the delegation with a copied downstream key. Official DKIM and domain-alignment records.

Enter child-domain records in the correct zone

If the child zone is delegated, edit its authoritative DNS rather than a non-serving copy of the parent. Check whether the DNS panel wants relative names or complete names. A duplicated suffix such as .news.example.com.example.com creates the wrong owner.

At an existing delegated _domainkey.news.example.com authority, full owner sailthru._domainkey.news.example.com maps to relative sailthru, and the second issued selector maps to sailthru2. Preserve NS delegation and other selectors; do not create a parent-zone copy to bypass authority. Relative names.

Keep these aliases DNS-only where a provider offers an HTTP proxy. A CNAME owner cannot also carry ordinary TXT, MX or address data. In particular, do not add a separate SPF TXT record alongside the bounce CNAME. Resolve the alias to inspect the provider-managed policy instead. If the owner already serves another system, stop and reconcile the conflict; deleting that system's record is not a routine authentication step. DNS alias rules.

Preserve both DKIM aliases and the bounce alias without CNAME flattening. On Cloudflare, inspect the individual record's Flatten control and zone-wide flattening for all CNAMEs, as either can hide a DNS-only alias. Coordinate any shared-setting change with the DNS owner after assessing other services; do not casually disable a zone-wide behavior or remove delegation. Confirm the resulting public CNAME answers. Cloudflare CNAME verification guidance.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

3. Complete provider activation and mailbox verification

Have your Sailthru contact complete domain enablement after the records are published. Then finish the documented mailbox verification in Setup > Verified Emails. Use a sender address with a real receiving inbox; Sailthru does not create the mailbox for you. Retain confirmation that the domain is active before testing. Activation and address verification.

Treat these as separate checkpoints: published DNS, active signing, and verified sender address. A mailbox confirmation link cannot validate the cryptographic signature on a campaign, and a public key lookup cannot establish that the sender address is usable.

Coordinate the broader onboarding requirements too. Sailthru's checklist includes Google Postmaster Tools and Yahoo's feedback loop. Use the current account-generated verification token where required and obtain organizational approval before granting monitoring access. Those ownership tokens are not SPF policies or DKIM keys. Sailthru new-domain checklist.

Keep link-rewriting and Horizon configuration separate from authentication. If changing tracking domains as part of the project, preserve working legacy link domains so earlier campaigns do not break. Check those operational dependencies against the full vendor guide instead of deleting every older Sailthru-related record during cleanup. Link-domain and Horizon setup.

4. Keep DMARC protection and reporting intact

Inspect the From domain's applicable DMARC policy, including inherited policy, before adding anything. Preserve existing p, sp, reporting recipients and alignment requirements. Do not replace an established quarantine or reject policy with the vendor's minimum p=none example.

Where there is no established applicable policy and the domain owner approves a monitored introduction, an illustrative record is:

Owner: _dmarc.news.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the names and provision the reporting destination before use. This requests monitoring, not blocking, and cannot repair misaligned mail. Retain one DMARC record per owner. A destination outside the applicable organizational domain needs external-report authorization. Assign someone to review aggregate reports for the real Sailthru envelope and signing identities, alongside every other authorized sender. DMARC aggregate reporting.

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 that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first apex policy, full TXT owner _dmarc.example.com maps to relative _dmarc in example.com. Keep the direct/inherited-policy guard and existing child mapping.

Do not add forensic ruf reporting by default; consider personal-data exposure and support first. Do not treat the obsolete pct tag as a current percentage-rollout control. Before enforcement, assess all legitimate and indirect mail flows; RFC 9989 requires valid DKIM for a domain publishing p=reject. The provider's strict-alignment limitation remains a separate compatibility question. DMARC policy considerations, failure reports.

5. Check public DNS and received-message identities

Adapt these read-only examples to your actual domain. They are not live verification results.

dig +short TXT news.example.com
dig +short CNAME sailthru._domainkey.news.example.com
dig +short CNAME sailthru2._domainkey.news.example.com
dig +short TXT sailthru._domainkey.news.example.com
dig +short TXT sailthru2._domainkey.news.example.com
dig +short CNAME bounce.news.example.com
dig +short TXT bounce.news.example.com
dig +short TXT _dmarc.news.example.com
dig +short TXT _dmarc.example.com

Compare authoritative DNS with an independent recursive resolver. Both DKIM aliases must match their specified targets and resolve to usable public keys. The bounce alias must match its issued target; a recursive TXT query can expose the alias chain and resulting SPF policy. If an answer is blank, inspect the full DNS response and delegation instead of treating silence as success. Allow existing TTLs to expire, then recheck.

After activation, arrange an authorized fresh message through the real campaign path. Use a controlled external recipient and inspect the recipient system's trusted Authentication-Results. An earlier message predating activation cannot validate the new setup. Authentication-Results trust.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For every tested route, retain:

• The expected and received From domain.
• The actual MAIL FROM domain and its SPF result, with alignment recorded separately.
• Every DKIM signing domain and selector, identifying the intended branded signature that both passes and aligns.
• The DMARC result and mechanism supplying its pass.
• Test time, account, campaign/route and receiver, with unnecessary personal data removed.

Require the trusted receiver to report dmarc=pass, with the aligned mechanism identified. Also require the intended branded DKIM signature to pass and align, even if aligned SPF already supplies that DMARC pass. Conversely, a healthy aligned DKIM signature does not excuse SPF permerror, temperror, fail or softfail. Investigate and correct an actual SPF fault. A provider-envelope SPF pass that is unaligned is a different finding: if the expected bounce identity is absent, check activation and route provisioning rather than repeatedly editing apex SPF.

Repeat this process for different From domains and materially different transactional or campaign routes. Authentication readiness does not authorize immediate full-volume sending. Follow the agreed ramp plan and review complaints, consent and unsubscribe handling separately. Sailthru bulk-sender guidance.

Troubleshoot Sailthru authentication