Clever Elements SPF, DKIM and DMARC setup, step by step

For Clever Elements, confirm domain ownership with your account's TXT token, publish cemsc._domainkey as a CNAME to dkim.cemsc.net, and separately enable DKIM sending in the account. Merge the documented SPF authorization into any existing policy, preserve DMARC protection and verify a fresh mailing's branded DKIM result. DNS publication and signing activation are separate steps. Clever Elements authentication, Domain ownership

This guide is for Clever Elements newsletter sending with your own From domain. It is not a CleverReach guide, a mailbox-hosting migration or an instruction to replace your website's DNS. A custom hyperlink domain is also separate from email authentication.

Identify the domain and existing dependencies

Start with the domain in the visible From address. For news@example.com, that is example.com; for news@updates.example.com, it is updates.example.com. Locate its authoritative DNS zone and the Clever Elements account that will send the mailing.

Save the existing SPF policy, DMARC policy and report recipients, ownership tokens and DKIM selectors. Record which applications use them. Other services' TXT verification records can coexist with your new verification token; they should not be removed just because both appear at the zone root.

If several teams share the domain, agree who owns the authentication changes and who will inspect reports afterward. A marketing change should not silently remove the support desk, transaction system or employee mailbox provider from the domain's working configuration.

Clever Elements states that outgoing mailings are already DKIM signed and separately offers association with your own sender domain. The existence of a default signature therefore does not prove that the branded From domain is authenticated. Check the signing domain, not merely whether the message contains a DKIM header. Default and custom DKIM

Confirm ownership with the account-issued TXT token

Retrieve the confirmation value from your own account and publish it as a TXT record for the domain being verified. The official ownership page gives a blank prefix, meaning the domain itself in that zone, and illustrates a mailing_sndcpt_... token. Use your issued value, not the example string. Ownership TXT instructions

Type: TXT
Owner: example.com
Value: EXACT_CONFIRMATION_CODE_FROM_YOUR_ACCOUNT

Replace both the example domain and placeholder. A DNS editor may call the root owner @ or leave it blank. Check the complete name after saving, especially when verifying a subdomain inside a parent zone. Do not merge the token into SPF or place it in the DKIM CNAME target field.

Clever Elements says recognition usually takes minutes, but can take up to 48 hours. Verify authoritative DNS first if the account does not recognize it. A token from another account or a record saved under the wrong name will not become correct by waiting.

Keep a note of what the ownership check establishes: permission to use that domain in the product. It does not show that a particular mailing was signed or that its envelope sender aligns with From.

Publish the DKIM alias without a record collision

The documented customer-domain DKIM record is:

Type: CNAME
Owner: cemsc._domainkey.example.com
Target: dkim.cemsc.net

Substitute your actual sender domain and compare with the current account instructions. In the example.com zone, the relative owner is cemsc._domainkey. For a From domain of updates.example.com managed in that parent zone, it is cemsc._domainkey.updates. Current Clever Elements DKIM setup

The target is a hostname, not a public key string. Do not copy an old key from a screenshot into a TXT record at the same owner. Resolving the CNAME lets the provider manage the key at its target.

For Clever Elements' DKIM CNAME, use the following DNS-host controls. Where literal CNAME answers are required, the end state is a DNS-only alias returning the exact issued target, without HTTP proxying or flattening hiding it. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.

A CNAME cannot coexist with ordinary TXT or address records at the same owner. If a prior record occupies cemsc._domainkey, identify its purpose and owner before changing it. Do not delete unrelated selectors elsewhere under _domainkey; different services can coexist by using distinct names. DNS alias constraints

For a separately delegated updates.example.com zone, the relative owner reverts to cemsc._domainkey. Avoid doubling the domain suffix. The saved full owner is the reliable comparison, not the text typed into a particular host's Name field.

If _domainkey.updates.example.com itself is delegated, the full owner cemsc._domainkey.updates.example.com is entered as cemsc in that zone. Preserve the NS delegation and other selectors, and publish with its actual authority rather than deleting the delegation. Do not change mailbox MX, forwarding or DNSSEC for this alias. DNS zone boundaries.

