Authenticate Zoho CRM's native sending domains by verifying the domain in CRM, publishing the generated DKIM TXT record and recommended region-correct SPF authorization, then validating the records. For native CRM mail, aligned DKIM is particularly important: Zoho documents a provider-owned return path that can pass SPF without aligning with your visible From domain. Adding another SPF include does not change that envelope identity. Zoho CRM authentication · Native return-path limitation
This guide covers CRM-originated email. It does not configure Zoho Mail or Zoho Campaigns. It also distinguishes native delivery from a connected mailbox and an email relay, because recipients can evaluate different sending servers and identities for each path.
Establish which CRM route you are configuring
List the From domain, account/data center and sending action: individual email, organizational address, mass email or workflow. Then identify whether CRM sends directly, uses a configured mailbox, or routes through an administrator-configured relay. Do not classify a message by where you composed it alone.
Zoho's authentication documentation identifies mass and organizational-address mail as Zoho-server routes. Relay configuration can route selected CRM-originated message types through another server, so inspect the actual relay rules rather than assuming all CRM traffic is direct. Zoho separately excludes configured-mailbox and relay routes from its native unauthenticated-sender replacement behavior. Sending-route distinctions
Use an Administrative profile for CRM email authentication and arrange access to authoritative DNS. Confirm feature availability in the account before planning relay work; relay capacity depends on subscription, and public documentation contains differing server-count statements. This guide does not prescribe a universal plan or server quota.
Save a DNS baseline with owners, values and TTLs. Identify employee-mail SPF authorizations, existing DKIM selectors and the applicable DMARC policy, including inherited parent settings. Adding CRM should not disable another sender or migrate the organization's incoming mail.
Verify the domain and obtain CRM records
Open Setup > Channels > Email > Email Deliverability > Email Authentication. Choose Add Domain and enter the company email address for the domain or subdomain you will use. Retrieve the verification code from that mailbox, choose Enter Code and verify it. Zoho documents a 15-day validity period and a Resend Mail option.
Choose Validate Records for the verified domain. Copy the complete SPF and DKIM instructions from the Authenticate Domain dialog. Domain verification and DKIM are required in the documented workflow; SPF validation is recommended. After DNS publication, return to Validate Record to complete the provider's check. Current administrative procedure
Keep the exact domain beside every copied record. A selector for one subdomain is not automatically a selector for the parent. Do not use Zoho Mail's selector-generation screen as a substitute for CRM's instructions, even when the organization buys both services.
Unauthenticated custom-domain senders on the native route may be replaced with Zoho-owned authenticated addresses. Therefore, acceptance must include the visible From domain, not merely a passing authentication result for whatever identity was substituted.
Merge the correct regional SPF authorization
Zoho's current CRM DNS instructions list these include mechanisms by data center:
- US:
include:one.zoho.com - EU:
include:one.zoho.eu - India:
include:one.zoho.in - Australia:
include:one.zoho.com.au - China:
include:one.zoho.com.cn - Japan:
include:one.zoho.jp
This is the published list, not an invitation to add every region. Use the account-generated instruction for the actual CRM account. For an unlisted region or a discrepancy with the account, obtain provider clarification instead of inventing a suffix. Older examples may show transmail.net; do not automatically replace a working authorization without identifying its current users. Official CRM DNS and regional guidance
Publish SPF as TXT at its specified owner. If a policy already exists there, merge the necessary mechanism into that record before the terminal all. Retain legitimate senders and the approved policy ending. Keep a single v=spf1 policy per owner. SPF terms are space-separated; ~all and -all are indivisible terms, not ~ all or - all.
Count lookup-causing terms across nested includes and redirects against SPF's limit of ten. Do not fix an over-limit policy by copying today's resolved IP addresses into a static record unless there is an approved process to maintain them. Providers can change infrastructure. SPF specification
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
On the native route, Zoho documents a return-path example under notifications.zohocrm.com. That is not your From domain, so SPF authentication can succeed while SPF alignment fails. The native return path is used for bounce tracking and is not customer-changeable in the documented troubleshooting flow. Focus on a passing aligned DKIM signature rather than assuming a different Zoho product’s delivery settings apply to native CRM. CRM alignment explanation
Publish DKIM and complete validation
Create the TXT record at the complete selector owner issued by CRM and paste its entire public-key value. Do not invent a selector such as zoho, reuse a screenshot's numeric selector, or publish private signing material. DKIM lookup uses the signature's s= selector and d= domain together. DKIM verification model
Check the DNS host's naming convention. If it appends example.com, the owner input may be only CRM-SELECTOR._domainkey; if it expects a full name, use the full owner. Replace placeholders with the actual issued name. A duplicated suffix publishes a record in the wrong place.
For an actual issued selector at full owner SELECTOR._domainkey.news.example.com, use relative SELECTOR._domainkey.news in the parent example.com zone, SELECTOR._domainkey in delegated news.example.com, or SELECTOR in an existing delegated _domainkey.news.example.com authority. Substitute the issued selector and connected domain, preserve NS delegation and other selectors, and confirm the final full owner. Relative DNS names.
Keep the public key intact, without a pasted newline or missing segment. Several quoted strings inside one TXT record can represent a long value; multiple separate competing TXT records are not the same arrangement. If the owner already holds a different key or CNAME, identify its dependency before changing it. Do not break an existing sender to make CRM's validation green.
Once authoritative DNS answers correctly, select Validate Record in CRM. If the provider still reports a missing record, compare the owner and value before waiting for caches. Zoho's troubleshooting specifically calls out auto-appended domain suffixes and duplicate SPF records. CRM channel troubleshooting
What if another Zoho product already authenticated the domain?
CRM documents recognition of authentication performed in another Zoho service. Automatic identification runs every 48 hours and requires at least one domain already authenticated in CRM through SPF or DKIM to initiate the process. Check the status shown beside the domain rather than assuming recognition is immediate. Reuse working records only when the current CRM workflow recognizes them; still verify a CRM message. Cross-product recognition is not proof that different products share every return-path behavior.
Treat relay delivery and fallback separately
An email relay changes the final sending infrastructure. Determine whether the relay preserves Zoho's envelope sender or rewrites it, and whether it changes signed content. Final-hop SPF can differ from the result at the relay's inbound connection. A surviving aligned DKIM signature remains valuable. Do not describe DKIM as an automatic delivery guarantee. Zoho CRM relay behavior
In an authorized existing relay configuration, Zoho documents a DKIM Authentication Enable option under advanced details and a public key to publish. Confirm signing is enabled for the routed message types. Do not create an open relay or relax security controls to resolve an authentication failure.
The current administrative relay procedure places domain authentication in Domain Settings; the developer procedure describes Advanced Details. Follow the supported screen in your account rather than assuming one label across versions. New persistent credentials, expanded relay access or security exceptions require separate security-owner approval. Changing bounce management or its recipient requires the mail owner’s separate approval: disabling CRM bounce handling also removes its bounce-status updates. These are not implicit DNS troubleshooting steps. Administrative relay settings.
For signing on an already approved existing relay, open Setup > Channels > Email > Email Deliverability > Email Relay and use that approved server’s Domain Settings (Advanced Details in the legacy procedure). Confirm the intended domain and selected message types, enable DKIM Authentication, use Copy to Clipboard for the complete public key and publish it at the issued DNS owner, then choose Configure to save the relay settings. Verify the saved configuration and a controlled routed message; copying a key without saving activation is incomplete. This sequence does not authorize a new relay, new credentials or changed bounce handling. Save relay configuration.
Zoho also documents fallback to its own servers when relay delivery fails or the configured relay sending limit is reached. Test native fallback as a distinct route; otherwise the first incident may expose a path never validated during onboarding. Relay configuration and fallback
Plan fallback checks with the workflow and mail owners using controlled synthetic records and recipients. Do not intentionally break a live relay, exhaust its quota or trigger a real customer workflow to test fallback. Preserve the DNS and approved sender/transport baseline; with the owner’s approval, pause only affected automation or restore the prior approved route after a regression. Keep keys required by queued mail, then retest the failed path and a known-good control. If safe fallback testing is unavailable, record that acceptance check as pending rather than claiming it passed.
Preserve DMARC policy and reporting
Look up _dmarc at the actual From domain and inspect applicable parent policies before editing. Preserve enforcement, reporting recipients and alignment choices. Do not replace p=reject with p=none, create duplicate DMARC TXT records, or introduce a monitoring record at a subdomain that weakens inherited protection.
Only when no direct or applicable inherited policy exists and the domain owner approves the monitoring and review plan, an illustrative first record is TXT with value v=DMARC1; p=none. This requests no reports by itself; add rua only for a provisioned, approved destination after checking the reporting rule below. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. Obtain explicit domain-owner approval of the monitoring and review plan before publication.
DMARC tags use semicolons. Add aggregate reporting as ; rua=mailto:YOUR-AUTHORIZED-REPORT-ADDRESS only after replacing the placeholder with an approved recipient. Multiple reporting URIs use commas. External reporting destinations may require authorization in the recipient's DNS. Preserve privacy and reporting ownership. Aggregate-reporting standard
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
DMARC requires either passing aligned SPF or passing aligned DKIM. Relaxed alignment compares organizational domains; strict alignment requires an exact match. Check DKIM d= against From under the policy's adkim setting, rather than accepting any Zoho signature. RFC 9989 supersedes RFC 7489 and removes pct; do not design a new enforcement rollout around it. Current DMARC standard
Validate DNS and receiver evidence
Replace all capitalized placeholders before using these read-only commands:
dig +short NS YOUR-ZONE
dig @AUTHORITATIVE-NS TXT YOUR-SPF-OWNER +noall +answer
dig @AUTHORITATIVE-NS TXT YOUR-DKIM-OWNER +noall +answer
dig @1.1.1.1 TXT YOUR-DKIM-OWNER +noall +answer
dig @1.1.1.1 TXT _dmarc.YOUR-FROM-DOMAIN +noall +answer
Compare the exact issued key and intended SPF authorization. Query the envelope domain separately after obtaining a delivered message. Correct DNS demonstrates publication only, not the route CRM actually chose.
Send authorized new messages through each used path: native individual, organizational/mass, workflow and relay where applicable. Use a controlled external mailbox. Record the intended and actual From, Return-Path, DKIM d= and s=, sending time and route. Trust Authentication-Results only from the receiving system, not arbitrary upstream headers. Header trust boundaries
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
Accept when the intended From remains intact, the expected DKIM signature passes with alignment, and the receiver reports dmarc=pass. Record SPF authentication and alignment separately; native nonalignment is not by itself a failure of this design. Investigate SPF fail, permerror or temperror independently even when DKIM carries DMARC; an unaligned SPF pass and an SPF error are different findings. A relay or mailbox route needs its own evidence. Retain the result with the DNS baseline for future migrations.
Match the intended active CRM-issued signature, or the final provider signer on the separately selected relay/mailbox route to its configured d= and s=. Require that signature to pass and align under effective adkim with the unchanged intended visible From, plus trusted receiver dmarc=pass. An unrelated aligned signer or SPF-only DMARC pass does not complete branded DKIM deployment. DMARC alignment.
Frequently asked questions and failure diagnosis
Why does CRM show authenticated but the message still fails DMARC?
Check the actual route, From domain and DKIM signing domain. A relay may modify signed content, or the message may use a different sender. Provider status does not prove the receiver's outcome.
Should I add more SPF includes to fix native alignment?
No. Additional authorization does not change the provider-owned return path. Fix aligned DKIM and verify the actual From identity.
Why is the sender address rewritten?
For native sending, check domain authentication and whether the address is a public mailbox domain. DNS alone is insufficient if CRM validation is incomplete.
Where do Campaigns instructions belong?
Use EmailAuth's separate Zoho Campaigns authentication guide. Its Campaigns delivery workflow is distinct from native CRM.
No customer account was configured, DNS changed or delivery test performed for this guide. Verify your account-specific settings, public DNS and delivered-message results using the checks above. Authentication does not guarantee inbox placement.