Engaging Networks SPF, DKIM and DMARC setup, step by step

To authenticate Engaging Networks email, open Marketing Tools → Domain authentication, publish the displayed SPF and two DKIM CNAME records, configure the return-path CNAME for your account's datacenter, and enable both DKIM and return-path processing in Engaging Networks. Validate the domain again, then check a delivered message. The platform's return-path alignment check is not a substitute for publishing and reviewing your domain's DMARC policy. Engaging Networks domain authentication.

Choose the correct sender domain and account

This guide covers broadcast and thank-you email sent by Engaging Networks. It does not configure employee mailboxes, another fundraising platform, website hosting or SMS. Authentication belongs to the domain after @ in the actual From address. If you use appeals@example.org for campaigns and receipts@donations.example.org for thank-you messages, inventory both domains rather than assuming one setup covers the other.

The current domain list is populated from Hello → Account Settings → Account Emails, including the Broadcast email sender and Sender for thank you email types. Check these addresses before requesting records. An absent domain can mean the required sender address has not been added, not that DNS has failed. The documentation now uses Marketing Tools navigation; older instructions may refer to Email → Settings. Current sender-domain workflow.

Before editing anything, record:

• The Engaging Networks account and its Canadian, US or US2 datacenter.
• Every affected From address, message type and domain owner.
• The authoritative DNS service and zone, which may differ from the registrar.
• Existing SPF, DKIM, DMARC, inbound MX and records at the proposed CNAME owners.
• The person who will validate account activation and later inspect controlled test messages.

Export the current zone or save the exact affected records and TTLs. Plan a reversible change. Domain authentication is required for sending, but correct authentication alone does not promise inbox placement. Consent, complaints, recipient quality and content still matter. Engaging Networks deliverability guidance.

Add the Engaging Networks SPF authorization safely

Open the domain's authentication details and compare the requested values with your DNS inventory. Current official instructions specify include:_spf.e-activist.com. For a domain whose only authorized sender is Engaging Networks and which has no existing SPF policy, the documented pattern is:

Owner: example.org
Type: TXT
Value: v=spf1 include:_spf.e-activist.com ~all

Replace example.org with the configured sender domain. This is a single-sender illustration, not a replacement for an organization's existing policy. Do not copy additional IP ranges from somebody else's example. Official SPF configuration.

If that owner already has a TXT record beginning v=spf1, add the Engaging Networks authorization to that record before its terminal all mechanism. Retain other legitimate senders and the approved ending, such as -all or ~all. Do not publish a second SPF record or concatenate two complete policies. Other non-SPF TXT records can remain.

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 connecting server against the envelope MAIL FROM domain, normally visible in Return-Path and smtp.mailfrom, not simply the address people see in From. Publishing an include on example.org does not make SPF pass for an unrelated envelope domain. SPF is also not inherited automatically by subdomains. Keep the provider-requested sender-domain authorization, then validate the actual envelope identity used by the message. SPF identity and publication rules.

Count DNS-querying SPF mechanisms and modifiers across nested includes. The limit is ten evaluated lookup terms, not ten TXT records or ten IP addresses. Engaging Networks expressly warns that its domain validator does not detect every SPF problem, including excessive rules. A green tick therefore does not replace a complete SPF evaluation.

Publish both DKIM CNAME records

The current official configuration uses CNAME, not two TXT records containing pasted public keys:

Confirm these against the instructions displayed for your domain. Preserve both rows. Do not invent selectors, generate a replacement key pair or substitute another service's targets. The provider signs the mail; your CNAMEs let receivers locate its public verification keys. No private key belongs in public DNS. Engaging Networks DKIM records.

In a DNS zone for example.org, a host field that automatically appends the zone usually needs enkey1._domainkey, not the full hostname. For a sender domain of donations.example.org inside that same zone, it usually needs enkey1._domainkey.donations. In a separate donations.example.org zone, it needs enkey1._domainkey. Check the resulting full owner after saving to catch doubled suffixes.

If the actual _domainkey namespace is itself delegated, publish at that authority: for full owner ISSUED-SELECTOR._domainkey.news.example.com in the delegated _domainkey.news.example.com zone, the relative owner is only ISSUED-SELECTOR. This is a placement illustration, not a provider-issued selector or a new sending-domain assignment. Preserve the existing NS delegation, other selectors and exact issued record type/target. DKIM owner construction, relative DNS names.

At each CNAME owner, stop if conflicting TXT, A, AAAA, MX or another CNAME data already exists. Do not delete unrelated records simply to make the form accept your input. Resolve the ownership conflict with the DNS administrator. CNAME aliases generally cannot coexist with other data at the same owner. DNS alias rules.

If you use Cloudflare, keep these DKIM CNAMEs and the return-path CNAME below DNS only, not proxied. Do not flatten these authentication aliases: their CNAME answers must remain visible for verification and mail-related lookups. Cloudflare warns that flattening can hide the CNAME required by a third-party verifier. Scope this check to the authentication records; do not disable proxying or alter unrelated website records. Cloudflare proxy guidance, CNAME flattening and verification.

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.

Configure return-path alignment for the right datacenter

