How to set up DMARC/DKIM/SPF for Zoho Campaigns
Updated on 19 Oct 2026: We updated the Zoho Campaigns setup steps, regional SPF values, and DMARC enforcement guidance for RFC 9989.
Configure Zoho Campaigns with DKIM as the primary DMARC pass path, then add a custom Return-Path so SPF can match the visible From domain too. Publish Zoho's account-specific values, verify them inside Campaigns, and add one DMARC TXT record at _dmarc.
Add your domain
Zoho Campaigns creates the domain entry when you verify a sender address. Use a real, monitored mailbox on a domain whose DNS you control. Public mailbox domains cannot be authenticated by you. If domain authentication settings are unavailable to your role, ask the organization's admin to open them.
- Open settings. In Zoho Campaigns, open Settings, then Email, then Senders and Authentication.
- Add the sender. Select Add Sender, enter the sender name and campaign sender address, then select Save to send the verification email.
- Confirm ownership. Open Zoho's message in that mailbox and select its verification link. Use Resend Verification if it expires.
- Open the domain. Return to Senders and Authentication, find the domain, and select Setup.
- Copy generated values. Keep this page open because the SPF value depends on the account's data center, and the DKIM selector and public key are account-specific.
Adding and verifying a sender in Zoho Campaigns
Use the campaign From domain
Authenticate every domain used after the @ sign in a campaign From address. Authenticating a different corporate domain does not cover it. Each added sender address still needs mailbox verification, even when its domain is already authenticated.
Zoho's current authentication instructions use Settings > Email > Senders and Authentication. Older layouts use Manage Senders and Domain Authentication under Settings > Deliverability.
Choose the correct regional SPF include
Use the SPF include generated by your Zoho Campaigns account, rather than choosing one by your physical location. Zoho's DNS setup instructions list these data-center values.
|
|
|---|---|
US | include:zcsend.net |
EU | include:eu.zcsend.net |
Australia | include:au.zcsend.net |
India | include:zcsend.in |
Japan | include:sender.zcsend.jp |
China | include:zcsend.net.cn |
Canada | include:zcsend.ca |
Saudi Arabia | include:zcsend.sa |
Zoho Campaigns SPF values by account data center
The examples below use the US include. Substitute the value shown in your account, and do not add every regional include to one SPF record.
Set up SPF
Zoho Campaigns supplies include:zcsend.net for US accounts. If the domain already has SPF, edit that record and insert your account's include before the final all mechanism. Never publish a second SPF record at the same host.
- Copy the value. Select Setup beside the domain and copy the SPF TXT value shown by Zoho.
- Check existing DNS. Look for a TXT record beginning with v=spf1 at the domain Zoho specifies.
- Merge when needed. Add the account's regional include to the existing value, preserving other authorized senders and one final all mechanism.
- Publish the TXT record. Use the host Zoho requests. For a root domain, the DNS provider often expects @ or a blank name.
- Add a custom Return-Path after DKIM. Once SPF and DKIM are configured, reopen Setup, expand Custom Return Path, enter an unused host such as bounce, publish Zoho's CNAME, and select Validate CRP.
SPF value for a US account with no existing SPFdns
v=spf1 include:zcsend.net ~all
Merge the US Zoho include into an existing SPF recorddns
v=spf1 include:mail.example.net include:zcsend.net ~all
Copying SPF and DKIM DNS values in Zoho Campaigns
SPF checks the MAIL FROM domain shown in Return-Path. The custom Return-Path CNAME lets receivers resolve Zoho's SPF policy for your bounce subdomain. Adding Zoho's include only to the root domain does not make a default zcsend.net Return-Path match your From domain.
Check the published record before sending. The result should contain one SPF policy, the correct regional include, a valid final all mechanism, and no more than ten lookup-causing SPF terms, including nested includes and redirect.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
The checker should find exactly one policy. A permerror usually means duplicate records, malformed syntax, or more than ten DNS lookups. Fix that before Zoho's verification step.
Send a campaign test after the custom Return-Path verifies. In the received headers, the Return-Path should use the custom subdomain and SPF should pass.
Creating a custom Return-Path in Zoho Campaigns
Check custom Return-Path prerequisites
The Custom Return Path section stays locked until SPF and DKIM are configured. Use an unused subdomain without existing MX, TXT, or address records; do not add an SPF TXT record beside its CNAME. Publish the exact CNAME target Zoho generates for the account.
For From: sender@example.com and Return-Path: bounce@bounce.example.com, default relaxed SPF matching works because both share example.com. With aspf=s, those domains do not match exactly; matching DKIM is still enough for DMARC. Zoho's custom Return-Path instructions explain setup and CNAME restrictions.
Set up DKIM
DKIM is the most dependable DMARC pass path for Zoho Campaigns because it survives forwarding more often than SPF. Copy the selector and public key directly from the Zoho setup screen rather than typing either value.
- Open DKIM setup. Select Setup beside the domain in Senders and Authentication, and locate DKIM.
- Copy the host. Use the selector and _domainkey host exactly as Zoho displays them.
- Copy the public key. Publish the complete TXT value without inserting line breaks, extra quote characters, or omitting key material.
- Save DNS. Confirm whether the DNS provider automatically appends the zone name so it does not appear twice.
- Verify in Zoho. Return to the setup window and select Authenticate after the TXT record resolves publicly. Older layouts label this Verify Domain.
DKIM record shape, use Zoho's generated valuesdns
Host: <selector>._domainkey Type: TXT Value: v=DKIM1; k=rsa; p=<public-key-from-Zoho>
Publishing the Zoho Campaigns DKIM record
DKIM success condition
A test message needs dkim=pass, and the DKIM d= domain must match the visible From domain under relaxed or strict DMARC rules. The selector only locates the public key. It does not need to match the From domain.
The v=DKIM1 tag is optional in a DKIM key record, so keep Zoho's generated value if it starts with k=rsa. A DNS provider can split a long value into quoted strings within one TXT record; the joined value must preserve the complete key.
Set up DMARC
A new DMARC record can collect reports with p=none while SPF and DKIM are being configured. Start with the DMARC record generator, unless the domain already uses p=quarantine or p=reject. Keep an existing enforcement policy and repair Zoho beneath it instead of lowering protection. Zoho Campaigns checks the DMARC record published in DNS; it does not generate the record for you.
Initial DMARC TXT recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Choose the mailbox. Replace dmarc@example.com with an address or reporting endpoint that accepts aggregate XML reports. For an external reporting domain, complete the destination's authorization requirements.
- Use the DMARC host. Create one TXT record at _dmarc for the From domain. For example.com, the full name is _dmarc.example.com. For news.example.com, it is _dmarc.news.example.com.
- Publish one policy. Remove duplicate DMARC TXT records because receivers cannot choose between them.
- Check matching mode. Default aspf=r and adkim=r accept a shared organizational domain. Strict mode requires an exact domain match.
- Collect reports. Allow at least one complete sending cycle before judging which sources belong to the domain.
Verified SPF and DKIM status in Zoho Campaigns
After DNS propagation, open the DMARC checker and enter the From domain. The parsed result should show version DMARC1, the intended policy, and the intended aggregate-report destination.
A valid DMARC record does not prove that Zoho messages pass. It publishes the receiver policy and reporting destinations. Test a real campaign and inspect the authentication results next.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If the checker finds no record, confirm the host contains _dmarc exactly once. DNS control panels that append the zone can turn a full host into _dmarc.example.com.example.com. A sending subdomain without its own record can inherit the organizational domain's policy, so check the effective policy before creating another record.
Zoho's DMARC guidance confirms that either the SPF path or DKIM path can satisfy DMARC when its domain matches the From domain.
Verify and troubleshoot
Verify DNS first in Zoho Campaigns, then test a delivered campaign. Zoho's green status proves its DNS lookup worked, while the received message proves the exact sending path passes DMARC.
- Wait for public DNS. Check the authoritative answer instead of relying on the record shown in the DNS control panel.
- Run Zoho verification. Open the domain's Setup window and select Authenticate, or Verify Domain in an older layout. Read the reason shown beside any failed record.
- Send a fresh campaign. Do not reuse a message sent before verification because it lacks the new DKIM signature or Return-Path.
- Inspect results. In the receiving server's Authentication-Results header, require dkim=pass and dmarc=pass. SPF should also pass and use the custom bounce domain.
- Confirm both domains. Compare the visible From domain with the DKIM d= domain and the SPF smtp.mailfrom domain shown in Authentication-Results.
|
|
|
|---|---|---|
SPF permerror | Duplicate SPF records, invalid syntax, or more than ten lookups | Merge the policies at that host and check nested includes |
SPF passes but its domain does not match | Default Return-Path or strict aspf=s with a bounce subdomain | Verify the custom Return-Path and check the policy's matching mode |
DKIM key not found | Wrong selector host or missing TXT record | Look up the signature's s= selector under its d= domain |
DKIM fail | Wrong key or a message modified after signing | Compare the public key with Zoho's value and send a fresh direct test |
DMARC fail | Neither passing authentication method has a matching domain | Fix DKIM for the campaign From domain first |
Custom Return-Path validation fails | Wrong CNAME target or conflicting records at the bounce host | Use an unused host and publish the exact account-specific CNAME |
Fast checks for common Zoho Campaigns authentication failures
The fastest end-to-end check is a real message. Send a Zoho Campaigns test campaign to Suped's email tester so it can inspect the message headers, authentication results, DNS, content, and routing.
Use a newly generated test address and send directly through Zoho Campaigns. Forwarding a copy changes the route and can invalidate SPF, which makes the diagnosis less useful.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A passing result should show DMARC pass through DKIM, plus SPF pass through the custom Return-Path. If only DKIM supplies the matching pass, the message still passes DMARC. Check the actual campaign route with a small controlled recipient group before a full send, because preview tests do not prove every production path uses the same authentication.
When Zoho says verification failed, compare the public DNS answer character by character with the value in Campaigns. The most common faults are a duplicated zone suffix, split SPF policies, copied smart quotes, and a truncated DKIM key.
SPF passes but DMARC does not
- Compare domains. SPF can pass for zcsend.net while DMARC rejects that path because From uses your domain.
- Fix the path. Verify the custom Return-Path CNAME and send a new test.
DKIM passes but DMARC does not
- Read the d= value. A valid signature for a different organizational domain does not satisfy DMARC.
- Fix domain choice. Authenticate the exact campaign From domain in Zoho and retest.
Monitor authentication failures
A one-time pass does not cover later DNS edits or changes to sending sources. Suped is our DMARC reporting and email authentication platform. Suped's DMARC monitoring turns aggregate reports into source-level issues and repair steps.
- Detect changes. Automated issue detection identifies new SPF, DKIM, and DMARC failures in incoming aggregate reports.
- Respond to alerts. Alerts surface failure changes after receivers submit reports. Aggregate reports commonly cover a day of traffic, so use direct campaign tests for immediate checks.
- Separate sources. Source identification keeps expected Zoho Campaigns traffic apart from unknown infrastructure using the domain.
- Watch reputation. Check blocklist (blacklist) events separately from authentication failures; a DMARC pass does not guarantee inbox placement.
- Manage at scale. The multi-tenant dashboard keeps client domains and their Zoho sources in one place.
Investigate sudden DMARC failure growth or a previously unseen source. A failed campaign then has a clear response: confirm the source, inspect its pass paths, correct DNS, and retest.
Practical monitoring workflow
- Triage the source. Confirm whether the failing traffic belongs to Zoho Campaigns.
- Read the failure. Distinguish authentication failure from a domain mismatch.
- Apply the repair. Use Suped's tailored steps to correct the affected record or Zoho setting.
- Prove recovery. Send a fresh campaign test and confirm the failure rate returns to baseline in subsequent reports.
Secure your domain with p=reject
Move beyond p=none only when every legitimate source has a matching SPF or DKIM pass. Use Suped's source reports to check approved senders and unresolved failures before changing policy.
- Build the inventory. Review aggregate reports across a complete business sending cycle and classify every source.
- Fix legitimate traffic. Require Zoho Campaigns and every other approved sender to pass through a matching domain.
- Apply quarantine. Use p=quarantine only after approved sources pass, then monitor legitimate-message failures. Do not rely on pct to limit exposure.
- Review the evidence. Check campaign tests and subsequent reports for unexplained legitimate failures before increasing enforcement.
- Apply reject. Set p=reject when the monitored quarantine stage shows that legitimate sending paths pass DMARC.
- Keep monitoring. Treat new sources and pass-rate drops as change events that need ownership and resolution.
Example enforcement stages, publish one record at a timedns
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
RFC 9989 made pct historic. Receivers implementing the revised standard ignore it, while older receivers differ in how they apply it. Do not treat pct=25 as a reliable enforcement limit. Receiver filtering decisions still apply independently of your requested policy.
Ready to enforce
- Zoho passes. Fresh tests show DKIM and DMARC pass.
- Sources are known. Report data contains no unexplained legitimate sender.
- Owners are ready. Each approved source has a contact for failures.
Pause escalation
- Traffic is unknown. A material source still lacks an owner.
- Failures are legitimate. Approved campaigns still lack a matching pass.
- Reports are incomplete. The observation window missed regular business sends.
Do not downgrade an enforced domain
If the domain already has p=quarantine or p=reject, keep that policy. Repair Zoho Campaigns under the current policy, test with a controlled recipient, and use report data to confirm recovery.
Frequently asked questions
Publish the SPF include shown for your account and the account-specific DKIM TXT record, then publish one DMARC TXT record at _dmarc. Configure the custom Return-Path CNAME so SPF can also pass with a matching domain. DMARC requires either a passing SPF result or a passing DKIM result with a domain that matches the visible From domain.
No. A domain must have one SPF record at a given host. Insert the regional include shown in your account into the existing policy before its final all mechanism, then confirm the expanded policy stays within the ten-lookup limit.
The default Zoho Campaigns Return-Path uses Zoho infrastructure rather than your From domain. SPF can authenticate that domain without satisfying DMARC's domain-matching requirement. Configure and verify the custom Return-Path CNAME. If the policy uses aspf=s, a bounce subdomain still does not match the From domain exactly; matching DKIM can provide the DMARC pass.
zcsend.net commonly identifies Zoho Campaigns sending and bounce infrastructure. Confirm the source with the full message headers and DMARC report data because a domain suffix alone does not prove authorization.
Verification works after the public DNS answer contains the exact record Zoho generated. Zoho's current instructions allow up to 24 hours for DNS changes to become visible globally. Cached positive and negative answers affect timing. Once the records resolve, select Authenticate and validate the custom Return-Path separately.
Use p=reject after fresh Zoho tests pass DMARC, all legitimate sources are identified, aggregate reports show no unexplained business traffic, and a monitored quarantine stage shows no legitimate authentication failures. Do not rely on pct for a percentage rollout. Keep p=reject if it is already active.