Enable DKIM sending in Clever Elements

After DNS is ready, enable DKIM sending in the optimization-options window or through the user account menu at the top right. The current primary instructions make this activation separate from the CNAME. They also describe automatic record checks and a sender-domain review in the user account. Activation and verification

An older support article asks customers to contact support for an account change. Follow the current self-service interface when it is available; if your account lacks the control or cannot activate, ask support to confirm the supported path rather than assuming the alias automatically enabled signing. Older support-assisted workflow

Check activation for the account actually sending the mailing. Record the status and intended sender domain together. An optimization warning disappearing is useful product evidence, but cannot prove the receiver verified the signature.

Merge SPF and identify the real envelope sender

Clever Elements documents include:cemsc.net and an illustrative policy that also contains mx:

Owner: example.com
Type: TXT
Value: v=spf1 mx include:cemsc.net ~all

Merge the include into an existing SPF record instead of adding a second one. Keep existing legitimate authorizations and the approved final qualifier. The mx mechanism authorizes the domain's MX hosts; use it only when those hosts are intended outbound senders, not simply because the example includes it. Clever Elements SPF documentation

The mx mechanism authorizes the applicable A/AAAA addresses of the mail exchangers resolved for its domain. Check those actual destinations against the approved outbound-sender inventory; receiving inbound mail alone does not make those hosts authorized campaign senders. SPF mx mechanism.

Use one v=spf1 marker and put required mechanisms before the terminal all. A policy containing two separate SPF records at the same owner is invalid; unrelated TXT records are not a duplicate-SPF problem. Evaluate nested includes and modifiers against SPF's ten DNS-query-causing-term limit. SPF record selection and lookup limits

If the existing SPF policy uses redirect=, reconcile its authorizations with the DNS owner before changing it. An all mechanism makes redirect ineffective regardless of their order; do not append all as an automatic merge step. SPF qualifiers express authentication results, not a guaranteed receiver delivery or rejection decision. SPF all and redirect processing.

SPF checks the SMTP envelope MAIL FROM domain, normally reported as smtp.mailfrom, rather than the visible From address. The older provider explanation describes provider-domain bounce handling, but does not establish a current universal custom Return-Path option. Inspect an actual mailing before deciding whether its SPF result aligns with your domain. Provider bounce-domain background

A passing provider-domain SPF result can coexist with unaligned SPF. Adding the include to the root domain does not change MAIL FROM. Conversely, an actual SPF failure is not merely an alignment issue: investigate the evaluated policy, connecting sender and DNS behavior.

Apply DMARC without copying the older percentage recipe

Check the From-domain policy and any applicable inherited protection first. Preserve existing p, alignment settings, reporting addresses and subdomain decisions. Do not overwrite an established policy or add a second policy just because an authentication panel suggests a starter value.

Clever Elements' authentication article still presents a percentage-based pct rollout and includes ruf in examples. Current DMARC, RFC 9989, removes pct. Do not assume pct=10 limits the impact of a new rejecting policy. Failure reporting is also not a mandatory setup ingredient; consider its data exposure and operational need before adding a ruf destination. Provider example, Current DMARC specification

For a domain with no existing or inherited policy, an approved monitoring start could be:

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

Use a real, approved mailbox or reporting-service destination. For From example.com, the relative owner is _dmarc. For a deliberate policy at _dmarc.updates.example.com, enter _dmarc.updates in the parent example.com zone or _dmarc in a separately hosted updates.example.com zone. Do not use a new child policy to weaken inherited enforcement casually.

DMARC passes when SPF or DKIM passes and its authenticated identity aligns with From. Relaxed alignment permits a common organizational domain; strict aspf=s or adkim=s requires an exact domain match for that mechanism. p=none requests monitoring rather than quarantine/rejection of failures.

