Identify which system sends the sales email
A Freshsales conversation can start in the CRM while its outbound message uses a separately connected mailbox service. That distinction determines which system supplies the authentication configuration. Before discussing records, identify the Freshsales edition, the relevant email feature and the selected sending transport. Record the intended From address alongside them. An application name alone is not a sufficient basis for changing domain authorization.
Freshworks documentation spans Classic, newer CRM workflows and marketing campaigns. Similar menus and shared support-site headings do not make those instructions interchangeable. This guide separates the documented branches and proposes the evidence needed to approve one account's setup. No account, mailbox or message has been inspected, and no current tenant entitlement or generated DNS value is established here.
Separate connected-mailbox and Freshsales transport
Freshsales' From and Reply-to guidance distinguishes sending through the connected provider's SMTP service from Freshsales SMTP. In the connected-provider case, the documented From choice is restricted to the connected address. The page separately discusses Team Inbox addresses with Freshsales SMTP. These distinctions should inform the scope review before anyone assumes that every email composed in the CRM uses the same outbound infrastructure.
The older mailbox connection guide also describes choosing between those transports. Its legacy plan names and 2021 revision make it background for that distinction, not a current credential-setup recipe. Do not translate it into instructions to create an app password, grant mailbox access or replace an existing connection without current provider guidance and authorization.
Ask the account owner to identify the exact sales sequence, individual message or other workflow being reviewed. A mailbox connection may establish address control without demonstrating which domain a receiver will authenticate. Conversely, a domain record may exist even though the intended message never uses the service associated with it.
Treat Classic instructions as a separate branch
The Classic DKIM guide explicitly discusses Freshsales Classic and a 2024 migration to the native email platform. Its June 2, 2024 deadline is historical, not a new instruction for today's operator. The documented path uses Admin Settings, Domain Verification, Add domain and View DNS record, followed by account-specific CNAME publication and verification.
The source marks its record table as representative. Preserve that distinction in the change ticket: the actual account must supply each hostname and value. A record's resemblance to a help-page example is not sufficient provenance. Do not recreate an old selector or redirect an occupied name merely to match an illustration.
If an account still presents a legacy workflow, retain its edition and configuration context before comparing it with newer guidance. A migration notice can explain why a record set changed, but it does not establish that this particular tenant completed the migration or requires another change now.
Use the applicable current account record set
The accessible domain-verification article, revised in February 2024, describes Email Sending Domains under Admin Settings. Adding a domain and primary sender leads to a Configure page containing hostnames and values, then a Verify action after publication. The page describes campaign sending; its availability does not establish that every standalone Freshsales account has that feature.
Once the owner confirms applicability, the proposed handoff should include the complete requested record set, each record's purpose and the existing consumer of each owner name. Keep signing, mail-routing and tracking dependencies distinguishable. Do not omit a generated entry because it is not labelled DKIM, or assume a tracking CNAME alone authenticates the Author Domain.
Compare the intended public owner with the DNS editor's input convention. Keep the account's instructions and the proposed DNS difference together so a reviewer can catch suffix duplication or cross-account mixing. Any occupied owner, unexplained replacement or product mismatch should stop the affected change until resolved. This is a proposed review control; no DNS query or edit was performed.
Distinguish verification from message authentication
Freshworks' sender-requirements guidance distinguishes administrator-led domain verification from individual users connecting their inboxes. Connecting one address should not be generalized into verification of every colleague's address. Keep these product checks separate from protocol results and treat the article's historical rollout timing as historical.
For the authentication analysis, RFC 7208 section 2.4 defines SPF's MAIL FROM identity. RFC 6376 section 3.5 identifies DKIM's signing domain, selector and signed material. Neither a familiar display name nor a Reply-to address establishes those identities. A valid signature verifies the material it covers under its signing rules, not every claim made in the message.
RFC 9989 section 4.4 explains alignment with the Author Domain. Retain each passing mechanism's authenticated domain before deciding whether it qualifies. One aligned passing path can satisfy DMARC, but a pass for an unrelated provider domain cannot simply be relabelled as customer-domain alignment. DMARC policy also does not override all other receiver filtering decisions.
Collect a route-specific acceptance record
After separately authorized setup and testing, the proposed evidence record should link the account edition, chosen transport, exact message workflow and configuration revision to a controlled received message. Record the From domain, envelope identity, every DKIM domain and selector, and trusted receiver results. Keep unavailable fields empty rather than filling them with expectations from a screenshot.
Use harmless content and an approved recipient. Limit access to retained message evidence and establish what would trigger recovery before changing records. A successful sample covers its documented route and conditions; it does not certify every campaign, sales sequence or connected mailbox in the organization.
Fictional handoff and open requirements
In a fictional sales team's proposal, a Classic example table is submitted for a message intended to use connected-mailbox SMTP. The reviewer holds the DNS handoff because neither the applicable edition nor account-generated values have been established. No failed delivery, configuration change or successful retest is claimed.
The exact requirement remains open: Current FreshSales first-party setup evidence and a received-message identity table from the exact product and route. The commissioning gate is: Confirm current product identity and provider-owned documentation; test a real message or published records. State unsupported custom-domain features honestly. Before release, obtain account-specific evidence, complete authorized tests, secure technical and owner review, and inspect the intended live presentation. Publication has not been authorized.