On this page: Scope: Click sending versus other Dynamics email · Prepare the change and identify the owners · Generate records and track activation separately · DKIM, SPF and the dedicated subdomain · Resolve strict-alignment conflicts before deployment · Verify public DNS, then verify a real message · Troubleshooting decisions · Frequently asked questions
Configure ClickDimensions email authentication through ClickDimensions Settings → Email Sending Domains. Publish the exact generated DNS records, run Verify, wait for Approved status, then inspect a received message. Default vendor-domain DKIM does not establish alignment with your own From domain. Click announces that unapproved From domains cannot send starting January 25, 2027. Email Sending Domains · DKIM Signing.
Scope: Click sending versus other Dynamics email
This guide covers mail sent through ClickDimensions Marketing Automation's documented Email Sending Domains workflow, introduced in version 10.11 and updated in 11.4. It does not configure Microsoft 365, Dynamics mailbox transport or another SMTP service. An email designed in the same CRM can take a different delivery route. Record which system actually hands the message to the receiving mail server before changing DNS.
A migration or multi-brand account needs a separate row for each From domain and sending route. Do not assume that approval of the company domain covers every brand, automation or regional identity. Check what the account actually lists.
Prepare the change and identify the owners
Arrange authorized access to ClickDimensions settings, the authoritative DNS zone and a controlled test mailbox. Assign a DNS administrator and a person who can pause campaigns. Record current DNS values, TTLs, working From addresses and the applicable DMARC policy before making a change. Keep secrets and private signing keys out of DNS tickets.
Separate these identities in your worksheet:
| Identity | Why it matters | Evidence to retain |
|---|---|---|
| Visible From domain | DMARC reference identity | Actual Email Send or automation configuration |
| Envelope MAIL FROM | SPF identity and bounce destination | Receiver's smtp.mailfrom result |
| DKIM signing domain | Authentication and alignment | Signature d= and receiver header.d |
| DKIM selector | Locates the public key | Signature s= and account-issued DNS owner |
| Email link hostname | Link branding, not authentication proof | Separate link configuration |
Domain ownership and permission to edit its DNS are prerequisites, not something a sample record grants. If a new record conflicts with an existing service, stop and identify that owner. Reusing an occupied subdomain can damage a different mail stream even when the new setup screen appears satisfied.
Generate records and track activation separately
In Email Sending Domains, enter the From domain, an unused DKIM subdomain label and a monitored Contact Email. Both subdomain fields take labels, not full domain names: for email.example.com, enter email. The DKIM label must be valid without leading/trailing punctuation and unused by other services, including existing Email, Web Content and Social CNAMEs. The optional Email CNAME label must differ from the DKIM label. Save and export the generated records. Click describes two MX and five TXT records plus a possible organizational SPF change; the account's current output governs the actual change set.
Publish, then use Verify. The documented progression is Waiting for DNS Verification → Waiting for Approval → Approved. Approval uses weekly change windows and can take up to seven days. Verify From fields on Email Send records and Campaign Automations too. Current setup and approval process.
Treat the export as a change request, not a license to replace everything at the root. Your approval checklist should identify the exact owner name, type, value, existing record, proposed result and responsible person for every row. A DNS administrator can then resolve conflicts without reverse-engineering a screenshot. Before activation, compare the exact issued MX destinations and any routing addresses with the approved dedicated-subdomain routing plan. Obtain approval for the resulting inbound/feedback route; an account export or public screenshot is not that approval. Preserve corporate mailbox MX, parent nameservers, DNSSEC and unrelated security settings.
DKIM, SPF and the dedicated subdomain
Custom DKIM changes the signing domain and return path. Click documents TXT-based custom DKIM, not CNAME-based DKIM; provider-issued selectors are gears or gears2. Do not derive a key from either name. MX records on the dedicated subdomain support feedback handling; preserve root-domain mailbox MX records. Click currently documents 1024-bit defaults and support-requested 2048-bit keys. Custom DKIM requirements.
Copy each public key exactly from the account or support response. A public key is safe to publish; a private key is not. Check long TXT handling against the actual issued record and DNS host's format. One TXT record may contain multiple character strings; do not turn one key into several independent TXT records or join separate account-issued records together. The current guide describes three separately issued DKIM TXT strings of 225, 225 and 4 characters and explicitly says not to concatenate them. Preserve the actual record boundaries and values; do not infer records from those lengths. Most portals add their own quotation marks, so check the host's input convention and the returned DNS data.
For a hypothetical issued owner ISSUED_SELECTOR._domainkey.news.example.com, a parent example.com zone uses relative name ISSUED_SELECTOR._domainkey.news; a separately delegated news.example.com zone uses ISSUED_SELECTOR._domainkey; a delegated _domainkey.news.example.com zone uses ISSUED_SELECTOR. These are naming examples, not Click-issued values. Use the exact generated names and preserve existing delegations and selectors.
For SPF, determine the exact envelope-domain owner rather than blindly adding a historical include at the visible From domain. A root-domain SPF edit cannot change the MAIL FROM identity. If the export requests a root SPF change, review it in the context of all authorized senders and the actual route rather than assuming it is either always necessary or always forbidden.
There must be only one SPF policy at each owner. Preserve existing legitimate mechanisms and the intended final qualifier. SPF's limit is ten evaluated DNS-querying terms, including nested evaluation, not ten TXT records or ten visible includes. Other TXT records can coexist with SPF. For a null reverse-path, SPF uses HELO. Nested include, a, mx, ptr, exists and redirect count toward the evaluated budget; ip4, ip6 and all do not. 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 rules.
Resolve strict-alignment conflicts before deployment
Click's DKIM documentation says this custom setup does not support strict adkim or aspf and requires relaxed alignment. If the applicable policy is strict, do not silently change it to accommodate the sender. Ask the domain's security owner to approve a compatible domain design or use a supported alternative route. Do not assume moving the From address to an arbitrary subdomain makes the documented restriction disappear. Click alignment limitation.
DMARC requires a passing SPF result aligned with From, or a passing aligned DKIM signature. Relaxed alignment permits the same Organizational Domain; strict alignment requires identical domains. For a hypothetical From example.com, a passing d=news.example.com aligns in relaxed mode but not strict mode; a passing d=example.com exactly matches in either mode. These identity examples are not a claim that Click offers strict-compatible signing. A vendor's passing signature can therefore be useful authentication evidence without satisfying your brand's DMARC. Current DMARC standard.
Retain established DMARC policy and reporting destinations. Inspect both the direct policy and any applicable inherited policy. Only when neither applies and the domain owner approves a monitored introduction, a first policy could use this placeholder example:
Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_MAILBOX
Replace example.com with the intended policy domain and YOUR_APPROVED_REPORT_MAILBOX with the mailbox address only, not another mailto: prefix. In the example.com zone, use relative owner _dmarc. A deliberate child policy at _dmarc.news.example.com uses _dmarc.news in the parent zone or _dmarc in the separately delegated news.example.com zone. Keep one policy per owner. Never add a weaker child policy to evade inherited enforcement; monitoring is not a repair for broken signing. Review all legitimate senders before stronger enforcement. RFC 9989 removed pct, so do not build a percentage-rollout plan around it. It supersedes RFC 7489 and RFC 9091.
Aggregate reporting follows RFC 9990. 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. Failure reports can expose message content; do not add ruf without a privacy decision. Aggregate reporting · Failure-report privacy.
Verify public DNS, then verify a real message
Run read-only checks after substituting your account's exact names. These placeholders are not Click-issued records:
dig +short TXT EXACT_SPF_OWNER
dig +short TXT EXACT_DKIM_OWNER
dig +short MX EXACT_CLICK_SUBDOMAIN
dig +short TXT _dmarc.EXACT_FROM_DOMAIN
Compare results from the authoritative nameserver with a recursive resolver. Expected evidence is the intended SPF policy at its exact owner, the issued public-key data at every required DKIM owner, and the issued MX destinations on the dedicated subdomain. Check applicable inherited DMARC policy too. If a DNS editor appends the zone automatically, a relative name is required; inspect the published full name to catch doubled suffixes. An empty response or SERVFAIL is not a successful check.
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.
After Approved status, an authorized operator should send through the actual campaign or automation to a mailbox they control. 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. Preserve the message timestamp, route, From, smtp.mailfrom, DKIM d=/s= and receiver results. Authentication-Results trust boundary.
Acceptance requires the expected customer signing identity with dkim=pass and alignment under the applicable adkim mode, expected SPF behavior, and dmarc=pass with the aligned mechanism identified. DNS presence, account approval and recipient acceptance are separate evidence. Test each materially different From domain and route. Authentication does not guarantee inbox placement.
A DMARC pass supplied only by SPF does not complete the DKIM task. A rewritten unrelated From domain is not successful authentication of the intended brand. For interpreting a delivered message, see EmailAuth's raw DKIM results versus aligned DKIM policy results. Likewise, investigate SPF fail, permerror or temperror even if aligned DKIM carries DMARC: check actual sender authorization, duplicate policies or lookup limits, and DNS errors respectively. Separate a direct-route defect from forwarding effects before changing the policy.
Troubleshooting decisions
| Observation | First investigation | Safe next step |
|---|---|---|
| DNS published, status still Waiting for DNS Verification | Exact name, key formatting, authoritative zone | Correct the mismatched row, then Verify again |
| Waiting for Approval | Change-window stage rather than propagation | Track the approval interval; use the monitored contact and support if overdue |
| Approved domain but automation cannot send | Actual From domain on the affected action | Check that action, not merely a working manual campaign |
| DKIM passes with a Click-owned domain only | Default rather than intended custom signing | Compare the message with account activation and contact support |
| SPF passes but DMARC fails | MAIL FROM and From differ beyond permitted alignment | Inspect customer-domain DKIM and the applicable alignment modes |
| Incoming corporate mail breaks after setup | Root MX edited by mistake | Escalate promptly and restore only the mistaken change from the saved baseline |
For example, a team may see a TXT lookup succeed and schedule a launch before provider approval. That lookup proves publication only. Its go/no-go record should still show approval and receiver testing as outstanding rather than mislabeling the entire configuration complete.