Identify the client and the domain together
Evalanche can be used across brands and customer clients. Begin with a matrix of sender address, actual domain, account or client, and mailing type. A domain configured somewhere in the system is not sufficient evidence that the intended client can use it correctly. Include inherited templates and automation routes in the inventory because a newly selected From address can create a different authentication requirement.
The Evalanche authentication guide, “DKIM entry” distinguishes global setup for multi-client use from settings in the corresponding customer client when operating for customers. Resolve that distinction with the administrator of your deployment. Do not assume that “global” is always safer or that a customer’s domain belongs in every client.
Define which identities the organization actually approves. List the mailboxes used for ordinary replies separately from the envelope identity used for delivery errors. A working reply address and a personalized tracking hostname do not determine whether a receiver will find an aligned DKIM or SPF result.
Prepare the scope and recovery review
Give each sender-domain object a business owner and a technical owner. Record which active campaigns and automations depend on it. Before editing a key or domain, capture the existing state and identify a controlled way to stop or postpone affected sends. Avoid discovering that a birthday or transactional-style event continues to send while an administrator is changing its authentication.
Review the authoritative DNS zone and any existing selector at the proposed name. If another service or client uses that owner, ask the responsible teams to resolve the collision. A new public key at the same owner can invalidate messages signed with the old key. Do not assume a freshly generated pair is an additive change.
This guide recommends using the product’s normal generation flow rather than manually handling secret keys. If an organization has an approved external-key process, keep it separate from routine domain verification. Only public verification material belongs in the worksheet or DNS change ticket. Never paste a private key into an ordinary support message or shared campaign document.
Generate the domain record in the correct context
In the authentication guide’s “Create DKIM entry” through “Check DKIM entry” sections, Evalanche documents Settings → Domain/DKIM → New, saving the sending domain, generating a key pair and publishing the displayed TXT record. Its documented owner pattern uses the ems selector. The page says signing is activated automatically and that the Valid status may take one to two days.
Record the complete DNS owner and public value shown by the actual account. Treat the documented selector pattern as context, not permission to invent a key or ignore account-specific output. Check the zone editor’s suffix behavior. A relative owner in one DNS interface may need a fully qualified name in another; what matters is the exact public lookup name ultimately produced.
Publish the complete value, preserving its characters. Where a DNS provider displays long TXT content as multiple strings, verify that the resulting answer represents the complete intended record. Do not truncate the key to fit a field or silently change the record type. Ask the DNS administrator or provider for a supported way to enter the issued value if the interface is unclear.
Capture public DNS evidence and application status independently. If the key is visible but the status has not updated, retain both observations and their times. If the application says Valid while a receiver cannot retrieve the corresponding key, inspect the actual d= and s= values used by the message rather than assuming the dashboard and message refer to the same domain object.
Review the published SPF authorization carefully
The guide’s “SPF entry” section publishes the authorization include:_spf.senders.scnem.com. Confirm that it applies to the actual service and domain before incorporating it into the policy. Preserve other required senders and evaluate the whole policy rather than replacing it with the page’s standalone example. There is no need to copy the example’s optional mechanisms merely because they appear beside the include.
The help page uses wording about reverse entries, but RFC 7208, sections 2.3 and 3 defines an SPF check on the SMTP MAIL FROM identity and publication using TXT. Do not create a PTR record as the SPF setup. Also do not assume that the domain after the visible From address is automatically the domain a receiver evaluated for SPF.
Before changing a policy, inspect a baseline message and record the receiver’s envelope-domain result. If the service’s envelope is unrelated to your From domain, a passing SPF result may not supply DMARC alignment. The documentation inspected here does not establish a universal self-service custom Return-Path setting. Ask support about the exact account and route if aligned SPF is a requirement.
RFC 7208 sections 4.5 and 4.6.4 cover record selection and the ten-term DNS lookup limit. Maintain one SPF policy at an owner, retain needed existing authorization and check nested includes. Stop for a policy redesign if the new dependency exceeds the evaluation limit; do not remove another business system simply to make the marketing sender pass.
Keep DMARC policy outside the campaign shortcut
The Evalanche page says no special application setting is needed for DMARC, then provides a DNS example in “Structure of an entry.” That does not mean the organization already has an effective policy or that the sample is suitable. Record the actual policy, alignment mode and reporting owner for your From domain before making changes.
Use RFC 9989, section 4.4 for the acceptance rule: at least one passing SPF or DKIM result must align with the visible From domain. An unrelated provider-domain signature is not enough. Under strict alignment, merely sharing an organizational domain is insufficient; exact-domain matching matters. Evaluate the identities under the policy that is actually in force.
Do not copy the provider’s quarantine or strict-alignment example over an existing policy. Policy enforcement and report destinations affect every sender in the policy’s scope, not only Evalanche. Preserve existing protections while investigating one campaign. Treat any proposed change as a separately owned and reviewed decision.
Test the real mailing types and templates
Evalanche’s “The first eMailing” guide, mailing types and Configuration distinguishes manual, event and trigger mailings and tells the operator to check sender authentication in the configured sender data. It also labels the described editor as legacy. Use the current account’s interface for the actual campaign; do not assume that a screen sequence in an older editor proves the current route.
Select controlled recipients and harmless content. For each material route, record the mailing identifier, client, template, configured From address and send time. Where a template inherits the sender, inspect the effective value after the campaign is created. A template review is useful but cannot replace evidence of what was actually delivered.
Read the final receiver’s trusted authentication results. Capture the visible From, Return-Path, every DKIM d= and s= pair, SPF result, DKIM results and DMARC result. RFC 6376, section 3.5 defines how the domain and selector identify the key lookup. Retain enough information to repeat that lookup without retaining unnecessary recipient data or message content.
Test both the external route and an internal recipient if internal filtering is a business concern. A local allowlist may change delivery behavior but does not validate the public authentication seen elsewhere. If the external test succeeds and the internal test fails, investigate the internal gateway using the same message evidence rather than changing good DNS records at random.
Work through failures by layer
If there is no intended signature, inspect the sender-domain object, client scope and effective campaign sender first. If the signature is present but cannot be verified, compare its lookup owner and public key with the account. If it verifies but DMARC fails, compare domains and alignment mode. Those are different problems with different fixes.
If only some mailings fail, compare their templates, domains, clients and downstream routes. A sender selected in one automation can differ from the manual campaign used during testing. If the body hash fails after forwarding or another gateway, investigate changes after signing rather than generating new keys reflexively.
Create a client-and-domain review record with columns for observations, evidence owner and next acceptance step. Include the effective From, client scope, inherited template, issued DNS record, receiver identities/results and recovery decision so these layers remain separate. Blank evidence is an open task, not a passing result.
Fictional worked example: the right key in the wrong scope
Fictional written case only: EV-01 stipulates an agency manual mailing with From agency@example.org and passing d=example.org. A customer trigger instead uses From offers@client.example, while the selected customer-domain object is unconfirmed and its DKIM/SPF results are unknown. The agency pass proves nothing about that trigger. The customer administrator must resolve scope and inherited sender settings, then collect evidence from that exact trigger. No deployment, key generation, DNS query or message was executed.
Close only after route evidence exists
Agree recovery with the campaign owner before a change. Pause affected sends when authentication is uncertain, preserve working selectors until their message-verification lifetime is understood, and restore only a reviewed prior state. Retest after a new brand, client, template sender, key or delivery gateway is introduced.
The live scope, account-issued values, public DNS, received-message identities and recovery procedure remain unverified in this documentary draft. Visual review, human SME approval and publication are pending. The procedure is a plan for producing evidence, not a claim that an Evalanche tenant has already been authenticated.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.