Salsa Labs SPF, DKIM and DMARC setup, step by step

For Salsa Engage email blasts, series and autoresponders, the documented SPF authorization is include:salsalabs.org, and custom DKIM is generated in Settings > Switch to > DKIM for the From domain. Publish the issued TXT record, run VERIFY and allow the provider’s activation step to finish. Pending means the record was recognized, not that branded signing is already active. Bonterra’s Engage authentication instructions.

This guide applies to Salsa Engage, formerly under Salsa Labs and now supported by Bonterra. It does not provide interchangeable settings for Salsa Classic, unrelated Bonterra products or a separate CRM mail route. The instructions below have not been executed in a customer account or tested against customer DNS or messages.

Inventory the Engage messages and domains

Build a short sender inventory before changing DNS. A blast and an automated receipt may use different From domains even within one account. Verifying one does not verify the other.

Use an organizational domain for which the DNS administrator can publish records. Have the account administrator generate the DKIM data and the DNS administrator publish it. Preserve the existing SPF, DMARC, DKIM and routing records first. Include staff mail, other fundraising systems and website notifications in the inventory so a change for Engage does not disrupt them.

If another product is involved, obtain its own current instructions. A shared Bonterra login or corporate owner does not establish a shared Return-Path, selector or activation process.

Generate the custom DKIM record in Engage

In the documented Engage controls, open the Settings tool icon, choose DKIM from Switch to, add the exact From domain and copy the generated record. The published setup uses TXT, not a generic CNAME. Its text preceding the record type identifies the owner; the value contains the public key. Use the current account output, never a selector or key copied from a screenshot. Official custom-DKIM workflow.

Prepare a change worksheet containing:

• The Engage account and intended From domain.
• The complete owner, normally in the form selector._domainkey.signing-domain.
• The record type, complete public value and TTL.
• The intended signing domain and account-issued selector.
• The person who will verify the record in Engage and confirm subsequent signing.

selector is a placeholder, not a literal selector. Do not invent the missing underscore in a transcribed example or assume a historic screenshot is the record for your account. Compare the actual generated full owner with the standard DKIM lookup form and resolve any discrepancy with support before publishing. DKIM verifiers use the message’s s= selector and d= signing domain to locate its key. DKIM key lookup.

Publish only the public DNS value. Private signing keys are not needed by the DNS administrator. If the requested owner already contains another key or a CNAME, establish what uses it before changing anything. Independent senders can have separate selectors; removing another sender’s key is not part of authenticating Engage.

Publish at the right apex, child or delegated zone

A From domain of example.com and a From domain of news.example.com are distinct inputs. The record for one is not automatically the generated record for the other.

The table below shows illustrative DNS-name mapping, not production values:

Confirm which DNS service is authoritative. A delegated child’s records belong at the child’s DNS host. If the console automatically adds the zone suffix, do not create a duplicated owner such as selector._domainkey.news.example.com.example.com.

At an existing delegated _domainkey.news.example.com authority, full owner selector._domainkey.news.example.com maps to relative selector. Use the actual account-issued selector and TXT value, preserve the NS delegation and other selectors, and never publish private signing material. Relative names.

Keep the entire TXT value intact. Long TXT data may use several character strings inside one resource record; that is different from creating multiple SPF policies or splitting a key into unrelated records. Follow the DNS host’s quoting rules. DNS TXT structure.

Do not change MX records, nameservers or unrelated website records for this task. Although this Engage workflow issues TXT data, check any existing alias collision: a CNAME owner cannot also hold ordinary TXT data. Resolve the owner conflict rather than deleting the alias without knowing its purpose. DNS CNAME rules.

Merge SPF without breaking existing senders

Use the Engage-specific fragment:

include:salsalabs.org

This is not a standalone DNS record. Add an approved fragment to the appropriate existing SPF policy, before its terminal all, without replacing the rest of the sender inventory. Do not reuse a Salsa Classic include. Bonterra documents the .org mechanism for Engage and warns about multiple SPF records. Engage SPF configuration.

For example, if a controlled owner has only the illustrative sender below, a merge would have this shape. These documentation-range IPs are examples, not addresses to publish:

Before: v=spf1 ip4:192.0.2.10 -all
After: v=spf1 ip4:192.0.2.10 include:salsalabs.org -all

Keep the existing approved qualifier; changing -all to ~all is a policy decision, not a requirement for adding Engage. If the policy uses redirect=, have the administrator review its evaluation order before adding mechanisms. Do not add mx merely because a sample contains it. That would authorize servers for a separate reason that may not fit your environment.

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.

SPF evaluates the SMTP MAIL FROM domain, usually reflected in Return-Path, not the displayed From address. Bonterra’s From-address validation is useful configuration feedback, but it does not prove the delivered envelope uses that same domain. Inspect smtp.mailfrom at a trusted receiver. No customer-configurable branded Return-Path process was established by the public Engage instructions reviewed here; do not invent one or assume the apex include creates SPF alignment. SPF identity rules.

