For Zoho Campaigns, verify your sender address, publish the SPF and DKIM records displayed for its domain, and complete domain authentication. In the current Campaigns 3.0 interface, configure SPF and DKIM first to unlock Custom Return Path, then publish its generated CNAME and validate it. Keep DMARC under your domain's existing policy rather than creating a competing record. Finally, inspect a newly delivered campaign. Zoho Campaigns 3.0 authentication
This is a marketing-email configuration guide for Zoho Campaigns, not Zoho Mail, Zoho CRM or Zoho Marketing Automation. Sharing an account or syncing contacts does not make those products' sending paths identical. SMS and WhatsApp campaigns are outside SPF, DKIM and DMARC.
Choose the correct interface and sender domain
Campaigns 3.0 uses Settings > Email > Senders and Authentication. Earlier documentation uses Settings > Deliverability > Manage Senders, with Sender Address and Domain Authentication tabs. Follow the version actually displayed in your account, not a screenshot from another product. Classic Campaigns workflow
You need access to Campaigns sender settings, a mailbox that can receive the verification message, and the authoritative DNS zone. Write down your account/data-center location and the precise domain in the campaign From address. Do not assume a US target is correct for an account elsewhere. The documentation reviewed does not establish a universal plan entitlement; confirm the available controls in your account. The records generated in the selected account govern regional DNS choices. In the classic form, up to five addresses can be added together; that is not a five-address account limit. Keep Campaigns consent, unsubscribe handling and list quality separate from authentication.
Before editing, save existing DNS values and TTLs. Identify other services using the domain, including employee mail and transactional applications. Record existing SPF and DKIM owners, the DMARC policy at the sending domain, and any applicable parent policy. No mailbox migration or MX replacement is required to publish these authentication records.
Verify the sender before authenticating the domain
In the current interface choose Add Sender, enter the display name and business email address, and save. Follow the verification link sent to that mailbox. If the sender remains Pending, use Resend Verification and resolve mailbox access before changing DNS repeatedly. A verified mailbox and an authenticated domain are separate milestones.
Use a domain you control rather than a public Gmail or Yahoo address. You cannot publish your own authentication policy for a public mailbox provider's domain. An address may be unavailable in the campaign composer because it is unverified, its domain is not authenticated, or it is a public-domain address. Zoho's sender-selection troubleshooting
Select Setup beside the intended domain and keep that domain context visible while copying records. If campaign personalization chooses different senders, inventory those domains too. One test from a fixed default sender does not cover every dynamically selected sender.
Publish SPF without disrupting existing services
The current official guide shows include:zcsend.net for its illustrated Campaigns SPF configuration. The v3 DNS guide also lists EU eu.zcsend.net, Australia au.zcsend.net, India zcsend.in, Japan sender.zcsend.jp, China zcsend.net.cn, Canada zcsend.ca and Saudi Arabia zcsend.sa. Each is the domain portion of the corresponding include: mechanism. Use only the actual account instruction, not every region. Regional SPF map Publish SPF as TXT at the exact owner indicated, usually the selected sender domain, not at _dmarc or a DKIM selector. Campaigns SPF setup
If an SPF policy already exists there, edit that policy to include the necessary authorization before its final all mechanism. Preserve every legitimate existing sender and the approved ending. Do not paste a second v=spf1 policy beside it. Do not change -all to ~all simply because a tutorial example uses a different ending.
SPF mechanisms use spaces. Keep ~all or -all as one token, not ~ all. Check the ten DNS-lookup-term limit across includes and redirects, not just the number of visible include statements. Count all evaluated DNS-dependent terms, including nested chains of include, a, mx, ptr, exists and redirect. Multiple SPF policies or excessive lookups can cause permanent errors. Preserve intentional qualifiers (+, -, ~, ?); none guarantees a receiver delivery decision. When an all mechanism is present, redirect is ignored regardless of order, so do not add an all to an existing redirect policy without reviewing the change. RFC 7208 section 5.1 SPF specification
There is an important distinction between satisfying Campaigns' setup validation and achieving SPF alignment on a delivered message. SPF evaluates the envelope MAIL FROM domain, represented by Return-Path after delivery. Adding an include at the visible From domain does not change a provider-owned envelope domain into your domain. Custom Return Path addresses that separate identity issue. For a null reverse-path, the relevant SPF identity is HELO, not the visible From. RFC 7208 section 2.4
Publish the generated DKIM TXT record
Copy the DKIM host name and complete public-key TXT value shown for your domain. The selector may be numeric; it is not a universal value to borrow from a screenshot. An illustrative owner has the shape ACCOUNT-SELECTOR._domainkey.example.com, but replace the whole placeholder with the account's real owner. Zoho's DKIM publication instructions
Use the record type the account requests. Do not turn a TXT public key into a CNAME, and do not paste a private key into DNS. Preserve the complete key and any tags issued with it. Some DNS tools show a long TXT value as several quoted character strings within one record; those component strings are concatenated without inserted spaces into one logical TXT record. RFC 6376 section 3.6.2.2 That is different from adding separate competing records at the same selector.
Check whether the DNS editor automatically appends the zone name. Entering a full owner in an editor that appends it again can publish the key at the wrong place. If that selector is already occupied by a different active key or CNAME, stop and coordinate with the existing owner instead of overwriting it. A key collision is not a propagation delay.
For illustrative owner ACCOUNT_SELECTOR._domainkey.news.example.com, the relative name is ACCOUNT_SELECTOR._domainkey.news in zone example.com, ACCOUNT_SELECTOR._domainkey in delegated news.example.com, or ACCOUNT_SELECTOR in delegated _domainkey.news.example.com. Substitute the real issued selector. Follow existing NS authority and preserve delegations; a parent entry cannot override a delegated namespace. Never delete NS or change DNSSEC to make the record fit.
For SPF TXT requested at apex example.com, use blank/@ in that zone. For requested news.example.com, use news in the parent zone or blank/@ in the separately delegated child zone. Publish the required setup policy at its exact requested owner, and separately test the actual delivered envelope identity.
Return to Campaigns and click Authenticate after the records resolve, before configuring CRP. In the classic workflow, return to Settings > Domain Authentication > Setup > Verify Domain and read any displayed error; these are version-specific labels, not interchangeable buttons. The v3 guide allows up to 24 hours for DNS updates; older guidance describes 24–48 hours. Compare authoritative answers first rather than treating either window as a guarantee. Public DNS alone does not mean the provider has completed its validation or started using the intended signing configuration.
Configure custom return path after SPF and DKIM
In Campaigns 3.0, the Custom Return Path section remains locked until SPF and DKIM are configured. Expand it, select an unused host label, publish the displayed CNAME target at that host, and choose Validate CRP. Zoho specifically warns against existing A or MX records at the chosen host. More generally, do not place a CNAME where ordinary TXT, A, AAAA or MX data already serves another purpose. Current CRP prerequisites and validation
Do not skip the current SPF prerequisite because an older third-party walkthrough says the root record is unnecessary for SPF alignment. The envelope-identity explanation is useful, but the current product's setup gate is a separate requirement. Use the current account workflow for activation, and the delivered message for proof.
The CNAME target is account-generated. Keep it DNS-only if your host offers HTTP proxying. Ensure the host returns the CNAME rather than flattening it to address records; the provider must be able to validate the alias. In Cloudflare, turn a relevant per-record Flatten control off when available and ensure applicable whole-zone flatten-all behavior does not suppress the literal issued CNAME. Coordinate shared-setting changes; do not disable unrelated behavior blindly. Mandatory apex or same-zone flattening can still apply. If it cannot preserve the required alias answer, stop and coordinate a supported arrangement with Zoho and the DNS owner rather than inventing an override. Cloudflare controls and exceptions
For a fictional CRP owner bounce.news.example.com, relative owner is bounce.news in parent zone example.com or bounce in delegated news.example.com. Do not add a TXT SPF policy at that CNAME owner or another CNAME beside it. This illustrates mapping only; use the account-selected host and target. The native CRP guide confirms the unused-host and validation workflow. Do not substitute your website host, mailbox MX server or an invented regional suffix. After validation, check that a real campaign uses the intended custom return path. A selected host label in a form is not evidence that the envelope changed.
Publish or preserve DMARC correctly
Campaigns 3.0 checks DMARC but does not generate the policy for you. First inspect _dmarc at the actual From domain and its applicable parent policies. Preserve existing enforcement, alignment choices and authorized report recipients. A subdomain without its own TXT policy may still inherit protection; do not undermine it with a new p=none record.
Only where no established or applicable inherited policy exists, the domain owner explicitly approves and someone owns the monitoring/follow-up plan, publish a TXT record at _dmarc.example.com for From domain example.com. Use _dmarc as the relative host only if the editor appends that zone. A minimal monitoring value is v=DMARC1; p=none. For From domain news.example.com, the full owner is _dmarc.news.example.com: use _dmarc.news in parent zone example.com, or _dmarc in delegated news.example.com. Publish only in the actual authoritative zone, not both. These are explanatory examples, not records tailored to your domain.
Use semicolons between DMARC tags. To request aggregate reports, add ; rua=mailto:YOUR-AUTHORIZED-REPORT-ADDRESS, replacing the placeholder with the approved mailbox address only, not a second mailto: prefix. Commas separate multiple URIs. If a report destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check destination DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone is not enough. Coordinate the authorization with the recipient operator. RFC 9990 section 4 This protocol check does not replace domain-owner approval to share aggregate traffic data and identifiers, including the recipient, access and retention decision.
A message passes DMARC when at least one passing SPF or DKIM identity aligns with From. Relaxed alignment permits the same organizational domain; strict alignment requires exact equality. For a hypothetical passing DKIM signature, From news@example.com and d=campaigns.example.com align relaxed but not strict; d=example.com with that same From aligns in both modes. Evaluate the intended account signature, not an unrelated provider signature. A passing SPF result for bounce.example.com likewise aligns relaxed but not strict with From example.com. A return-path subdomain is not automatically strict-SPF aligned. Aligned DKIM can independently satisfy DMARC. Preserve existing aspf and adkim choices rather than relaxing them without review. DMARC, RFC 9989
RFC 9989 replaces RFC 7489 and removes pct. Do not use that retired tag for a new enforcement rollout. Monitoring is a discovery stage, not a promise to block spoofing. Review all legitimate sources before moving toward quarantine or reject.
Check DNS and a delivered campaign
Replace the capitalized placeholders in 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 @AUTHORITATIVE-NS CNAME YOUR-CRP-OWNER +noall +answer
dig @1.1.1.1 TXT _dmarc.YOUR-FROM-DOMAIN +noall +answer
Expect one SPF policy, the complete issued DKIM public key, the exact CRP alias target and one applicable DMARC policy. Compare a public resolver with the authoritative server; mismatches may be caching, whereas matching wrong answers indicate configuration problems. Check SPF at the actual envelope domain too after obtaining a message.
Send a newly authorized campaign test to a controlled external mailbox, using the production From selection. Capture raw headers, the send time and campaign identity. Inspect From, Return-Path, every DKIM d=/s= and receiver-generated Authentication-Results from inside the receiving service's known processing boundary. Confirm with its administrator or documentation how externally supplied Authentication-Results are stripped or isolated. Header position and a matching authserv-id string alone cannot prove origin; ignore attacker-supplied or untrusted fields and request receiver-side evidence if the boundary is unknown. RFC 8601 section 7.1
Accept the setup only when the originally intended From address appears, not a substituted provider From, the intended branded DKIM signing identity passes with alignment, and DMARC passes through aligned SPF or DKIM. Record SPF pass and alignment separately. Investigate SPF fail, permerror or temperror even when DKIM carries DMARC; a broken custom-return-path SPF configuration is not a completed setup. Diagnose fail as failed sender authorization, temperror as a transient evaluation/DNS issue to investigate and retry, and permerror as invalid policy/evaluation such as duplicates, malformed syntax or exceeded lookup budget. These are not mere alignment mismatches. SPF results Confirm custom return path independently if you configured it. Repeat for distinct sender domains and automated campaign paths before relying on one successful test.
Retain evidence and recover safely
A preview may not follow the final campaign route. Use an approved small seed audience and retain the product/account, sender selection, campaign identifier, timestamp, intended and observed From, envelope/SPF identity and result, every DKIM signature result, applicable alignment mode, trusted receiver boundary and DMARC result. Mark unknown fields unknown. Compare a direct message with a forwarded copy when forwarding matters; do not add a forwarder's infrastructure to Campaigns authorization to conceal downstream failures. See raw DKIM results versus aligned policy results.
Fictional diagnostic case: news@club.example has passed its emailed sender verification, but DKIM is still missing in domain authentication. No final campaign original has been captured, so envelope and signature results remain unknown. Obtain the correct account-issued key, finish domain validation and inspect a controlled final campaign. The verification email itself is not a campaign authentication test. No customer test was performed for this example.
Keep the approved DNS diff, prior values, redacted message evidence and named recovery owner. If a change fails, pause the affected campaign or use a separately approved previously tested route. Restore only the integration's changed configuration; retain selectors needed by in-flight messages and other senders. Retest after rollback, key/region/domain changes or relay migration. Before retiring a sender, inventory scheduled campaigns and workflows. In v3, removing the final address also removes its domain, so deletion is not a harmless verification reset. Never remove unrelated SPF or DMARC protection.
RFC 9989 section 7.4 requires valid DKIM for domains publishing p=reject and cautions about indirect mail. A single SPF-aligned test is not sufficient evidence for a domain-wide enforcement decision.
Troubleshooting and FAQs
Why is Custom Return Path locked?
Complete the current SPF and DKIM setup and authentication first. If both are verified but the control remains unavailable, capture the account's exact status and ask Zoho to investigate rather than deleting working DNS records.
Why does verification fail after publication?
Check the authoritative zone, duplicated domain suffix, wrong TXT/CNAME type and incomplete key. Check CRP host collisions. Allow caching time only after confirming the authoritative answer is correct.
Why does SPF pass while DMARC fails?
The provider may authenticate its own envelope domain without alignment to your From address. Verify custom return path and aligned DKIM. A root SPF include alone cannot fix an unrelated envelope identity.
Does a green Protected status guarantee inbox delivery?
No. It reports the platform's configuration assessment. Receiver authentication, reputation, consent, content and mailbox policy are separate. Keep complaint and bounce diagnosis separate from DNS validation.
Can I reuse these instructions for other Zoho products?
Use EmailAuth's separate Zoho CRM guide for CRM mail. Its native return-path behavior differs; do not import Campaigns' CRP workflow into CRM.
No account configuration, customer DNS change or delivery test was performed. Complete the account, DNS and delivered-campaign checks above for your setup. Authentication does not guarantee inbox placement.