Scope the guide to Conversica's dedicated subdomain route
Conversica's Subdomain Configuration Instructions, updated October 29, 2025, describe registering a dedicated sending subdomain in the dashboard and publishing the generated DNS records. This is the route covered here. It is not a guide to an unrelated SMTP integration or proof that all Conversica accounts have identical settings. Confirm the current account, assistant and transport before selecting a configuration path.
The guide requires the subdomain entered in Add Domain to be used exclusively by the Conversica assistant. Start with a name that the organization controls and has not assigned to another service. Treat the choice as a routing and ownership decision, not just a branding preference. The source explains that this arrangement lets Conversica handle assistant email sending and receiving; replacing records at an already-used name can therefore affect more than outgoing authentication.
Record who owns DNS, who administers the assistant, which message categories use it and what existing dependencies must remain intact. Avoid copying lead addresses or conversation content into that inventory. The domain, route and configuration reference are enough to begin the technical review. No assistant, domain or recipient data was accessed for this manuscript.
Register the subdomain and preserve the generated record set
The documented navigation is DNS Settings, Add Domain, then the desired subdomain rather than only the organizational domain. Advanced settings allow custom DKIM selectors. Opening the resulting domain ID displays nine records: two TXT, three MX and four CNAME records. Preserve the actual generated owner names, values and MX priorities rather than treating a screenshot or a remembered example as a universal template. Conversica setup guide
The TXT entries cover SPF and FBL SPF. The MX entries cover two mail-routing records and FBL MX. The CNAME entries cover verification, links and two DKIM records. Keep those functions distinct in the change request. A verified ownership alias does not substitute for either DKIM alias, and a functioning tracking link does not prove that the return path or receiving route is correct.
The guide offers Download CSV for the issued records and a generated DNS setup-page link that can be sent to an IT team. A generated link can convey setup capability or information to its recipient, so use an approved recipient and sharing route. This guide does not generate, transmit or test such a link. A local change record can identify the authorized handoff without exposing it in a public article.
Preserve the provider's SPF and DNS-mode constraints
Conversica explicitly says that SPF macros are not allowed in the configured TXT record and that the record must contain conversica.com. Those are product constraints, not general limitations of SPF. Do not weaken them into suggestions or silently rewrite the generated instructions to fit an existing automation pattern. If an organizational policy generator uses macros, resolve compatibility with the provider and policy owner before proceeding. Conversica setup guide
For Cloudflare-managed DNS, the same guide requires all Conversica-related CNAME records to be DNS only rather than proxied. This statement is scoped to the documented configuration. It is not permission to change unrelated proxy, network or security settings. Identify the specific records in the approved change and leave other service dependencies untouched. Record the resulting mode as an acceptance item rather than assuming a saved CNAME has the required behavior.
DNS editors use different labels for owner names and values. Copy the provider's Domain and Entry fields into the correct editor fields, preserving MX priorities separately. Confirm the fully qualified owner produced by the editor so that a suffix is not accidentally repeated. An apparently plausible name at the wrong owner can leave the intended record absent while still looking correct in a change ticket.
Distinguish new setup from the documented legacy migration
Conversica also publishes a legacy-to-enhanced DNS migration guide, updated September 30, 2021. Its age matters: establish current account applicability before using it. Do not mix its intermediate record count with the October 2025 new-subdomain procedure or assume every existing domain still requires that migration.
The historical workflow begins with a domain marked Validated (Legacy), checks six legacy records and adds or confirms the verification CNAME. Only after those records validate does it move to Enhanced DNS Records. The later stage changes the legacy MX entries and adds the enhanced dependencies, ending with nine green checks. This is an ordered migration, not a direction to delete all old records and hope the new set works.
Use the actual current domain ID and issued values to decide what remains required. A migration worksheet should distinguish retained records, changed targets and new records, with a rollback owner and provider confirmation of any retirement. The guide's promotional reference to enhanced encryption does not establish message-content confidentiality or a particular TLS guarantee. This article makes neither claim.
Validate each record without declaring message success prematurely
After entering the records, the setup guide directs the operator to Validate. Green checks indicate successfully validated entries; a red X requires examining the configuration. Keep the result for each record and the time of observation. If one alias is missing, a successful check for another does not close the whole nine-record requirement. A waiting period is not a substitute for correcting a wrong owner, target or priority.
A proposed diagnostic order is to compare the requested record, authoritative publication and provider observation before considering a transient resolver delay. The legacy guide's timing allowance is not a promise that every fault resolves automatically. No validation button or DNS query was executed for this article. The documented workflow and the blank worksheet are preparation for a separately authorized implementation.
RFC 7208, sections 3.2 and 4.6.4 provide additional SPF checks: avoid competing policies at the same owner and review evaluated DNS-dependent terms across the complete path. A product-specific prohibition on macros does not replace those protocol requirements. Similarly, custom selector support does not excuse publishing an incomplete DKIM record set or confusing a selector with the signing domain.
Establish the actual message identities after configuration
A separately authorized harmless acceptance message should identify the visible author domain, envelope identity, DKIM signing domain and selector, together with trusted receiver results. RFC 6376, section 3.5 defines the signature fields that connect a message to its key lookup. DNS existence alone does not show that the route uses the intended signature.
RFC 9989, section 4.4 explains alignment. A passing identity must have the required relationship to the visible From domain; any passing provider identity is not automatically sufficient. Keep DKIM, SPF, DMARC and recipient delivery observations separate. Neither nine green DNS checks nor a valid signature proves the safety of a message's business request or guarantees inbox placement.
Fictional diagnosis and blank acceptance worksheet
A fictional events business, Cedar Arena, selects a subdomain previously used for a website redirect. Its DNS operator adds the requested aliases but leaves the existing proxy behavior in place. The proposed review identifies both an ownership conflict and the documented DNS-only requirement before authorizing any production change. The team chooses to resolve the name's use and record-specific configuration rather than disabling unrelated protections. This is a fictional planning example, not an actual failed validation or network test.
- Account, assistant, route and current guide applicability: ______
- Exclusive subdomain ownership and existing dependency review: ______
- New setup or confirmed legacy migration path: ______
- Two TXT, three MX and four CNAME instructions with exact owners: ______
- SPF macro restriction and conversica.com condition reviewed: ______
- Applicable CNAME DNS-only mode and approved scope: ______
- Per-record validation evidence and unresolved errors: ______
- Actual message identities, alignment and remaining acceptance gates: ______
Original implementation evidence, human review, current applicability, production routes, visual accessibility and owner release remain open. No records, proxy settings, account controls or messages were changed or created.