Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Inventory both broadcast and thank-you mail
Engaging Networks authentication applies to the domains used by account email senders. Treat broadcast campaigns and thank-you messages as separate acceptance cases: their business triggers, templates and sender addresses can differ. Before editing DNS, list each configured sender and the workflow that uses it. A donation receipt or action confirmation should not become an untested side effect of a marketing change.
The current documentation points to Marketing Tools, Domain authentication. The listed domains come from account email addresses configured under Hello, Account Settings, Account Emails for broadcast and thank-you senders. Select the relevant domain's DNS instructions. Do not rely on a historical menu label or another account's screenshot as evidence of the current setup.
Make the provider-specific changes
The provider instructs administrators to include _spf.e-activist.com in the existing SPF policy, add the two enkey1/enkey2 DKIM CNAMEs pointing to masterkey1/masterkey2.e-activist.com, and configure the enbounce return-path CNAME. That bounce target depends on the account datacenter: e-activist.com for Canada or use.e-activist.com for US/US2. Confirm the current account instructions and datacenter rather than guessing from recipient geography.
After publishing and validating the records, enable the domain's DKIM and return-path checkboxes. These request final verification. Revalidate and inspect the indicators. The provider explicitly warns that its validation does not identify every SPF problem, such as excessive rules. Therefore, green checks are necessary product evidence but not a substitute for protocol validation or a message test.
Understand what the return-path CNAME does
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
A branded bounce namespace and a DMARC policy are different DNS responsibilities. The enbounce CNAME supports return-path processing. It is not a v=DMARC1 TXT policy and does not by itself establish that the visible From and SPF identity align under every mode. Retain the domain's independently managed DMARC policy and evaluate the actual message identities.
For example, a hypothetical campaign uses From updates@example.com and an authenticated envelope at enbounce.example.com. That is not an exact domain match. Relaxed alignment may recognize the same organizational domain; strict SPF alignment requires identical domains. A passing signature with d=example.com provides exact DKIM alignment independently. This is a synthetic explanation, not an observation of an Engaging Networks account. Do not change strictness simply because a dashboard labels return-path configuration as DMARC.
Publish records with a controlled DNS diff
References: RFC 1034 §3.6.2, RFC 7208 §3.2, RFC 7208 §4.6.4.
Give the DNS owner a change request with each full owner name, record type, target, previous data and TTL. Verify whether the DNS panel wants a relative label or a full name. Check that the enkey labels do not already carry incompatible data. A CNAME cannot simply be added alongside arbitrary existing records at the same owner; investigate the collision before proceeding.
For SPF, retain one candidate policy at the owner name. Add the required authorization before the terminal all mechanism while preserving other legitimate services. Evaluate the expanded lookup path and syntax, including the ten-term limit for evaluated include, a, mx, ptr, exists and redirect terms across nested SPF processing. A display containing the right include can still fail because another mechanism is invalid or a lookup limit is exceeded. Keep the earlier valid record ready for rollback.
Query authoritative DNS first, then observe recursive caching. The provider's propagation guidance is a planning estimate, not proof of correctness. If the published name has a doubled zone suffix, waiting longer only preserves the mistake. Save both the requested and observed records so the next operator can distinguish an account-setting issue from a DNS publication issue.
Test a real workflow, not only the configuration page
References: RFC 6376 §6, RFC 9989 §4.4.
Send a controlled broadcast and trigger the actual thank-you flow using approved test data and a documented sandbox or non-chargeable test mechanism. Do not submit a real donation or trigger an unapproved payment merely to produce a thank-you message. Retain the original messages without exposing donor or supporter personal information. At a trusted receiving system, record the visible From domain, envelope domain, all DKIM signing domains and selectors, and authentication verdicts. Include timestamps, account and workflow labels so the evidence is reproducible.
SPF success for an unrelated envelope is not aligned SPF. DKIM success for an unrelated signing domain is not aligned DKIM. DMARC needs an aligned passing path, not just two generic pass labels. If alignment works but delivery differs, investigate reputation, recipient filtering and content separately. Do not promise that authentication removes all spam placement.
Diagnose activation and recovery separately
If the DNS answers are correct but a signature is missing, confirm that the domain enablement request was completed and that the test sender belongs to that domain. If the bounce identity is unexpected, compare the account datacenter, target and return-path activation. Avoid replacing the DKIM records merely because an SPF path failed. Work from the failing identity outward.
When a launch must be paused, retain the old working sending configuration until the new one is tested. Do not disable domain-wide DMARC protection to conceal one incomplete integration. When retiring this service, check both broadcast and thank-you dependencies and queued traffic before removing authorizations or delegated selectors. Keep a documented owner for that decision.
This guide retains first-party documentary evidence, not a tested tenant configuration. No production DNS changes or received-message tests were performed. The acceptance worksheet remains to be populated by the operator, and human approval remains separate from editorial review.