Zoho Mail is a full mailbox host, so it sends all of your day-to-day mail as well as any transactional messages. To pass SPF, DKIM, and DMARC you need exactly three DNS records: one SPF record that authorizes Zoho's servers with include:zohomail.com, one DKIM TXT record you enable per domain inside the Zoho admin console, and one DMARC record that tells receivers what to do when a message fails. Get all three right and aligned, and your mail authenticates at Gmail, Yahoo, and Outlook without landing in spam.
Below is the exact configuration, the single-SPF-record rule that trips up most people, the correct DKIM selector, and a safe none-to-reject DMARC rollout. Check your domain first to see what is already live.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Add one SPF record with include:zohomail.com
SPF is a single DNS TXT record at the root of your domain that lists which servers may send mail for you. For a Zoho-hosted domain, the record is short:
v=spf1 include:zohomail.com ~all
Publish this as a TXT record on your root domain (host @). The include:zohomail.com mechanism pulls in Zoho's current sending IP ranges, so you never hardcode addresses that Zoho might change. The ~all at the end is a softfail, which tells receivers that anything not listed is suspicious but should still be accepted for now. Once your setup is stable and DMARC is enforcing, you can tighten this to -all (hardfail).
The single-SPF-record rule
A domain must have exactly one SPF record. This is the mistake that breaks more Zoho setups than any other. If you also send through a newsletter tool or a CRM, you do not add a second v=spf1 record. You merge the includes into one:
v=spf1 include:zohomail.com include:_spf.google.com ~all
Two separate SPF records is a permanent error (PermError) and receivers treat the whole check as failed. If you are unsure why SPF is failing, our guide on spf-permerror-vs-temperror explains the difference between a syntax problem and a transient DNS timeout.
Watch the 10-lookup limit
SPF caps DNS lookups at 10. Each include counts, and includes can nest, so stacking several ESPs alongside Zoho can push you over the limit and cause a PermError even when every record is syntactically correct. If you send through multiple providers, read fix-spf-too-many-dns-lookups before you add more includes.
Enable DKIM per domain in the Zoho admin console
DKIM adds a cryptographic signature to every outgoing message, which lets receivers confirm the mail really came from your domain and was not altered in transit. Unlike SPF, DKIM is not a record you write by hand from scratch. Zoho generates the key pair for you, and you enable it inside the admin console.
The path is Zoho Mail Admin Console, then Domains, then your domain, then the Email Configuration or DKIM tab. Zoho shows you a selector and a public key, and you publish that public key as a TXT record at the host it gives you. Zoho then signs your mail with the matching private key.
The Zoho DKIM selector
Zoho's DKIM record lives at a selector-based host in this form:
selector._domainkey.yourdomain.com
Zoho typically uses a selector such as zoho or zmail, but do not assume. Copy the exact selector and public key from your own admin console, because the value is unique to your domain and Zoho controls it. The published TXT record looks like this:
zoho._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."
After you publish it, return to the console and click the option to verify or enable DKIM. Zoho will not start signing until it confirms the record is live in DNS, so a message sent before verification will not carry a signature. If you host more than one domain in Zoho, you enable DKIM separately for each one. There is no account-wide toggle that covers every domain at once.
Why alignment matters
DMARC does not just want DKIM to pass, it wants DKIM to align. Alignment means the domain in the DKIM signature (the d= tag) matches the domain in the visible From address. Because Zoho signs with your own domain, alignment is automatic here, which is exactly why a full mailbox host is simpler than a third-party ESP. If you ever see DKIM passing but DMARC still failing, our guide on fix-dkim-alignment walks through the mismatch.
Publish DMARC and start at p=none
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails both. It also unlocks reporting, so you can see who is sending mail as your domain. Publish it as a TXT record at the _dmarc host:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"
Start with p=none. This is monitor-only mode: it changes nothing about how your mail is delivered, but it asks receivers to send you aggregate reports at the rua address. Those reports show every source sending under your domain, which is how you confirm Zoho is authenticating correctly and catch anything you forgot, like a billing system or a marketing tool. Never jump straight to p=reject, because a source you overlooked will get its legitimate mail bounced.
Move DMARC from none to reject in stages
The point of DMARC is enforcement, but you earn it gradually. A staged rollout lets you watch reports and fix problems before any real mail is blocked.
- Week 1 to 2: run
p=noneand read the aggregate reports. Confirm Zoho passes SPF and DKIM with alignment, and identify every other legitimate sender. Our guide on how-to-read-dmarc-aggregate-report shows what the XML is telling you. - Week 3 to 4: move to
p=quarantine. Failing mail now goes to spam rather than the inbox, which is a reversible warning shot. Use thepcttag to ramp gradually if you want, for examplep=quarantine; pct=25to apply the policy to a quarter of failing messages first. - Week 5 onward: move to
p=rejectonce reports are clean. Failing mail is now rejected outright, which is the only policy that actually stops spoofing of your domain.
The enforcing record looks like this:
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s"
For a step-by-step version of this ramp, see how-to-move-dmarc-from-none-to-reject. If you want the reasoning behind each policy level, dmarc-policy-none-quarantine-reject covers the tradeoffs.
Verify every record live in the checker
DNS changes are easy to fat-finger and can take time to propagate, so do not trust that a record is correct just because you pasted it. After each step, confirm the record is actually resolving. Run your domain through the checker at the top of this page and look for three green results: one SPF record (not two), DKIM passing with the correct selector and a valid public key, and a DMARC policy at the level you expect.
Common things the checker will catch: a second stray SPF record left over from a previous host, a DKIM record you published but never clicked to enable in Zoho so signing never started, or a DMARC record still sitting at p=none weeks after you meant to enforce it. Meeting the google-yahoo-sender-requirements for bulk senders means all three have to pass, so verifying live is the difference between mail that authenticates and mail that quietly goes to spam.
Frequently asked questions
What is the Zoho SPF record?
For a domain hosted on Zoho Mail, the SPF record is v=spf1 include:zohomail.com ~all, published as a TXT record on your root domain. If you send through other services too, merge their includes into this one record rather than creating a second SPF record.
Which DKIM selector does Zoho use?
Zoho generates a selector for you in the admin console, commonly zoho or zmail, and the record lives at selector._domainkey.yourdomain.com. Always copy the exact selector and public key from your own console rather than guessing, because the values are unique to your domain.
Do I have to enable DKIM for each domain separately?
Yes. Zoho enables DKIM per domain, so if you host several domains you generate and publish a key and click to enable signing for each one individually. There is no single account-wide switch.
How long before I can set DMARC to p=reject?
Plan on four to six weeks. Run p=none for a couple of weeks to confirm every legitimate sender authenticates, move to p=quarantine for another week or two, then go to p=reject once your aggregate reports are clean. Rushing to reject risks bouncing mail from a source you forgot.