Do I use include:zohomail.com or include:zoho.com in my SPF record?

Zoho's Admin Console documentation gives include:zohomail.com as the value for Zoho Mail. Zoho also documents including zoho.com, which covers its sending services collectively and is the better choice if the business sends from other Zoho products as well. Use one or the other, never both, and never as two separate TXT records. Your domain gets exactly one SPF record, and Zoho warns that publishing more than one interrupts delivery.

I added the DKIM record but Zoho still shows it as not verified. What now?

Three causes cover almost every case. The host was entered as the full name, so the record ended up at s1._domainkey.yourdomain.com.yourdomain.com instead of s1._domainkey.yourdomain.com, because most DNS editors append the domain for you. The public key was truncated or broke across lines when pasted. Or the record simply has not propagated yet, which can take a few hours. Fix the first two, wait, then press verify in the Admin Console again. Zoho does not sign your mail until that verification passes.

Does the free Zoho plan support SPF, DKIM and DMARC?

Authentication is not a paid feature, because it does not live at Zoho. SPF, DKIM and DMARC are records in your own DNS zone, and the DKIM selector and DMARC record are generated in the Admin Console that every organization has. What the free tier restricts is access and administration: IMAP, POP and ActiveSync are paid, along with features such as email routing and single sign-on. Receiving servers apply the same filtering whatever you pay.

Zoho Mail: SPF, DKIM and DMARC set up properly

Say a nine-person consultancy calls us because their proposals stopped arriving. Nothing changed on their side, they insist. Their mail runs on Zoho, the domain sits at a registrar someone configured years ago, and the DNS zone holds one TXT record starting with v=spf1 that still names the hosting company they left behind. Zoho signs nothing, because nobody ever created a DKIM selector. Gmail is doing exactly what it has published that it will do.

Zoho Mail is a sensible choice for a small business, and it hands you every authentication control you need inside the Admin Console. It just does not switch them on for you. This is the setup we run on a Zoho domain, in the order we run it, with the three failures we find most often on the way.

Start with the zone the internet actually reads

Before touching a record, we confirm where the domain's nameservers point. A Zoho customer typically has three plausible DNS panels: the registrar, a web host, and whatever CDN was added later. Only one of them is authoritative, and records added to the other two look perfect and do nothing at all. Check the nameservers, then edit only there.

The second thing we check is which Zoho data center the organization lives in. Zoho runs separate regional data centers, and the records differ between them. Zoho documents that the MX hostname's top-level domain varies by data center, and that the DKIM and SPF values generated for each one are different. The Admin Console's Tools and Configurations section shows the correct values for your account. Copy from there, not from a blog post, including this one.

MX first, and the priority that quietly wins

Authentication only matters once delivery works, so mail routing comes first. Zoho publishes three inbound hosts, mx.zoho.com, mx2.zoho.com and mx3.zoho.com, with ascending priority numbers, and the correct suffix for your data center appears in the console.

Type: MX   Host: @   Value: mx.zoho.com    Priority: 10
Type: MX   Host: @   Value: mx2.zoho.com   Priority: 20
Type: MX   Host: @   Value: mx3.zoho.com   Priority: 50

The failure we see here is leftovers. Zoho's own guidance is blunt about it: if another MX entry survives with a lower priority number, such as 0 or 5, mail will not reach Zoho at all. Lower numbers win. Delete every MX record belonging to the previous provider rather than leaving one in place as a safety net, because that safety net is where the mail goes.

SPF: exactly one record, and the value the console gives you

SPF names the servers allowed to send for your domain. Zoho's Admin Console documentation gives the value for Zoho Mail as a single TXT record on the root of the domain.

Type: TXT   Host: @   Value: v=spf1 include:zohomail.com ~all

Zoho also documents a broader form. If the business uses other Zoho products that send mail, including zoho.com covers Zoho's sending services collectively rather than Zoho Mail alone. Pick one of the two, not both.

The rule that breaks more domains than any other: a domain gets one SPF record. Zoho states it plainly, that every domain should have a single SPF record covering every server it sends from, and that publishing several TXT records of the SPF type interrupts delivery. This is not a Zoho quirk. RFC 7208 defines the behavior, and a checking server that finds two policies treats the result as a permanent error, which means neither one applies. If a record already exists, you extend it. You do not add a second.

So a domain with mailboxes on Zoho and a store platform sending order confirmations gets one merged record, with the mechanisms in the middle and one ~all at the end:

v=spf1 include:zohomail.com include:someplatform.example ~all

Keep an eye on the count while you merge. SPF allows a limited number of DNS lookups per evaluation, and every include spends from that budget. Cross the line and the record fails with a permanent error even though it reads correctly. We wrote up how to get back under the limit in the SPF lookup guide.

DKIM: Zoho signs nothing until you create a selector

This is the step small teams skip, because SPF feels like it was the hard part and mail appears to work afterwards. It works until a receiver decides to be strict, or until a message gets forwarded and SPF stops being usable.

