For CleverReach campaigns, create a DKIM entry under My Account → Settings → DKIM, publish its generated TXT record, and use Verify to reach active status. CleverReach also documents the SPF mechanism include:spf.crsend.com; add it only within the appropriate existing SPF policy, not as a duplicate record. Finish by verifying that a delivered campaign authenticates the intended From domain.
On this page
- Define the campaign route
- Generate and publish the DKIM record
- Configure SPF without confusing identities
- Keep DMARC policy intact
- Activate and verify
- Troubleshoot by the failed check
- Frequently asked questions
Define the campaign route
This guide addresses customer-domain authentication for newsletters sent through CleverReach. The authenticated domain must be one your organization can administer. A working address on Gmail or Yahoo is not permission to configure those providers' DNS. Use a custom-domain sender and identify the DNS administrator before starting.
Do not confuse CleverReach with Clever Elements or another similarly named service. Do not apply these records to messages that bypass CleverReach entirely. Employee mailboxes are a separate route. Preserve their records; CleverReach authorization is not permission to alter an employee-mail route. For interpreting a delivered message, see EmailAuth's raw DKIM results versus aligned DKIM policy results.
Create a short campaign inventory: account, sender address, visible From domain, campaign or automation, DNS zone, and expected owner of the change. Note whether more than one business unit sends from the domain. Shared DNS does not mean every application has the same DKIM selector or signing configuration.
CleverReach has a separately documented transactional SMTP workflow. The public guide describes a beta enabled on request with separate transactional billing. That connection selects an existing DKIM entry or creates one. Do not assume a newsletter test proves that a separate SMTP connection selected the same entry. This article is not an SMTP credential or plan-eligibility guide; confirm the feature and connection in your own account if using that route.
The public DKIM setup article is not a plan comparison and does not establish regional or agency-wide inheritance rules. Apply the instructions in the account actually sending the campaign. If a setting is absent, confirm account permissions and supported functionality instead of inventing DNS values.
Generate and publish the DKIM record
CleverReach's Set up DKIM documents this sequence: profile icon, My Account, Settings → DKIM, then Add domain. The selector is optional at creation. Open the domain row's ••• → Show DNS settings, copy its TXT record and publish it at your DNS host.
Capture the generated owner and full public value together. Keep the complete tagged DKIM TXT value in one logical record. If DNS represents it as multiple character strings, the verifier concatenates their contents without inserting spaces; do not insert spaces into key material or split one key into independent TXT records. DKIM TXT key storage. The DNS shape is:
Type: TXT
Owner: ACCOUNT_SELECTOR._domainkey.SIGNING_DOMAIN
Value: Complete public DKIM TXT value generated by CleverReach
Those capitalized fields are placeholders. Do not literally publish them. Use the account's exact selector, signing domain and value rather than assuming a selector named default. Do not generate a replacement key pair independently: the public key must match the private signing key used by CleverReach.
For the fictional signing domain news.example.com and selector campaign1, the full owner would be campaign1._domainkey.news.example.com. A DNS panel managing example.com and appending that suffix would usually take campaign1._domainkey.news. If the panel manages the separately delegated news.example.com zone, its relative name would instead be campaign1._domainkey. If _domainkey.news.example.com is separately delegated, publish in its authoritative zone with relative owner campaign1. Preserve that delegation, existing selectors and DNSSEC; do not move nameservers to imitate a tutorial. The correct public owner, not how many labels you typed, is the acceptance criterion.
Do not put the DKIM TXT value at @. That symbol commonly means the current zone root; it is not a wildcard that publishes the key beneath every subdomain. General hosting examples in a help article must not override the account-issued DKIM owner.
Save unrelated selectors. Multiple DKIM selectors for different services can coexist because their owner names differ. Two incompatible keys at the same selector are not a safe way to support two platforms. If the requested owner already holds a CNAME or another service's TXT key, pause and resolve selector ownership before replacing it. Keep private keys out of DNS and support tickets.
Configure SPF without confusing identities
CleverReach's official SPF page publishes include:spf.crsend.com and tells customers with an existing policy to add that mechanism rather than overwrite the record. Its complete new-record example also includes a and mx; those mechanisms authorize additional hosts and should not be copied without confirming that authorization is intended.
For an owner that genuinely needs to authorize only CleverReach and has no existing SPF policy, a scoped illustrative policy is:
Type: TXT
Owner: The approved SPF domain for this sending route
Value: v=spf1 include:spf.crsend.com ~all
This is a conditional example, not a command to replace your root policy. If other systems send using that owner, merge the mechanism into the existing single policy before its terminal all. Preserve their authorizations and the current terminal policy unless the DNS owner approves changing it. Never publish a second v=spf1 TXT record at the same owner. An all mechanism causes redirect to be ignored, so adding all to a redirected policy can disable its intended authorization path. Review the evaluated design before merging. Preserve qualifiers; they do not guarantee delivery or rejection. SPF redirect semantics.
SPF checks the SMTP MAIL FROM domain, or the HELO identity for a null reverse-path, not Reply-To or the display name. The visible From domain is a different identity. An SPF pass for CleverReach infrastructure does not automatically establish DMARC alignment with your business domain. Look at smtp.mailfrom in a delivered message before concluding that a root-domain DNS change affects the evaluated SPF identity. The SPF standard governs these semantics even where marketing explanations use looser language.
Do not confuse Settings → Domains with SPF authentication. CleverReach’s own-subdomain guide describes a CNAME to ssl.cleverreach.com for tracking and opt-in confirmation links. That web-link branding workflow does not establish a custom SMTP envelope sender or prove SPF alignment. Use delivered-message headers to identify the actual envelope domain, even when branded links work correctly. If separately implementing the tracking alias, use the issued web-link configuration, not an invented DKIM CNAME. Where this route requires a literal CNAME answer, use DNS-only rather than HTTP-proxied records. In Cloudflare, turn the applicable per-record Flatten control off when available and ensure applicable zone-wide flattening does not conceal this alias. Review other dependencies before any zone-wide change, not a blanket disable. Apex or same-zone behavior can impose flattening; if the required alias cannot be preserved, stop and agree a supported hostname/design with the DNS owner and sending provider, rather than inventing a switch. Do not add conflicting TXT, A, AAAA, MX or another CNAME at that owner, or delete an NS delegation to make the example fit. Cloudflare verification guidance, applicable flattening controls.
Check the ten evaluated DNS-querying-term limit, including nested include, a, mx, ptr, exists and redirect, before expanding any policy. ip4, ip6 and all do not consume that term budget. Do not count only the number of visible includes or flatten dynamic provider addresses into a permanent IP list without a maintenance plan. DKIM configuration should not become an excuse for unrelated SPF rewrites.
Keep DMARC policy intact
First inspect the existing policy for the actual From domain and its applicable parent policy. A campaign using news.example.com may inherit protection even when _dmarc.news.example.com has no local record. Do not add a weaker local policy merely because an authentication wizard does not display the inherited one.
For an otherwise unprotected domain, an owner-approved monitoring rollout could begin with:
Type: TXT
Owner: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace both the domain and reporting address. The mailbox must exist, be approved for reports and have someone responsible for reviewing them. A root-zone DNS editor commonly uses _dmarc as the relative owner. A deliberate policy for news.example.com would instead use _dmarc.news.example.com as the full owner: _dmarc.news in the parent zone, or _dmarc in a separately delegated news.example.com zone.
Keep exactly one DMARC policy record at a given owner. Preserve existing enforcement, reporting recipients, subdomain policies and alignment modes. p=none is monitoring rather than a blocking policy; it is not a fix for a broken key. Compare the Organizational Domain of the domain where the DMARC policy was found with that of the aggregate-report URI host. If they differ, the report-generating receiver must check the destination's DNS authorization; a destination within the same Organizational Domain is excepted, even if the hostnames differ. External reporting authorization, RFC 9990 section 4. That protocol permission is separate from the domain owner's approval to share report data with the recipient. Retain approved destinations and privacy controls; do not copy another organization's reporting address.
Passing aligned DKIM or passing aligned SPF can satisfy DMARC. Relaxed alignment allows domains within the same organizational domain; strict alignment requires an exact match. For a hypothetical visible From news.example.com, a passing signature with d=example.com aligns in relaxed mode but cannot align in strict mode. A passing d=news.example.com exactly matches that From domain in either mode. These are illustrative identity comparisons, not measured campaign results. RFC 9989 is the current DMARC standard, replacing RFC 7489; new configurations should not use the removed pct tag.
Activate and verify
Return to the DKIM domain row and select ••• → Verify. Current CleverReach documentation says successful verification displays a status checkbox and changes the domain to active automatically. Older screenshots may show Check and a separate activation step. Check the actual final active state rather than stopping at DNS publication. The official guide allows up to 48 hours for DNS availability.
Run public DNS checks with the actual generated names:
dig +short NS example.com
dig +short TXT ACCOUNT_SELECTOR._domainkey.SIGNING_DOMAIN
dig +short TXT ACTUAL_SPF_DOMAIN
dig +short TXT _dmarc.example.com
Expected observations are the intended authoritative provider, the exact generated public key, one applicable SPF policy where queried and the intended DMARC policy. Long TXT output can contain multiple quoted strings belonging to one record; that is not automatically multiple separate policies. If queries disagree with the dashboard, compare authoritative responses and an independent public recursive resolver before editing again.
Next, send an authorized campaign to an independent mailbox you control. Use the intended production sender, not merely a preview with different settings. Open full headers and locate the receiving system's trusted Authentication-Results. Use only results generated inside the receiving service's known processing boundary. Establish that boundary from the service's documented removal or isolation of externally supplied Authentication-Results, or use its authenticated message diagnostics/logs. A familiar authserv-id string or a header's position alone proves nothing; ignore attacker-inserted or otherwise untrusted result fields. Receiver trust and forged results.
Record the From domain, envelope domain, DKIM d= and s=, and the receiver's results. For release, require the expected sender identity, a passing aligned DKIM signature and dmarc=pass; also record whether SPF passes and aligns. A configuration can pass DMARC through DKIM when SPF is unaligned, but that distinction must be documented rather than hidden behind “all green.” Investigate actual SPF fail, softfail, temperror or permerror even when aligned DKIM permits DMARC to pass. Separate forwarding effects from direct-route authorization failures, and resolve policy syntax or DNS lookup problems rather than treating DKIM success as proof that SPF works. An SPF fail calls for sender-authorization and route review; permerror calls for policy syntax, duplicates and lookup-budget repair; temperror calls for temporary DNS/resolver investigation. A DMARC pass through SPF alone does not finish this branded-DKIM setup, and a rewritten provider From is not successful authentication of the intended brand. Repeat for materially different sender domains and SMTP connections.
Troubleshoot by the failed check
The key is visible in the account but absent publicly: verify that the edited DNS zone is authoritative. Then check duplicated suffixes, a root-owner mistake and whether the key was truncated during copying.
The account says active but the signature uses another domain: check the campaign's selected sender, account and route. A successful setup for one domain cannot authenticate an unrelated address. Inspect whether CleverReach rewrote the sender; its DKIM documentation describes sender replacement when requirements are unmet.
DKIM passes but DMARC fails: compare the passing signature domain with the visible From domain under the actual alignment mode. Do not change p=reject to p=none just to conceal a strict-alignment mismatch.
SPF returns permerror: check duplicate SPF policies and lookup depth. Adding yet another SPF record compounds the problem. Preserve legitimate senders while fixing the malformed policy.
Only forwarded messages fail SPF: compare direct-delivery results first. Forwarding changes the connecting server; a surviving aligned DKIM signature may still permit DMARC to pass. Do not authorize the forwarder's entire infrastructure without understanding the route.