Start with a domain you can authorize
CleverReach's Set up DKIM guide describes a custom-domain workflow in the account settings. It is a useful starting point for authentication configuration, but the sender domain must be one the organization can legitimately administer. A marketing operator's access to the campaign interface does not automatically confer control of the DNS zone or approval to change organization-wide DMARC policy.
Identify the account, intended From domain, campaign category and DNS owner. If the team uses a public freemail address, do not attempt to publish records for that provider's domain. The guide discusses handling of freemail sender addresses, but that is not a substitute for an organization's own controlled sender domain. Plan any visible sender-address change with the communications owner so recipients are not surprised.
This manuscript covers the documented DKIM setup. It does not invent an SPF include value, assert that every CleverReach account has identical settings, or claim an implemented tenant has been checked. CleverReach Set up DKIM
Generate the domain and selector configuration
The documented navigation starts at the profile icon, then My Account, Settings and DKIM. Add the intended domain through Add domain. The guide also provides a selector option. Treat the domain and selector together as a specific configuration: a different selector leads a verifier to a different DNS key location, even when the author address remains unchanged.
After adding the domain, use the action menu to Show DNS settings. Copy the generated TXT record from that domain's settings rather than borrowing an example from another account or assuming a conventional selector name. Preserve the displayed owner name, type and complete value in the change request. Record who generated the request and which account it belongs to, without including login credentials.
Selectors help distinguish DKIM keys; they are not a promise that the same key can be reused across independent vendors or accounts. Before replacing an existing owner name, determine whether another active configuration depends on it. A collision needs a reviewed resolution, not an unexamined overwrite. Domain setup and DNS settings; RFC 6376, section 3.5
Publish the TXT value in the correct zone
The DNS administrator should map the generated owner name to the authoritative zone and the editor's conventions. Some interfaces append the zone name automatically; others accept a full name. Confirm the resulting published name rather than treating the visual field value as definitive. The record type in this CleverReach workflow is TXT; do not convert it to a CNAME simply because another service uses aliases.
Preserve the complete key value and inspect the final DNS representation. A TXT record can contain multiple character strings that an application combines; those strings are not the same thing as several independent records at the owner name. Copying quoted presentation text into a field that supplies its own quoting can also require provider-specific handling. Do not guess at editor behavior from a generic example. RFC 1035, section 3.3.14; RFC 6376, section 3.6.2.2.
The documentation includes examples for DNS providers, but the acceptance target remains the exact intended name and value. A root shorthand such as @ must not be described as a universal wildcard for every subdomain. In RFC 1035 master-file syntax, a standalone @ denotes the current origin, not every subdomain; a particular DNS editor may require different input. RFC 1035, section 5.1; Generated TXT instructions
Run verification and interpret the status narrowly
After publishing the record, return to the domain's action menu and select Verify. The guide describes the active status that follows successful verification. Keep this provider check distinct from the DNS publication itself. A saved DNS change does not prove that the service has checked it, and an unsuccessful check does not immediately justify replacing the key or creating another domain entry.
When a check does not succeed, compare the intended owner name, authoritative zone, complete TXT value and domain selection first. Then consider publication timing and cached data. The provider discusses propagation delays, but a stated waiting interval should not become a guarantee that an incorrect record will eventually fix itself. Retain the timestamp and exact status so a later check can be compared meaningfully.
The status concerns the configuration examined by CleverReach. It is not a delivered-message report and does not independently prove which domain a specific campaign signed with. This distinction is especially important when an organization has several sender domains or older scheduled campaigns. Verify and status guidance
Check alignment on the selected campaign route
The proposed final check is an authorized representative campaign message inspected at the receiving system. Record its visible From domain, DKIM d= domain, selector and trusted validation result. Compare the passing signing identity with the author domain using the applicable DMARC alignment mode. Do not infer alignment merely because both domains contain the organization's brand name.
SPF and DKIM are separate authentication mechanisms. DMARC can use a passing aligned identity, but a DKIM setup article does not establish the full SPF configuration of every product route. If SPF needs review, obtain the actual envelope identity and current provider instructions rather than adding a guessed include at the root domain.
A passing aligned message establishes evidence for that sample and route. It does not promise inbox placement, engagement, consent quality or safety of the message's business request. Keep delivery observations and content-risk decisions in their own workstreams. RFC 9989, section 4.4; RFC 7208, section 2.4
Acceptance worksheet for campaign administrators
Use this proposed worksheet to connect the configuration request to the final evidence. Complete it separately for each domain or materially different route.
- Domain ownership: name the account, intended sender domain, communications owner and DNS administrator.
- Generated configuration: retain the selected domain, selector and issued TXT owner/value from Show DNS settings.
- Collision review: identify any existing key at the same name and its active dependencies before changing it.
- DNS publication: record the approved change, expected fully qualified owner name and verification evidence.
- Provider verification: record the time Verify was requested and the actual returned status.
- Campaign sample: record the selected notification or campaign class and the observed author/signing identities.
- Release decision: name the reviewer, remaining gaps and rollback owner rather than marking all campaigns ready from one screen.
No account login, DNS publication or campaign transmission has been performed here. The worksheet is an original acceptance design, not a completed implementation record.
Fictional diagnosis: active domain, unexpected sender
A fictional membership organization configures DKIM for news.example and obtains an active status. Its next campaign is still scheduled with an older From address at events.example. The reviewer sees the active domain in the settings and initially assumes the campaign must align. The two observations concern different identities, so the conclusion is unsupported.
The proposed investigation begins with the campaign's configured sender and the received message's signing domain. The team checks whether the intended domain was selected for that route, then reviews the relevant alignment relationship. It does not delete the working news.example key to repair an unrelated campaign. The final handover distinguishes the verified configuration from the campaign that still needs evidence. This scenario is fictional and contains no executed DNS lookup or test send.