In the Admin Console, open Domains, pick the domain, go to the Email Configuration tab and choose DKIM. Add a selector, give it a name, and choose a key length of 1024 or 2048 bits. Zoho generates the TXT value and shows it beside the selector you created.

Publish it in DNS as a TXT record whose host follows the standard selector format:

Type: TXT
Host: s1._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkq...   (the full value from the console)

Two details decide whether this works. The host is <selector>._domainkey followed by your domain, and most DNS editors append the domain for you, so pasting the fully qualified name creates a record one level too deep that nothing will ever read. And the public key value is long. Copy it whole, with no line breaks introduced by the paste.

Then go back to the Admin Console and verify the selector there. Zoho does not start signing until you do, and the record can take a few hours to propagate before verification succeeds. Publishing the record and walking away is the version of this that fails silently.

The senders that are not Zoho

Once the mailbox domain is clean, we inventory everything else that sends using the same From address. On a typical small business this list is longer than the owner expects: the invoicing or billing platform, the CRM, the website contact form, the appointment tool, the accountant's system, sometimes a scanner or a copier in the corner.

Each one needs to be either authorized in SPF, signing with DKIM, or moved to a subdomain of its own. Anything sending as your domain without one of those is a message that fails authentication, and once you enforce a DMARC policy it is a message that disappears.

Zoho Campaigns needs its own records

Teams assume that authenticating Zoho Mail covers the rest of the Zoho suite. It does not. Zoho Campaigns has a separate domain authentication flow: you add the sender domain, copy the SPF and DKIM TXT records that Campaigns generates, publish them in DNS, and verify inside Campaigns. It lives under Settings, in Manage Senders beneath Deliverability, and sender addresses are verified by email confirmation as part of the same process.

The reason this matters beyond a checkbox is alignment. DMARC does not just ask whether SPF or DKIM passed. It asks whether the domain that passed matches the domain your recipients see in the From line. Marketing mail sent through a platform that signs with its own domain passes DKIM and still fails DMARC, and the aggregate reports are the only place you would notice.

DMARC, and actually reading what comes back

DMARC ties the two together and tells receivers what to do when neither aligns. Zoho generates the record for you: in the same Email Configuration tab, choose DMARC, pick the action for failures, and give an address to receive aggregate reports. There is a Regenerate button for changing it later, and the generated record still has to be published in your DNS by hand.

Type: TXT   Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Start at p=none. It changes nothing about delivery and starts the reports flowing, which is the entire point of the first two weeks. Zoho surfaces them inside the Admin Console as well, under Reports, in the Compliance section, where the DMARC view breaks down which messages passed and which failed SPF, DKIM and DMARC.

Those reports are XML, and the first one is genuinely unpleasant to read. We took one apart line by line in the guide to aggregate reports. Only once every legitimate sender in those reports is aligned do we tighten the policy, and we do it in stages rather than in one move, which is its own careful process.

Why the free plan still needs all three

Zoho's free tier is what brings a lot of small businesses in, and it comes with real limits. Access is through webmail and the mobile apps, with IMAP, POP and ActiveSync reserved for paid plans, alongside things like email routing and single sign-on.

Authentication is not on that list, and it could not be. SPF, DKIM and DMARC are records in your DNS zone, which you own whatever you pay Zoho. The receiving side does not know or care which plan you are on either. Google's published sender guidelines ask every sender to set up SPF or DKIM, to keep the spam rate reported in Postmaster Tools under 0.3 percent, and to make the From domain align with the SPF or the DKIM domain. Senders above 5,000 messages a day to Gmail have had to have all three since 1 February 2024, with a DMARC policy that may be as gentle as p=none.

A ten-person company sending quotes and invoices is nowhere near 5,000 a day. It is also not exempt from filtering, and the low-volume sender has less reputation history to fall back on, not more. Three DNS records is the cheapest deliverability work that exists.

When Zoho stops being the right fit

We are not religious about the platform, and part of an honest engagement is saying when the tool is the problem. The usual pressure points are desktop clients and older devices that need IMAP, shared calendars and files for a team that has outgrown ad hoc sharing, and admin controls when the business starts caring about device management and retention. If those are the constraints, the conversation is about Google Workspace rather than another DNS record, and the migration is a separate project with its own cutover plan.

If none of those apply, a properly authenticated Zoho domain delivers perfectly well, and changing platform would fix nothing that the three records above do not.

How Guanacos Tech helps

We do this end to end for small and mid-sized companies across North America and Latin America: audit the zone, fix the routing, publish and verify the three records, find the senders nobody remembered, then read a few weeks of DMARC reports before moving the policy to enforcement. If your Zoho mail is landing in spam and you would rather not guess, run your domain through the checks above, or book a call and we will look at it with you. More on the full engagement in email deliverability.

Zoho Mail SPF, DKIM and DMARC: the setup we run, and why the free plan needs all three