Plan around the documented approval process and date
Click's official Email Sending Domains guide, edited October 6, 2026, describes configuring domains in ClickDimensions Marketing Automation. It announces that, starting January 25, 2027, emails can be sent only from domains with Approved status. As of this guide's November 9, 2026 review, that is a future announced restriction, not evidence that the new enforcement has already occurred in a tenant. Confirm the applicable version, account and current provider notices before planning a change.
The guide says each domain used in a From Email Address must be covered, including domains used by different brands or regions. Inventory the actual From addresses on Email Send records and Send Email actions in Campaign Automations. Do not assume the organization's main domain covers every configured sender. Account readiness depends on the actual domain list and approval states, neither of which has been inspected for this manuscript.
Keep DNS verification distinct from Approved status
The documented sequence includes Waiting for DNS Verification, Waiting for Approval and Approved. After the DNS records are verified, the domain still goes through Click's Change Management process. The guide describes weekly changeover windows, potentially taking up to seven days, and says DKIM publication is anticipated one to seven days after the waiting-for-approval stage. These are provider scheduling statements, not a promise of immediate activation or an independently verified service-level commitment.
Plan the DNS work early enough to leave room for that approval process and any corrections. A green DNS check should not be entered as Approved unless the domain's actual status says so. Record the contact mailbox responsible for provider questions and make sure an authorized person monitors it. This article does not open a support ticket, submit a domain for approval or claim that any change window has been booked.
Enter domain and subdomain fields with the correct scope
Navigate to ClickDimensions Settings and Email Sending Domains. The guide describes a sending domain, a DKIM subdomain, an optional Email CNAME and a Contact Email. The subdomain fields take labels rather than complete fully qualified names. The DKIM subdomain must be unique to Click, not reserved for another service or purpose, and use a valid label without leading or trailing punctuation. The DKIM and Email CNAME subdomains cannot use the same label. Review existing web-content and social CNAME dependencies as well instead of choosing a convenient label without checking ownership.
The optional Email CNAME is for email links; it is not interchangeable with the DKIM subdomain. Keep link branding, return-path configuration and signing evidence separate in the acceptance record. Use the account's generated values for the intended domain. Do not copy another brand's labels or targets because it already has an Approved status. Approval belongs to the configured identity and its records, not to a reusable DNS template.
After saving, the guide describes a possible organizational-domain SPF change, two new MX records and five new TXT records. Record the entire issued set and the purpose of each owner. These are not instructions to replace the organization's ordinary inbound MX records at the root. Review the exact generated owner names and routing dependencies with the DNS administrator before making any change.
Preserve the provider’s DNS formatting instructions
The guide warns about copy-and-paste formatting of its gears._domainkey entries, including line breaks, spaces and quotation marks introduced by email clients. It also says its three DKIM TXT values are 225, 225 and four characters and should be created without concatenation. Apply those instructions to the actual issued records rather than merging them into a single invented key value or assuming every TXT record has the same format.
A DNS editor's presentation is distinct from the logical data returned by DNS. RFC 6376, section 3.6.2.2 defines TXT resource records for DKIM key storage. Preserve provider-issued record boundaries and inspect the actual published data through an authorized process. A screenshot of a saved input box is not sufficient to establish that the public owner and value are correct.
The guide's Verify button checks that records exist and contain content. That scope is narrower than a complete received-message test. Keep the actual verification result, subsequent approval state and final signing evidence separate. If a record is wrong, correct the specific mismatch with the DNS owner rather than repeatedly submitting approval or replacing unrelated records.
Treat relaxed alignment as a product prerequisite
The official DMARC implementation guide, edited May 16, 2025, says Click's subdomain design does not support strict adkim or strict aspf. It requires relaxed values for both, either explicitly or through the corresponding defaults. Preserve this as a documented product constraint; do not soften it into an optional performance recommendation or say the account can use strict mode without additional evidence.
That does not authorize silently weakening an organization's existing domain policy. Identify the policy owner, other mail streams and intended security requirements. If the current policy conflicts with the documented product design, keep the implementation blocked pending an approved design decision or current provider clarification. No DMARC policy was changed here, and this guide does not claim an unsupported alternative configuration.
RFC 9989, section 4.4 defines the protocol's alignment rules. General protocol support for strict alignment does not mean every service implements a compatible route. Conversely, the provider's restriction does not mean strict alignment is impossible everywhere. Keep those two statements separate when documenting the acceptance decision. Do not treat an unrelated passing signature as aligned simply because the sending platform is trusted by the organization.
Review SPF and actual message identities together
The account-generated SPF instructions need review within the full legitimate-sender inventory. RFC 7208, sections 2.4, 3.2 and 4.6.4 define MAIL FROM, multiple SPF policy behavior and evaluated DNS-dependent term limits. Do not replace a working organizational policy with a single-service example or add a competing second SPF record. Review the actual return-path identity used by the approved route.
After separately authorized setup, a harmless acceptance message should establish the author domain, return-path domain, signature domain and selector, with trusted receiver results. RFC 6376, section 3.5 defines the signature fields. A provider-level default signature or a successful DNS verification alone is not evidence that a customer-domain route aligns. Authentication also does not guarantee inbox placement or campaign engagement.
Fictional diagnosis and blank acceptance worksheet
A fictional distributor, Birchline Tools, completes DNS verification for its second brand and schedules a campaign while the domain remains Waiting for Approval. The campaign team treats that intermediate state as equivalent to production readiness. The review identifies two missing decisions: completion of the provider change window and confirmation that the brand's DMARC alignment settings meet the documented product requirement.
The proposed correction is to retain the completed DNS evidence while keeping release open until the actual domain state and policy decision are resolved. It is not to bypass approval, alter the From address secretly or weaken policy without authorization. This fictional scenario contains no real tenant result, scheduled campaign or executed test.
- Account version and all actual sending domains: ______
- Generated DKIM subdomain, optional link domain and record set: ______
- Existing dependencies and authoritative DNS approval: ______
- Required relaxed adkim/aspf compatibility decision: ______
- DNS Verify result, Waiting for Approval and Approved evidence: ______
- Monitored contact and provider change-window planning: ______
- Email Send and Campaign Automation From-domain checks: ______
- Trusted message-level identities and alignment result: ______
- Unresolved conditions, rollback owner and release decision: ______
Original implementation evidence, human subject-matter review, current applicability, production routes, visual accessibility and owner release remain open. No domain was submitted, DNS edited, policy changed or email sent. The catalogue's broader implementation requirement remains dependent on authorized account and message evidence.