Engaging Networks documents the following alternatives. Publish only the one appropriate to the account, after checking its displayed instructions:

Use your domain instead of example.org. Do not choose a target based on the recipients' country. This alias concerns bounce processing and the envelope sender; it does not move your ordinary inbound mailbox service. Do not put an additional SPF TXT record at the enbounce CNAME owner. Datacenter-specific return paths.

For a From domain of example.org and a MAIL FROM domain of enbounce.example.org, SPF alignment can be relaxed because both share the organizational domain. They are not identical, so that pairing does not satisfy strict SPF alignment (aspf=s). DKIM alignment is evaluated separately against the signing domain in d=. DMARC can pass with either an aligned SPF pass or an aligned DKIM pass. Do not weaken an existing strict policy to conceal a failed setup. DMARC alignment.

Preserve or establish the DMARC policy

The platform labels a check “Return Path Alignment (DMARC).” That check does not itself create a policy at _dmarc. Inspect the TXT record at _dmarc.<From-domain> and any applicable parent policy before adding a record. For donations.example.org, inspect _dmarc.donations.example.org and the organizational policy at _dmarc.example.org; a missing child record does not mean no policy applies.

Keep established enforcement, subdomain policy, alignment modes and reporting destinations unless the domain's security owner approves a specific change. Publish only one DMARC policy at each policy owner. For a genuinely new policy with no established or inherited enforcement to weaken, an approved monitoring start can look like this:

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

The domain and mailbox are examples. Use an existing monitored destination authorized by the organization to receive these reports. If the destination belongs to an external reporting service, complete that service's external-report authorization. Do not add arbitrary third-party addresses, or failure-report recipients that may receive message-level information. DMARC aggregate reporting and destination authorization.

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 monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.org uses full owner _dmarc.example.org, or _dmarc relative to the example.org zone. From donations.example.org uses full owner _dmarc.donations.example.org: enter _dmarc.donations in the parent zone, but _dmarc in a separately delegated donations.example.org zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Review aggregate results for every legitimate sender before approving enforcement changes. An EmailAuth authentication review can help organize sender and alignment evidence; publishing a policy or obtaining a tool score does not establish how one campaign authenticated.

Enable the features and revalidate in Engaging Networks

After the DNS records are visible, return to the domain's authentication screen. Select both I wish to enable DKIM for [your domain] and I wish to enable return path for [your domain]. These controls notify Engaging Networks that the records are ready for final verification. Re-run validation and investigate any red X or alert. The official example shows three green ticks for fully authenticated status. Activation and validation.

The documentation allows up to 24 hours for DNS propagation. That is a planning allowance, not proof that waiting repairs a wrong record. If the authoritative answer is incorrect, fix the owner, type or value first. If it is correct but a recursive resolver still has the old answer, allow the relevant cache TTL to expire.

Verify DNS and a delivered message separately

The following are read-only examples. Replace example.org, any selector and the nameserver with your actual values before running them:

dig +short NS example.org
dig +short TXT example.org
dig +short CNAME enkey1._domainkey.example.org
dig +short CNAME enkey2._domainkey.example.org
dig +short CNAME enbounce.example.org
dig +short TXT enbounce.example.org
dig +short TXT _dmarc.example.org

Query an authoritative server and a public resolver when results disagree, for example dig @AUTHORITATIVE_NS CNAME enbounce.example.org and dig @1.1.1.1 CNAME enbounce.example.org. Substitute the actual authoritative server for AUTHORITATIVE_NS. Verify the two DKIM aliases, their resolving public keys, the datacenter-specific return path and a single applicable DMARC policy. An SPF TXT lookup through the bounce alias is a DNS check, not an SPF result for a particular message.

After activation, an authorized operator should send a message through each real workflow to a mailbox they control: at minimum broadcast and thank-you mail if both are used. Do not use a message sent manually from an employee mailbox as the test. Save the delivered raw source and use the destination system's trusted Authentication-Results, not an untrusted header copied inside a forwarded message. Authentication-results trust boundary.

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.

Acceptance requires:

1. The intended From domain and Engaging Networks sending route are present.
2. dkim=pass applies to the intended branded signing domain, aligned with From under the active adkim mode. Match d= and s= to the published record. A provider-only signature is not sufficient evidence of branded DKIM.
3. spf=pass applies to the actual MAIL FROM identity. Verify that return-path activation selected the expected domain, and assess its alignment separately.
4. dmarc=pass applies to the intended header.from domain.

DMARC may pass through one method while the other is broken. Treat unexpected missing or failed DKIM, SPF or return-path branding as an unresolved configuration issue even if DMARC passes. DKIM's selector-based lookup is defined in the DKIM specification.

Troubleshoot the result you actually see

If the message is rejected before delivery, retain the full SMTP response, UTC timestamp and campaign identifier. Redact supporter information before sharing evidence. A mailbox provider's rejection can concern factors other than authentication.

Documentation and verification limits

This is a documentary setup guide. No customer account, DNS zone, activation status, delivered message or inbox placement was tested. Account-displayed records and direct DNS and message evidence must confirm the implementation.