Define the CRM route and administrative boundary
Zoho CRM's Email Authentication guide requires an Administrative profile. It describes domain verification and required DKIM, with SPF recommended. The documented path is Setup > Channels > Email > Email Deliverability > Email Authentication. Add Domain, verify the emailed code, then use Validate Records to obtain the DNS values and validate after publication. Zoho CRM Email Authentication
Treat this as the product workflow, not evidence about an existing organization. Record the CRM account, regional service, sending domain and message categories under review. A sales team's individual correspondence, a mass-mail operation and an organizational sender should not be collapsed into one unexamined route. The proposed inventory should show which team owns each use and what evidence will establish its actual sending identity.
The broader catalogue implementation requirement remains open. No account has been accessed, no verification code requested and no customer domain inspected for this manuscript. The review must still establish current applicability to the organization's edition and configuration.
Obtain records from the selected account
The DNS guide lists regional SPF values, including one.zoho.com for the US and distinct EU, IN, AU, CN and JP variants. Its instructions use generated SPF/DKIM setup values and TXT records. Existing SPF policies are edited rather than supplemented with competing policies; the displayed DKIM hostname and value belong to the account. CRM DNS settings
Use the region as an explicit change-request field. An administrator who remembers a mechanism from another Zoho service should not treat that memory as the source of truth for this CRM route. Compare the account's current instructions with the retained documentation and pause when they differ. The proposed resolution is a provider clarification, not an improvised mixture of regional includes.
Preserve the exact owner name and complete value, along with the requesting account and date. Do not reuse a sample selector or alter a public key to make it resemble an existing record. A generated value is a configuration input whose ownership and applicability still require review.
Review SPF as one complete policy
SPF evaluates the SMTP identity specified by the protocol; it does not simply search the domain visible in a salesperson's From address. A proposed include therefore needs to be associated with the actual sending route and relevant policy owner. If other applications already use the domain, preserve their legitimate authorization when reviewing a change.
Multiple selected SPF records produce an error rather than a useful union of sender lists. Combining policies is also not a mechanical paste operation: keep the intended mechanism order, termination behavior and authorized sources, and review the limits on DNS-dependent terms. Those limits concern evaluation, not a count of every network packet emitted by a resolver.
A syntax-valid policy does not prove that an observed message used an authorized path. The proposed evidence pack should distinguish a policy review from a message result, and should identify where envelope evidence remains missing. This avoids interpreting a new CRM status as a complete audit of all other systems using the domain. RFC 7208, section 2.4; RFC 7208, section 3.2; RFC 7208, section 4.6.4
Preserve the difference between DNS publication and identity verification
A DNS editor's owner-name field is not the final wire representation. Establish whether the interface appends the zone name and compare the intended fully qualified key name with the resulting record. In DNS master-file notation, a standalone @ denotes the current origin; this does not make it a wildcard covering every subdomain. Provider interfaces may use their own conventions.
DKIM key storage uses TXT records at the appropriate selector and signing-domain location. The signature's selector and d= value together identify the relevant lookup. A correct-looking public key at an unrelated selector does not validate the signature under examination. Preserve the complete key data and distinguish multiple character strings within one TXT record from separate records.
Do not request a private signing key for a routine DNS review. The public DNS configuration and a minimized received-message extract should be sufficient to identify the boundary that needs investigation. RFC 1035, section 5.1; RFC 1035, section 3.3.14; RFC 6376, section 3.5; RFC 6376, section 3.6.2.2
Evaluate the received identity rather than a status label
CRM also documents recognition of domains authenticated through another Zoho service, with prerequisites and a periodic update window. Treat that status as product configuration evidence, not a universal assertion that every Zoho product or message route behaves identically. Cross-service authentication note
The proposed final acceptance is to review an authorized representative message from each material route. Record its author domain, DKIM signing domain, selector and trusted receiver results. Compare the passing identity with the author domain under the applicable DMARC alignment mode. Keep that assessment separate from a label saying that a DMARC policy exists.
If the observed message does not match the inventory, investigate the route selection and evidence timestamps first. Do not weaken an organization's policy merely to eliminate a dashboard warning. A valid aligned sample is useful but limited: it does not establish inbox placement, consent quality, sales engagement or safety of the message's business request. RFC 9989, section 4.4
Acceptance worksheet for a sales-operations handover
Use this original proposed worksheet to make the account and route boundaries visible. Each row needs an owner and evidence reference rather than an unsupported checkmark.
- Scope: CRM account, edition, region, sender domains and distinct message categories.
- Authority: application administrator, DNS owner and communications approver for any visible sender changes.
- Domain checkpoint: evidence of the account's domain verification, without retaining its one-time code.
- DNS plan: issued owner names, types and values, existing-record comparison and approved change reference.
- SPF review: the complete affected policy, preserved authorized senders and evaluation-limit assessment.
- Message acceptance: route, timestamp, author domain, signing identity and trusted authentication results.
- Release: reviewer, rollback owner and unresolved production or applicability questions.
This worksheet has not been executed. A domain passing one configuration checkpoint is not permission to mark every row complete.
Fictional diagnosis: the regional shortcut
A fictional sales organization opens a new CRM account in a different region from its older deployment. The administrator starts with a remembered SPF mechanism and an old selector screenshot. A reviewer notices that neither artifact is tied to the new account's generated settings, so the change is paused before publication.
The proposed correction is to obtain the current account values, map the relevant policy and preserve unrelated senders. The organization then plans separate acceptance for its main organizational sender and its other material CRM routes. Nothing in this scenario proves that the old record was malicious or that the provider failed; it shows why copied configuration is weak evidence. The example is fictional, with no DNS queries, message sends or account changes performed.