Separate Clever Elements domain ownership from authentication
Clever Elements publishes separate instructions for proving domain control and configuring email authentication. This guide covers those documented Clever Elements account workflows, not CleverReach or another similarly named marketing platform. The authentication article is dated April 19, 2024, and the ownership article March 19, 2024. Their product steps provide useful setup evidence, but their age requires a current-account applicability review, especially where the older DMARC advice differs from the current standard.
The domain-ownership guide directs the user to publish a TXT record containing the confirmation code from the account. Use that issued code rather than the illustrative code printed in the article. The check demonstrates control of the relevant DNS configuration; it is not a DKIM public key, an SPF policy or proof that a particular mailing authenticates. Keep each record's purpose explicit in the change request.
Identify the sender domain and existing dependencies
Before adding records, identify the actual sender domain used by the intended mailings and who manages its authoritative DNS. A domain used for web links may differ from the domain in the visible email author address. Clever Elements recommends a separate branded hyperlink domain alongside authentication, but that recommendation should not be treated as proof that link branding authenticates the sender. Review each function on its own terms.
Inventory existing SPF policy, active DKIM selector owners and the current DMARC policy before changing anything. Record other services that send with the same organizational identity so their authorization is not accidentally removed. If the chosen domain is a subdomain, review its actual policy and delegation rather than assuming every setting is inherited from the parent. No customer domain, mailing list or DNS record has been inspected for this manuscript.
Publish the documented DKIM alias and activate signing separately
The official authentication setup guide specifies a CNAME with prefix cemsc._domainkey pointing to dkim.cemsc.net for the sender domain. Confirm that this documented value remains applicable to the current account before publication. Compare the final fully qualified owner with the DNS editor's suffix behavior, and check whether any existing record at that name is still needed. Do not overwrite an occupied owner without understanding its dependency.
The guide explicitly requires enabling DKIM sending for the account after adding the record. It describes an optimization-options window and an alternative control in the user account at the upper right. DNS publication and that account setting are distinct steps. A correct alias cannot make an inactive signer generate signatures, and an enabled control cannot make a wrong alias validate. Record both the public-record evidence and the actual account state when an authorized operator performs the work.
A CNAME delegates the public-key lookup to the named provider target. It does not publish a private key, and no private material belongs in the acceptance worksheet. RFC 6376, sections 3.5 and 3.6.2.2 define signature fields and TXT key storage. Later message-level verification must use the actual signature domain and selector rather than assuming the existence of a familiar DNS prefix proves which key signed the message.
Merge SPF authorization rather than copying a whole example
The Clever Elements guide prints a policy containing mx, include:cemsc.net and a softfail all term. That is the provider's example, not a complete inventory of every legitimate sender for a real organization. Review whether its mechanisms match the actual authorized infrastructure. Do not create a second independent SPF record or remove existing mailbox and transactional services merely to reproduce the article's sample.
RFC 7208, sections 2.4, 3.2 and 4.6.4 identify MAIL FROM, describe multiple-record behavior and set limits on evaluated DNS-dependent terms. Assess the envelope identity used by the actual mailing route and its complete policy. Count nested dependencies along the evaluation path rather than treating each visible include as the whole lookup cost. Publishing an SPF include does not itself configure the application to use a particular envelope identity or guarantee alignment with the visible sender domain.
Reconcile the older DMARC recipe with current requirements
The 2024 provider article includes percentage-based rollout instructions and a pct tag in its sample DMARC records. RFC 9989, Appendix A.6 documents removal of pct from the current DMARC specification. Do not present that old recipe as a current-standard generator or assume a percentage will provide the intended rollout control across receivers. Review existing sender coverage and choose a transition plan based on current behavior and evidence.
The provider also illustrates reporting addresses and stronger policy choices. Those are decisions for the domain owner, not harmless defaults to copy from a setup page. Preserve an existing policy until its scope, legitimate senders and intended changes have been reviewed. Choosing a report destination entails data-sharing and operational responsibilities; this manuscript neither creates reporting records nor authorizes sending reports to a new recipient. The version string remains v=DMARC1 under the current standard, not an invented second version.
RFC 9989, section 4.4 explains alignment. A passing aligned SPF result or a passing aligned DKIM result can satisfy the authentication condition; the standard does not universally require both to pass. Two passing results for unrelated domains are not equivalent to alignment. Keep the provider's recommendation to configure several mechanisms separate from the normative evaluation rule.
Interpret the product’s checks narrowly
Clever Elements says its system detects whether the records are correctly set and removes the optimization notice in an unsent mailing's detail view when the check is satisfied. It also describes checking used sender domains in the user account. Those are useful account observations, but they do not replace trusted receiver evidence for the actual mailing route. A vanished notice is not proof of inbox placement or recipient engagement.
The ownership article gives an ordinary recognition estimate of minutes and a possible delay of up to 48 hours. Treat those as provider guidance, not proof that a wrong name or value will eventually work. A proposed acceptance exercise should retain the actual observation time and configuration state, then use a separately authorized harmless message to inspect signature and alignment results. No mailing, account toggle, DNS query or diagnostic upload has been performed here.
Fictional diagnosis: DNS was ready but signing was not enabled
A fictional publisher, Lantern Field Notes, adds the documented DKIM alias and its account-issued ownership TXT code. Its editor marks authentication complete because both records are visible in the DNS panel. The review finds that the DKIM sending control has not been enabled and that no receiver evidence exists for the intended sender domain.
The proposed correction is to separate ownership verification, key lookup, signing activation and message acceptance into distinct checklist items. It is not to replace the public key or tighten DMARC immediately. The example is fictional and contains no real subscriber information, provider result or executed test. It illustrates why DNS preparation alone cannot establish an active signing configuration.
Blank acceptance worksheet and release boundary
- Product, current account applicability and sender domain: ______
- Issued ownership TXT code reference and public verification result: ______
- DKIM alias owner/target and existing-record dependency review: ______
- Authorized DKIM sending activation and observed account state: ______
- Complete SPF policy and evaluated dependency evidence: ______
- Current DMARC decision, legacy pct review and reporting approval: ______
- Account check result and trusted received-message alignment evidence: ______
- Remaining exceptions, rollback owner and release decision: ______
Original implementation evidence, human subject-matter review, current source applicability, production-route testing, visual accessibility and owner release remain open. The broader catalogue requirement still needs authorized operational evidence. This guide does not claim that a live account is configured, that an old DMARC example remains current, or that authenticated mail is guaranteed to reach an inbox.