Evaluate the complete SPF policy, including nested dependencies, against the ten DNS-lookup-term limit. It is not simply a maximum of ten include statements. Nor is 255 characters the maximum total SPF policy length: that is the maximum size of an individual DNS character string. One owner must not publish multiple applicable v=spf1 records. SPF records and evaluation limits.

Finish verification and signer activation

After publication, query the intended public owner and compare the complete returned key with the generated data. Bonterra advises allowing up to 24 hours for DNS changes, then using VERIFY. Recognition changes the status to Pending; the documented server-side update happens overnight. Verification and activation timing.

Treat that interval as a planning estimate, not a guarantee. If authoritative DNS is wrong, waiting will not fix it. If DNS is correct but activation remains unclear after the expected cycle, ask support to confirm the domain’s signing status and use a new controlled message to verify it. Do not schedule the next major appeal on the strength of Pending alone.

The Sender Details indicators in an email blast provide another account-level check. Bonterra’s DMARC guide also calls for inspecting a received message, including Gmail’s Show Original view. Neither a green icon nor a successful lookup replaces the domain comparison in the actual headers. Engage DMARC verification.

Retain DMARC policy and useful reporting

DMARC passes when SPF or DKIM both authenticates and aligns with the visible From domain. For DKIM, compare the passing signature’s d=/header.d; for SPF, compare the authenticated MAIL FROM domain. Relaxed alignment accepts the same organizational domain. Strict alignment requires an exact match under adkim=s or aspf=s. Aligning two DNS records is not the test. DMARC identifier alignment.

Find the effective policy for the actual From domain, including applicable parent-domain policy. Do not blindly put every policy at the apex, and do not add a second DMARC record where a policy already exists. Preserve existing enforcement and reporting destinations unless their owners approve a change.

If there is no established applicable policy and you are beginning a monitored rollout, this is an illustrative starting shape only:

Before publishing this first policy, obtain the domain owner’s explicit approval of the monitoring rollout and review plan. Confirm that no direct or applicable inherited policy exists; preserve any existing policy and use only an approved, provisioned reporting destination.

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

Replace the domain and reporting mailbox with approved values. For an externally hosted report destination, follow that service’s external-report authorization requirements. Assign someone to review the reports for unknown sources, changing volumes and failed authentication. Keep legitimate sender coverage in view before moving to enforcement. Do not weaken an existing quarantine or reject policy because one Engage domain is still activating.

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 the full apex DMARC owner _dmarc.example.com, enter relative _dmarc in the example.com zone. Existing child/delegated-child mappings remain separate; preserve applicable policy.

Bonterra’s DMARC guidance recommends reporting and a cautious initial policy. Use a clean record value rather than copying explanatory link markup from its examples. Aggregate reports are not limited to failed messages and are not an inbox-placement report. Forensic reports are a separate, privacy-sensitive option, not necessary for this setup.

Verify public DNS and each delivered message route

The commands below are read-only examples. Replace the illustrative zone, authoritative server and selector with the actual values. For a delegated child, use that child’s authoritative server.

dig +short NS example.com
dig @ns1.example.net selector._domainkey.example.com TXT +noall +answer
dig +short TXT selector._domainkey.example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com

Confirm that authoritative and recursive answers contain the expected full key and policy values. Query the actual MAIL FROM domain’s SPF as well, even if it differs from the From domain. Diagnose NXDOMAIN, empty responses, SERVFAIL, duplicate SPF records or a wrong suffix before continuing.

After activation, use controlled recipients to obtain a new blast, a representative series message and a safely triggered autoresponder for each distinct sending domain. Read the original message at the receiver. Use the receiver-added authentication result, not an arbitrary Authentication-Results field copied into the message by its sender. Trusted authentication results. Establish trust through the receiving provider’s authentication display or its mail administrator’s confirmed boundary handling. A familiar authserv-id name or a header’s position alone does not establish that trust; both can mislead when untrusted results are retained. RFC 8601: forged authentication headers.

Require all of the following for this implementation:

1. The intended Engage route and approved From domain were actually used.
2. The expected branded DKIM signature has dkim=pass, the correct d= and s=, and alignment under the effective adkim mode.
3. The receiver records dmarc=pass for the expected From domain.
4. SPF is evaluated for the observed smtp.mailfrom, with its result and alignment recorded separately.
5. Any actual SPF fail, softfail, neutral, none, temperror or permerror is investigated rather than dismissed because DKIM passed.
6. The reply address and intended automated-response behavior work without unintended supporter actions.

A provider-domain SPF pass that is unaligned can coexist with DMARC pass through branded DKIM. Conversely, dmarc=pass supplied by SPF does not prove that the requested custom DKIM deployment is complete. Keep untested routes explicitly pending.

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.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

Troubleshoot common Engage failures