For Zoho Mail, publish the SPF TXT value appropriate to your account, generate a DKIM selector in the Admin Console, publish its public-key TXT record, then verify and enable DKIM. Publishing a key alone does not activate signing. Use your domain's current setup screen rather than copying another organization's selector or regional SPF value. Zoho SPF setup and DKIM configuration
This guide covers custom-domain Zoho Mail sending, not every product carrying the Zoho name. Zoho Campaigns, CRM and transactional services need their own route-specific authentication checks. Hosting a mailbox at Zoho does not prove that your website or invoicing software sends through Zoho Mail. If an application uses a separate relay, follow its guide, such as SMTP2GO sender-domain authentication, rather than adding that route to Zoho by assumption.
Confirm the sending route and prerequisites
Start with a verified custom domain in the correct Zoho organization, administrator or super-administrator access, and permission to edit its authoritative DNS. Identify the domains used in visible From addresses, including aliases and subdomains. Record your data center and account type.
Zoho's setup guide explicitly says that generic DNS values can differ by data center and directs administrators to their domain-specific setup screen. Do not construct an EU, India or other regional include merely by replacing the suffix in an example. Domain purchases through Zoho may have records configured automatically, but existing automation still needs validation. Domain setup and DNS mapping
For a mail client or application, obtain the precise SMTP server details from the account's Server Configurations Details. Zoho distinguishes account types and data centers; the server, permitted address or alias, encryption and authentication must all be correct. A login failure is separate from an SPF failure. Zoho SMTP configuration
There is an important scope limit: Zoho's DKIM documentation limits support to mail generated in Zoho and delivered directly to external servers. It excludes the documented Email Routing/Outbound Gateway cases and messages generated on other servers. If you use those paths, stop treating this direct-delivery recipe as sufficient and review the complete outbound architecture. DKIM route limitations
Prepare a DNS change worksheet
Before editing, save the current zone and answer five questions:
- Which hostname is Zoho asking you to authorize for SPF?
- Which existing services also send using that envelope domain?
- What exact DKIM selector owner and public value did your account generate?
- Does that owner already contain a TXT record or a CNAME for another service?
- What DMARC policy and reporting destinations already exist?
Keep the complete owner, record type, value, TTL and previous value together. This prevents a common split-team mistake: the DNS administrator publishes one selector while the mail administrator enables another. Share public record values through your approved process, not passwords or private keys.
This is an authentication change, not permission to migrate incoming mail. Preserve working MX records unless a separate mailbox migration requires changing them. Do not delete verification tokens, unrelated TXT records or other services' DKIM selectors just to make the zone look simpler.
Configure one SPF policy with the correct Zoho authorization
Navigate to Domains → your domain → Email Configuration → SPF in the Admin Console. Copy the instruction for that domain. Zoho's current general SPF page gives v=spf1 include:zohomail.com -all and identifies include:one.zoho.com as an option for multiple Zoho services. These are documented examples, not permission to overwrite an existing multi-sender policy or assume one value fits every account. Current SPF instructions
If a v=spf1 TXT record already exists at the required owner, merge the applicable Zoho mechanism into that record before its terminal all. Preserve other verified senders. If none exists, publish the account-appropriate complete policy after establishing which services should be authorized. The DNS host may use @ for the zone root; use the actual required owner for subdomain sending.
There must be one SPF policy per owner, not separate policies for Zoho, Google and your help desk. Multiple TXT records of other kinds are fine. Check the resulting policy for more than ten DNS-lookup-causing terms, including nested includes. Avoid +all, which authorizes everyone, and do not silently change an established -all to ~all. SPF publishing and evaluation rules
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.
Return to the domain's SPF screen and use Verify SPF Record. That checks the published configuration; it does not establish the actual MAIL FROM identity of every application. For SPF, the relevant identity is the SMTP envelope sender, not simply the visible From address.
Generate, publish and activate DKIM
In Domains → your domain → Email Configuration → DKIM, add a selector, choose a key length and obtain the generated TXT record. Publish the full public value at the displayed SELECTOR._domainkey.DOMAIN owner. Then verify that selector in Zoho, make the intended selector default and enable DKIM. Check for user-specific selector assignments when different users behave differently. Zoho DKIM workflow
Prefer the offered 2048-bit RSA option where supported. The DKIM cryptographic update recommends at least 2048-bit signing keys and prohibits undersized keys below its minimum requirements. Never shorten the public key to fit a form. DKIM key-size guidance
A DNS interface may display a long TXT value as several quoted character strings inside one record. That can be valid; separate independent TXT records containing fragments are not equivalent. Keep the entire key, preserve punctuation, and avoid adding literal explanatory placeholders. Do not publish anything described as a private key. DKIM DNS key representation
If the DNS editor rejects the intact key, stop and obtain the DNS host’s supported single-record representation. Do not truncate the key, split it into independent records or silently downgrade its length to make the form accept it.
Some DNS hosts append your domain automatically. If you enter a full owner into a relative-name field, the result can repeat the domain. Confirm the final name in the saved record. If a CNAME already occupies the intended selector owner, do not add a conflicting TXT record beside it. Use a new supported selector or resolve the existing service dependency first.
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.
Validate the public records
Use a DNS lookup service or these read-only command patterns, replacing uppercase placeholders with your real domain and selector:
dig +short TXT ENVELOPE_DOMAINdig +short TXT SELECTOR._domainkey.SIGNING_DOMAINdig +short TXT _dmarc.FROM_DOMAINdig +short NS DNS_ZONE
For SPF, expect one complete policy containing the account-appropriate authorization alongside other legitimate senders. For DKIM, expect the exact public key issued for the active selector, with no truncation. For DMARC, expect the intended policy at the applicable discovery location, not a second competing policy.
If a lookup returns no record, check the complete owner and the nameservers actually delegated for the zone. If one resolver differs from another, compare authoritative answers and cache TTLs. Do not interpret every delay as a provider failure, but do not wait indefinitely for a typo to repair itself. SERVFAIL calls for DNS troubleshooting, including possible DNSSEC problems.
Keep the lookup time, resolver and results with the change worksheet. These observations support a support request and make later migrations easier to audit.
Test a delivered Zoho message, not only the dashboard
Use a mailbox and recipient you control. Send an ordinary external message through Zoho webmail, then separately test any authorized SMTP client, alias or application route that matters. Inspect the received copy's full headers. A message in your Sent folder is not evidence of recipient authentication.
Record the receiver's trusted Authentication-Results, the visible From domain, Return-Path and DKIM signature's d= and s= values. Look for spf=pass, dkim=pass and dmarc=pass, but also record the domains attached to those results. The signature selector identifies the key to retrieve; it is not itself the signing domain. DKIM identifiers and verification
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.
DMARC needs either passing SPF aligned with From or passing DKIM aligned with From. Relaxed alignment allows the same organizational domain; strict alignment requires an exact match. A passing signature belonging to a different provider domain is not automatically useful for your domain's DMARC evaluation. DMARC alignment
Match the intended active Zoho Mail signature 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.
Consider a diagnostic example: webmail passes, but a website form fails. Before adding more Zoho includes, confirm whether the form really uses Zoho's SMTP service or the web host's local mail server. The correct fix depends on the observed route. This example is not a claim that customer mail was tested.
Keep DMARC policy and reporting under domain control
Do not replace an existing quarantine or reject policy with a generic monitoring example. Check for an applicable inherited parent policy before adding a child record; do not weaken inherited protection. If no applicable DMARC policy exists, establish an authorized report destination and assess a monitoring-first rollout after configuring legitimate senders. Review both Zoho Mail and non-Zoho sources before enforcement.
Only when no direct or applicable inherited policy exists and the domain owner approves initial monitoring, 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.
RFC 9989 is the current DMARC standard, replacing RFC 7489. Its changes remove pct, so a new rollout should not depend on percentage sampling. Preserve working reporting destinations during an SPF/DKIM update, and review any external report-recipient authorization before sending reports outside your domain. Current DMARC policy standard and aggregate-report authorization
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.
Authentication does not guarantee inbox placement. A receiver can filter authenticated messages for other reasons; changing policy is not a substitute for investigating the actual rejection or spam classification.
Troubleshoot the specific failure
SPF verification fails: check the account's regional instructions, duplicate policies, the correct DNS owner and lookup complexity. Do not import an include from a different Zoho product merely because it shares the brand.
DNS contains the key but messages are unsigned: distinguish publication from activation. Confirm the intended domain and selector were enabled, then check whether the message used the supported direct Zoho delivery route.
Only certain users fail: compare their From domains and actual d=/s= identities with a passing user's message. Investigate selector assignments and aliases before rotating the organization-wide key.
DKIM fails after an outbound gateway: review whether the gateway changes signed content or whether the route falls outside Zoho's documented support. Test at the final recipient rather than assuming the initial submission preserved authentication.
SMTP submission fails: review server/account type, permitted From address and authentication independently. Do not disable multifactor authentication to repair a DNS problem; use the supported client-authentication method for the account. SMTP troubleshooting
Completion and review limits
Retain the published SPF, active selectors, account verification state and a test log for each relevant sending route. Use ongoing reports to find legitimate workflows missed by a single message test.
No customer account, public customer DNS or delivered message was tested. Deployment, indexing and delivery outcomes remain unverified.