Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Evidence scope: provider instructions below use hash-verified first-party captures retained with the original manuscript. The technical page displays a May 2024 update; its capture reports crawling last month, while the DMARC capture reports two weeks ago, relative to capture time. Later access exposed a login redirect, so this review does not claim a current signed-in walkthrough. Confirm the current Engage controls and account-issued records before implementation.
Confirm the Salsa product and actual message type
This guide is scoped to Salsa Engage. The first-party technical article describes Engage settings and messages, so its procedure must not be presented as verified instructions for Salsa Classic or every product sold under the Salsa Labs name. If the account uses another product, identify it first and obtain the applicable setup guidance. A shared company name is not enough to establish a shared signing workflow.
Inventory the visible From addresses used by email blasts, series messages, and autoresponders. These can represent different teams or subdomains within the same nonprofit. Record the approved sender and reply owner for each, as well as the real workflow that generates the message. A successful blast test should not close the acceptance record for an automated response that uses another identity.
Salsa's technical guide supports custom DKIM signing for the domain of those From addresses. It also documents the SPF mechanism include:salsalabs.org. Use this Engage-specific first-party source instead of selecting a similarly named include from a third-party article. Salsa technical configuration
Prepare a controlled domain change
Ask the domain administrator to identify the authoritative DNS service, current SPF policies, existing DKIM selectors, and DMARC policy. Preserve a before-change export or equivalent record. The person who edits the nonprofit's website is not necessarily the person who controls DNS; confirm ownership before deciding who will make the change.
Choose an address on a domain the organization controls. Ensure replies go somewhere monitored, especially when the message concerns donations, events, or advocacy. Authentication does not establish consent to send a campaign, nor does it establish that an address can receive replies. Keep those business checks in the plan without conflating them with DNS verification.
Plan tests that do not create an actual donation or send an unintended advocacy message. Use a designated test path and harmless information. Where an autoresponder is tied to a consequential action, agree on a safe way to trigger it. Retain the workflow reference so a second administrator can reproduce the test without relying on private supporter details.
Generate and publish the Engage DKIM record
The documented Engage route is the Settings icon, then the Switch to menu and DKIM. Add the exact From domain. Salsa supplies a TXT record whose owner and public value must be entered into the corresponding DNS fields. Use the generated record rather than a selector shown in a screenshot. Salsa technical configuration
Record the full owner name, record type, public value, TTL, issue time, and account association. The DNS administrator should check how the console expands owner names. A value that is correct in a provider example can still be published under the wrong name if the DNS console adds the domain twice. After saving, query the intended public owner rather than merely rereading the editor.
Keep the DKIM public record distinct from private signing material. There is no need to request or upload a private key to complete the documented public-DNS step. If existing data already occupies the generated owner, stop and reconcile it with the current account configuration. Do not overwrite another working sender's key just because its name resembles the new one.
The provider says VERIFY recognizes the TXT record and can show Pending before later server-side activation. That is an important intermediate state. Wait for current provider confirmation and a newly received signed message before treating configuration as complete. A propagation estimate is planning guidance, not a guarantee for a particular DNS service or send. Salsa technical configuration
Review SPF without copying the whole example
Assess include:salsalabs.org against the account's actual sending route and preserve the existing SPF policy. The organization's staff mail, fundraising platform, and website notifications may already rely on authorized mechanisms. Do not publish a second applicable SPF record or replace the entire policy with a one-service example. Confirm that any added permission is at the domain actually evaluated for the relevant SMTP identity.
Use RFC 7208 for technical limits. The DNS-lookup limit is not simply a count of visible include words, because other mechanisms and nested evaluation matter. A DNS TXT record can contain multiple character strings, so a blanket 255-character total-policy limit is also misleading. Do not copy unnecessary mx permissions from a sample or imply that an SPF failure forces every receiver to take the same action. SPF RFC 7208
Salsa's older explanatory text simplifies some of these points. Preserve its provider-specific configuration facts while using the standard for protocol interpretation. A reader should be able to distinguish a supported include from an oversimplified general rule. This is why the article does not reproduce a complete production SPF record or promise that authentication guarantees inbox placement.
Confirm the actual identity and DMARC result
Salsa's DMARC article points to Sender Details checks in an email blast and recommends inspecting a received message. Use those account indicators as one piece of evidence, then preserve the original at a receiver you control. Record the exact From domain, envelope domain, all DKIM signing domains and selectors, and trusted SPF, DKIM, and DMARC results. Salsa DMARC guide
The DKIM d= value names the signing domain, while s= identifies the selector used to locate its public key. A signature can pass for a service-owned domain without establishing authority for the nonprofit's visible From domain. Compare the actual domains rather than recording only the word pass. DKIM RFC 6376
DMARC evaluates whether a passing authentication path aligns with the visible From identity. Use the effective policy and current discovery and alignment rules, including any relevant subdomain policy. Do not describe DMARC as merely matching two DNS records or require every deployment to publish policy only at the apex. DMARC RFC 9989
Review the existing organizational policy before adding or changing a DMARC record. An older sample containing reporting tags is not a complete modern rollout plan. Select an approved aggregate-report destination, check who will review the data, and avoid copying obsolete or unexplained parameters. Do not weaken an established enforcement policy solely because one Engage domain has not completed activation.
Diagnose failures at the correct layer
If Engage does not recognize the record, compare the issued owner and public value with the authoritative answer. Check for duplicated domain suffixes, an incorrect selector, quoting mistakes, or changes made at a DNS service that is not authoritative. Retest after the published TTL and relevant cache conditions, while preserving the original failure evidence.
If the record is recognized but the message lacks the expected signature, check the exact From domain and provider activation state. Do not assume that Pending is the final signing state. If DKIM passes but DMARC fails, inspect alignment and the policy being applied. If both pass but a supporter still cannot find the message, investigate the specific receiver response or suppression condition rather than repeatedly editing DNS.
Repeat a representative test for each released blast, series, and autoresponder sender. Record any route that was not safely testable as pending. A release may be deliberately limited to the verified workflows; it should not imply that unrelated or inaccessible workflows were validated.
Fictional example of premature release
A fictional charity configures news@charity.example for its monthly blast. The DNS check succeeds and Engage shows Pending, so the team schedules a campaign. In this invented scenario, a test message sent before activation lacks an aligned signature. The successful lookup did not prove active signing.
The administrator pauses the cutover, confirms activation, and reruns the message. They also discover that an event autoresponder uses events@events.example and needs its own domain review. The correction is a complete sender inventory and real-message evidence, not a global DMARC downgrade. These domains and results are fictional teaching examples.
Implementation worksheet and release limits
- Product: confirmed Engage account, responsible owner, and excluded Classic or other routes.
- Sender inventory: blast, series, autoresponder, approved From domain, reply destination, and safe trigger method.
- DKIM: generated owner and public TXT value, DNS change reference, verification state, and activation evidence.
- SPF and policy: existing record, approved include change, lookup review, effective DMARC policy, and reporting owner.
- Received evidence: workflow, timestamp, receiver, envelope identity, DKIM d=/s= values, authentication and alignment results.
- Recovery: last supported sender, pause decision, previous DNS values, and retest conditions.
The source retrieval includes readable first-party content, but live account configuration, DNS, received headers, screenshots, visual review, and human SME sign-off remain pending. This is an unpublished documentary candidate, with non-Engage procedures explicitly excluded until separately verified.