How to set up SPF, DKIM & DMARC for Zoho Mail

Setting up SPF, DKIM and DMARC for Zoho Mail is a 15-minute job, and none of it happens inside Zoho. You publish three records in your own DNS — Zoho only gives you the values. When you're done, mail sent through Zoho will be verifiably yours, and spoofers won't be able to fake your domain. (Zoho runs p=reject on its own domain — the standard is proven at their scale.)

Zoho SPF record

Add this as a TXT record at the root of your domain:

v=spf1 include:zoho.com ~all

include:zoho.com covers Zoho's mail servers, including Zoho CRM sends. The ~all says "softfail" — unlisted senders are marked suspicious but not rejected.

If your mailbox isn't on Zoho's US data centre, the include changes with it: zoho.eu, zoho.in or zoho.com.au. Each publishes its own record, and using the wrong one means your mail fails SPF. The domain you sign in at tells you which you're on.

Publish it, then wait a few minutes for DNS to spread. If your domain already has an SPF record, merge the two — never publish two (that's a permanent error). Watch the 10 DNS lookup limit while you do: include:zoho.com expands to four more includes internally, so it spends five of your ten on its own. Adding Google Workspace or Microsoft 365 alongside it takes you close to the ceiling, and going over means receivers return permerror and treat SPF as failed.

That lookup budget in practice

Five of ten is a lot to spend on one provider, and it is why Zoho domains hit the SPF ceiling sooner than most. A realistic small-business record — Zoho for mailboxes, one marketing platform, one CRM or invoicing tool — is already at eight or nine lookups before anyone notices. The failure mode is nasty because it is silent and it is global: once a record permerrors, receivers stop evaluating SPF for every message you send, including the ones that would have passed.

Two things keep you under it. First, remove includes for services you no longer use — SPF records accumulate dead entries faster than anything else in DNS. Second, lean on DKIM: a service that signs with DKIM aligned to your domain passes DMARC without costing you an SPF lookup at all. Count where you stand with the free SPF record checker, which resolves every include and tells you which ones are expensive.

Zoho DKIM

In the Zoho Mail admin console (Domains → your domain → DKIM), Zoho generates a keypair and shows you a TXT record. Publish it at the selector it names — usually zoho._domainkey.yourdomain.com — then click Verify in Zoho.

That's the whole trick: Zoho holds the private key, DNS holds the public key, and receivers can now check that every message signed by Zoho genuinely came from your domain — even after forwarding.

Two details worth getting right while you're in there:

• Publish before you verify. Zoho's Verify button checks DNS live. Clicking it before the record has propagated returns a failure that looks like a configuration error, and people go back and regenerate the key — which invalidates the record they just published and starts the loop again. Wait, then verify.
• Watch the TXT value's length. A 2048-bit key is longer than the 255-character limit on a single DNS string, so providers split it into several quoted chunks. Most panels do this for you; a few require you to paste it as-is and will silently truncate. If the DKIM checker finds the selector but reports the key as malformed, truncation is why.

Zoho MX records

Not authentication, but the same region rule applies and it belongs on the same checklist. Zoho's mail servers are regional, so a domain pointed at the US hosts while the mailbox lives in the EU will not receive mail. Take the exact hostnames from the Zoho admin console for your account rather than from any guide, including this one — they're shown in the same Domains section as the DKIM settings, with the priorities to use.

The other Zoho products that send as you

Zoho Mail is rarely the only Zoho service touching your domain, and this is where DMARC reports produce surprises. Zoho Campaigns, Zoho CRM, Zoho Desk, Zoho Books and Zoho Bookings can all send with your domain in the From address, and each has its own domain-authentication screen inside its own product — enabling DKIM in Zoho Mail does not enable it in Zoho Campaigns.

The pattern is the same each time: find the sender-domain or email-authentication settings in that product, publish the DKIM record it hands you at the selector it names, and verify. Until you do, mail from that product may pass SPF via include:zoho.com while failing DMARC alignment, which is exactly the case that breaks the day you move to p=reject.

This is the argument for spending real time at p=none. The aggregate reports name every one of these senders before you enforce anything.

Zoho DMARC record

Start in monitoring mode with reports going to a mailbox you actually read:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

Watch the reports for a week or two. Once every sender in them is one you recognize, tighten to quarantine, then reject:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; sp=reject; adkim=s; aspf=s

sp=reject protects your subdomains too. The full format is covered in DMARC record examples.

The record goes in your DNS provider's panel, not in Zoho — host _dmarc, type TXT, value as above. If the panel appends your domain automatically (most do), enter _dmarc alone; typing the full _dmarc.yourdomain.com creates a record at _dmarc.yourdomain.com.yourdomain.com that nothing will ever read. That single mistake accounts for most "I published it and the checker says it isn't there" reports.

A note on strict alignment

The enforcement record above sets adkim=s and aspf=s, which require the signing and envelope domains to match your From domain exactly rather than merely sharing an organisational domain. That's the stronger setting, and it's the right destination — but if you send from subdomains (news.yourdomain.com, billing.yourdomain.com) with signatures from the parent, strict alignment will fail them. Move to strict after your reports show it passing, not before, and read DMARC policies explained for the sequencing.

What changes in your reports

Before: mail from Zoho shows SPF and DKIM passing — but aligned to zoho.com, not you, so DMARC fails. After: the same checks pass for your domain, DMARC passes, and the aggregate reports you receive list only senders you own. Anything else on the list is someone trying to use your name.

Reports arrive as compressed XML attachments, typically within a day or two of publishing your record. If you'd rather see what's in one before committing to a monitor, the free DMARC report analyzer parses a report in your browser and shows the per-sender table; DMARC aggregate reports explained covers the format itself.

Troubleshooting

SPF passes for zoho.com but DMARC still fails

That's an alignment failure, not an SPF failure, and it means DKIM isn't set up — or is set up in Zoho Mail but not in whichever Zoho product sent the message. DMARC needs SPF or DKIM to pass for your domain, and Zoho's envelope sender is Zoho's, so DKIM is what carries your domain across.

The DKIM checker can't find my key

Check the selector name first. Zoho usually issues zoho._domainkey, but a domain that has had a key regenerated may be signing under a different label. The definitive answer is in the s= tag of the DKIM-Signature header on any message you've sent through Zoho — Gmail's "Show original" will show you it in about ten seconds.

Everything worked, and then it stopped

Records rot. A regenerated Zoho key that never got republished, a registrar migration that dropped TXT records, an SPF include that grew past the lookup limit on the provider's side — all of them break mail that was working yesterday, with no notification to you. That's DNS drift, and it's the reason a one-off check has a short shelf life.

Free checks: DMARC checker SPF checker DKIM checker Spam checker

Done? Run the free DMARC checker — it reads your live DNS and confirms all three records parse and align. For the staged walk from p=none to p=reject, see DMARC policies explained.