Verify that aggregate reports reach the intended service and review legitimate sending sources before enforcing. Restrict report access and document who investigates new sources. DMARC aggregate reporting

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is 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 the policy domain is excepted; a different hostname alone does not make it external. Follow the reporting service's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS and the CNAME's final key

Replace the example domain in these read-only commands. They assume the sender is example.com; adjust the complete selector owner for a subdomain sender:

dig +short NS example.com
dig +short TXT example.com
dig +short CNAME cemsc._domainkey.example.com
dig +short TXT dkim.cemsc.net
dig +short TXT _dmarc.example.com

The root TXT answers should include your exact ownership token and, if configured there, one complete SPF policy. The selector CNAME should point to the documented target; the target must return usable DKIM key material with a nonempty p=. Finding only the alias does not establish that the key can be retrieved. DKIM key lookup

Compare the current key resolution with the current provider setup, not a historical public-key screenshot. If the target fails, retain the alias and investigate the target's DNS availability or ask the provider for guidance. Do not invent a replacement key.

If +short is blank, repeat the lookup without it to inspect the status. A DNS timeout, SERVFAIL and NXDOMAIN have different causes. Compare authoritative and recursive responses; allow caches to expire only after the authoritative answer is correct. Then recheck the product's domain status and activation.

Prove branded DKIM on a real mailing

Generate a fresh mailing after activation through the actual sending account and From domain. Use a controlled recipient where raw headers are available. If campaigns and automations use different domains or settings, test them independently. A test of another account or an old mailing does not validate the changed configuration.

Read the trusted receiver-added Authentication-Results. Record spf with smtp.mailfrom, the intended dkim result with header.d, and dmarc with header.from. Identify the signature's s= selector and d= domain in DKIM-Signature. A sender can insert misleading earlier authentication fields, so use the results from the receiving system you trust. Authentication-Results trust boundary

Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Reject attacker-supplied or otherwise untrusted fields; obtain the receiver's own diagnostic evidence when provenance is uncertain. Operational receiving-result trust.

Complete acceptance requires:

• The intended Clever Elements account and branded From domain were used.
• The intended branded DKIM signature passes and aligns under the published adkim mode. Default provider signing alone does not meet this requirement.
• The receiver reports dmarc=pass for the intended From domain.
• The actual SPF result and envelope identity are recorded and explained. An unaligned provider-domain pass is distinct from fail, softfail, permerror or temperror.

Investigate an SPF error even if DKIM allows DMARC to pass. Mark unresolved authentication defects as open rather than declaring the whole setup healthy. Retain redacted headers, route and timestamp; do not share confidential message content with public tools.

Troubleshoot Clever Elements-specific failures

Ownership token not recognized: verify the token's account, exact domain and full DNS owner. Ensure it is a separate TXT record, not text appended to SPF. Check authoritative answers before waiting up to the documented recognition window.

CNAME correct but branded signature missing: check the separate DKIM activation control and the actual sending account. If the control is unavailable, seek provider confirmation. A DNS record cannot force a server to sign.

Only a provider-domain DKIM signature passes: do not count that as branded acceptance. Check whether custom signing was enabled for the correct From domain and send a fresh sample after correction.

SPF permerror: count SPF policies, validate syntax and evaluate nested lookups. Do not delete the ownership token: its different prefix means it is not an SPF policy. For fail/softfail, investigate the connecting source and evaluated MAIL FROM domain; for temperror, inspect DNS failures. Escalate provider-owned policy problems with redacted results.

DMARC fails despite SPF pass: compare the envelope and signing domains with From. Do not try to repair identity misalignment by adding duplicate includes or weakening an enforcing policy.

Tracking domain works but authentication fails: the hyperlink configuration serves links, not DKIM. Its documented target, ea.celnk.net, is not the target for the DKIM selector. Hyperlink-domain documentation

Documentation and testing limits

No customer account was activated, DNS changed or mailing sent for this guide. Validate your own account, public records and delivered headers. Authentication does not guarantee inbox placement.