Email authentication for Zoho Mail: SPF, DKIM and DMARC

23 April 2026 · 12 min read

Zoho Mail is a popular choice for businesses that want professional email on their own domain without paying Google Workspace or Microsoft 365 prices. The catch is that hosting your mailboxes with Zoho does not, on its own, make your mail trusted. Gmail, Yahoo, Apple and Microsoft now expect every domain that sends them mail to pass SPF, DKIM and DMARC, and to do so in an aligned way. Zoho gives you the building blocks in its Admin Console, but the records still live in your DNS, and the order you publish them in decides whether you reach enforcement cleanly or bounce legitimate mail.

This guide is specific to Zoho Mail. It covers the exact SPF include Zoho uses, how DKIM selectors work in the Zoho Admin Console, the return-path and alignment quirks that trip people up, and a safe sequence to take a Zoho-hosted domain from no protection to p=reject. It assumes you are using Zoho Mail for your own custom domain (for example yourcompany.com), not the free @zohomail.com addresses, which you cannot authenticate yourself.

How email authentication works when Zoho sends your mail

When a Zoho user sends a message from you@yourcompany.com, Zoho's outbound mail servers connect to the recipient and present three things a receiving server can check:

• The envelope sender (also called the return-path or MAIL FROM), which the receiver uses for SPF.
• A DKIM signature in the message header, signed with a private key Zoho holds, verifiable against a public key you publish in DNS.
• The From header your recipient actually sees, which is you@yourcompany.com.

DMARC ties these together. It passes only if at least one of SPF or DKIM both authenticates and aligns with the domain in the visible From address. Alignment is the part people miss: SPF can pass for Zoho's own domain while still failing DMARC, because the domain that passed SPF is not the domain in your From header. We will return to this, because with Zoho it is the single most important concept.

If any of this is unfamiliar, our glossary defines each term, and /blog/dmarc-alignment-explained walks through alignment in detail. For the rest of this article we will stay focused on Zoho.

Step 1: Verify your domain and point MX to Zoho

Before authentication matters at all, your domain has to be verified in Zoho and your inbound mail has to flow to Zoho's servers. In the Zoho Mail Admin Console under Domains, Zoho asks you to add a verification record (a TXT or CNAME) to prove you control the domain, then to publish Zoho's MX records:

yourcompany.com.   MX   10   mx.zoho.com.
yourcompany.com.   MX   20   mx2.zoho.com.
yourcompany.com.   MX   50   mx3.zoho.com.

Regional data centres use different hostnames. If your Zoho account lives in the EU, India or Australia, the MX hosts may read mx.zoho.eu, mx.zoho.in or mx.zoho.com.au. Always copy the exact values the Admin Console shows you rather than the ones above, because the data centre your account sits in determines which sending and DKIM infrastructure your mail uses too. This matters later for SPF.

MX records affect inbound mail only. They are not part of SPF, DKIM or DMARC, but getting them wrong means your verification stalls and nothing else can proceed. Once the domain shows as verified and active, move on to authentication.

Step 2: Publish the Zoho SPF record

SPF declares which servers are allowed to send mail using your domain in the envelope sender. Zoho publishes its sending infrastructure behind a single include, so you do not list individual IP addresses. The record Zoho's documentation directs you to publish is:

v=spf1 include:zohomail.com -all

Publish this as a TXT record on the root of your domain (host @, or yourcompany.com). A few rules that catch people out:

• A domain may have only one SPF record. If you already have a v=spf1 record (perhaps from a previous provider or a marketing tool), do not add a second one. Merge the includes into the existing record instead. Two separate SPF TXT records is a permanent error and SPF will fail for everyone.
• The -all at the end is a hard fail: it tells receivers that anything not covered by the record is unauthorised. This is the correct, strict choice once you are confident every sender is listed. If you are still adding sources, ~all (soft fail) is a safer temporary setting, but plan to tighten it to -all.

When you use more than one Zoho product

If you send through Zoho Mail and also Zoho Campaigns, Zoho CRM, Zoho Desk or Zoho's transactional service, those can sign or send from your domain too. Rather than stacking several Zoho includes (each include costs a DNS lookup, and SPF permanently fails above ten), Zoho provides a consolidated include:

v=spf1 include:one.zoho.com -all

include:one.zoho.com is designed to cover the broader Zoho suite under a single lookup, which keeps you well under the limit. Use the single-product include:zohomail.com if Zoho Mail is your only Zoho sender; use include:one.zoho.com if you have several Zoho services authorised on the domain.

If you also send through non-Zoho services

Real businesses rarely send through one platform. You might use Zoho Mail for staff mailboxes, plus a separate provider for invoices, newsletters or your help desk. Each of those needs to be in the same single SPF record. A combined record might look like:

v=spf1 include:zohomail.com include:_spf.example-esp.com include:servers.example-crm.net -all

Every include triggers a DNS lookup, and some providers' includes expand into several more behind the scenes. SPF allows a maximum of ten DNS lookups before it returns a PermError and stops authenticating. Zoho's own include is lean, but stacking three or four third parties on top can quietly push you over. If you hit that wall, our explainer at /blog/spf-10-lookup-limit covers the rule, and /blog/fix-spf-permerror covers the fix. Automatic flattening, described in /docs/how-spf-flattening-works, keeps the record under the limit without you hand-editing IPs every time a provider changes theirs.

When you have published it, confirm the record resolves and counts correctly with our SPF checker. For a wider look at how different platforms phrase their includes, see /blog/spf-for-common-providers.

Step 3: Enable and publish DKIM in Zoho

DKIM is the stronger of the two mechanisms, and for Zoho it is the one that does the heavy lifting for DMARC alignment (more on that below). DKIM attaches a cryptographic signature to every outgoing message. Receivers fetch your public key from DNS and verify the signature was made with the matching private key, which Zoho holds and never exposes.

In Zoho, DKIM is off by default and you must generate it per domain. The flow in the Admin Console is:

1. Go to Domains, select your domain, and open Email Configuration (sometimes shown as DKIM).
2. Click Add to create a new DKIM key.
3. Provide a selector name. Zoho lets you choose this; its documentation uses zoho as the example. Pick something short and lowercase such as zoho or zmail.
4. Zoho generates a public key and shows you the TXT record to publish.

What the DKIM record looks like

Zoho gives you a host (name) and a value. The host follows the standard DKIM pattern:

zoho._domainkey.yourcompany.com.   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

The selector you chose sits in front of ._domainkey. So if you named your selector zoho, the host is zoho._domainkey; if you named it zmail, it is zmail._domainkey. The long p= string is your public key. Some DNS providers (GoDaddy, Namecheap, Squarespace, Wix and others) automatically append your domain to the host, so you enter only zoho._domainkey rather than the full zoho._domainkey.yourcompany.com. Entering the full name where the provider also appends the domain is a classic mistake that produces a record at zoho._domainkey.yourcompany.com.yourcompany.com and silently breaks DKIM.

A few Zoho-specific notes:

• The public key Zoho issues is typically a single long string, but DNS TXT records are limited to 255 characters per chunk. If your DNS provider does not split it for you, you may need to break the value into multiple quoted strings. Get this wrong and the key will not parse.
• After publishing, return to the Admin Console and click Verify, then Enable. Zoho does not start signing your mail until DKIM is verified and switched on. Publishing the DNS record alone is not enough; the activation step in Zoho is what makes outbound mail carry the signature.
• You can add multiple selectors in Zoho, which is useful if you want to rotate keys or separate signing for different groups of users. For most domains, one selector is plenty.

Once DKIM is enabled and live, validate it with our DKIM checker by entering your domain and the selector you chose. Background on why selectors exist and how to manage them sits at /blog/dkim-selectors-explained, and our managed approach is described in /docs/hosted-dkim.

Step 4: Understand Zoho's return-path and alignment behaviour

This is where Zoho deserves a section of its own, because it is the difference between DMARC passing and failing.

DMARC requires alignment, not just authentication. There are two ways to align:

• SPF alignment: the domain in the envelope return-path matches (relaxed mode) or equals (strict mode) the domain in your visible From address.
• DKIM alignment: the d= domain in the DKIM signature matches your From domain.

For a domain hosted on Zoho Mail with the records above:

• DKIM aligns naturally. When you enable DKIM for yourcompany.com in Zoho, the signature carries d=yourcompany.com, which exactly matches your From domain. That alignment is what carries DMARC for ordinary Zoho mailbox sending. This is the main reason DKIM is non-negotiable on Zoho: it is your reliable path to DMARC pass.
• SPF alignment depends on the return-path. Zoho's outbound servers are authorised by include:zohomail.com, so SPF itself passes. Whether it aligns depends on what domain Zoho uses in the envelope sender. For standard mailbox mail from your verified domain, the return-path uses your domain and SPF aligns too. But some Zoho flows, particularly newsletters via Zoho Campaigns or certain forwarded and automated mail, can use a Zoho-controlled bounce domain (for example a bounce subdomain on Zoho's infrastructure). When that happens, SPF passes for Zoho's domain but does not align with yourcompany.com, so SPF contributes nothing to DMARC.

The practical takeaway: do not rely on SPF alignment alone with Zoho. As long as DKIM is enabled, verified and signing with d=yourcompany.com, DMARC will pass on the DKIM side even when SPF alignment slips. Domains that skip DKIM and lean only on SPF are the ones that see DMARC failures the moment mail is forwarded or sent through a Zoho sub-service. Forwarding breaks SPF entirely, which is covered at /blog/forwarding-and-dmarc; DKIM survives most forwarding hops, which is another reason it is your anchor.

If you use Zoho Campaigns or Zoho's transactional sending for the same domain, authenticate those separately. Each Zoho product has its own DKIM setup in its own console, and you should enable signing there too so that marketing and transactional mail also align on yourcompany.com. SPF should already cover them via include:one.zoho.com.

Step 5: Publish a DMARC record at p=none and start monitoring

Now publish DMARC. Unlike SPF and DKIM, Zoho does not publish your DMARC record for you; you create it manually in DNS. DMARC tells receivers what to do when a message claiming to be from your domain fails authentication, and crucially it asks them to send you reports about every source using your domain.

Start in monitoring mode so you observe without affecting delivery:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=none; rua=mailto:reports@yourcompany.com; fo=1"

What each tag does:

• v=DMARC1 declares the record version. It must come first.
• p=none is monitor-only. Receivers take no action against failing mail, but they still send reports. This is your safe starting point.
• rua=mailto:... is where aggregate (RUA) reports are delivered. These daily XML summaries are how you discover every system sending as your domain, including ones you forgot about.
• fo=1 requests failure reports whenever any mechanism fails, giving you more diagnostic detail.

p=none provides no protection: a spoofer can still impersonate you, and many tools will show the domain as unprotected. It is a measurement phase, not a destination. The danger of treating p=none as "done" is covered at /blog/dmarc-policy-none-quarantine-reject. The point of this phase is to collect a few weeks of reports so you can confirm that all of your legitimate mail, your Zoho mailboxes, any newsletters, your CRM, your help desk, is authenticating and aligning before you turn enforcement on.

Generate a correct record with our DMARC generator, publish it, then verify it with the DMARC checker. Every tag, including subdomain policy and alignment modes, is explained in /docs/understanding-your-dmarc-record.

Step 6: Read your reports and fix every misaligned source

Aggregate reports arrive as raw XML, one file per reporting receiver per day, and they are tedious to read by hand. Each report lists the sending IPs seen using your domain and whether SPF and DKIM passed and aligned for each. What you are looking for:

• Your Zoho mailbox traffic should show DKIM pass and aligned, and usually SPF pass and aligned as well.
• Any source showing fail on both SPF and DKIM is either a legitimate sender you have not authenticated yet, or someone spoofing you.

Common Zoho-related findings:

• Zoho mail passing DKIM but not SPF alignment. Expected on some flows. Harmless, because DKIM alignment carries DMARC. No action needed if DKIM is solid.
• A newsletter or CRM sending unaligned. That third party needs its own DKIM set up on your domain, and its include added to SPF. Fix these before you enforce, or that mail will be quarantined or rejected.
• An unknown IP failing everything. This is exactly what DMARC exists to expose. It might be an old forgotten service, or it might be abuse. Identify it before enforcing.

Pull the report XML into our DMARC report analyzer to turn it into plain English, or let hosted analytics ingest it continuously. The walkthrough at /docs/aggregate-report-analysis explains how to interpret each row. Do not advance your policy until every legitimate source is passing and aligned.

Step 7: Ramp to quarantine, then reject

Once your reports show clean authentication across all legitimate senders, tighten the policy in two steps. First, move to quarantine, optionally sampling a fraction of mail with pct so you can watch the effect on a slice before applying it to everything:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourcompany.com; fo=1"

pct=25 applies the quarantine action to roughly a quarter of failing mail; the rest is treated as p=none. Raise it to 100 once you are confident, then move to full enforcement:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=reject; rua=mailto:reports@yourcompany.com; fo=1; adkim=s; aspf=s"

At p=reject, receivers refuse any mail failing DMARC outright. This is the policy Gmail, Yahoo and Microsoft reward, and the one that actually stops impersonation of your domain. The adkim=s and aspf=s tags switch alignment to strict, requiring an exact domain match rather than an organisational one. Add these only after confirming in reports that your Zoho DKIM signs with your exact domain (it does for standard mailbox mail). If you run mail on subdomains, leave alignment relaxed or set a separate subdomain policy with sp=.

Keep watching reports for a while after each change. The staged approach, with the checks at each gate, is laid out end to end in /docs/the-enforcement-journey, and the requirements the big mailbox providers impose are summarised at /requirements and /blog/sender-requirements-2024-2025.

A clean Zoho checklist

Putting it together, a fully authenticated Zoho Mail domain has:

1. Verified domain and Zoho MX records published and active.
2. One SPF record: v=spf1 include:zohomail.com -all, or include:one.zoho.com if you use several Zoho products, with any non-Zoho senders merged in and the total under ten lookups.
3. DKIM generated in the Zoho Admin Console, the selector TXT record published (zoho._domainkey or your chosen selector), and DKIM verified and enabled in Zoho so mail is actually signed.
4. Every other service that sends as your domain (Zoho Campaigns, CRM, help desk, third-party tools) authenticated and aligned in its own right.
5. A DMARC record, starting at p=none with rua reporting, advancing through p=quarantine to p=reject only after reports prove every legitimate source aligns.

Why DKIM is your anchor on Zoho, and what we automate

The thread running through all of this is that DKIM alignment is what makes DMARC pass reliably on Zoho. SPF is necessary and you should publish it correctly, but because Zoho's return-path can diverge from your From domain on some flows, and because forwarding breaks SPF anyway, DKIM is the mechanism you can depend on. Enable it, verify it, keep it signing, and your domain has a solid path to enforcement.

The work that remains is mostly vigilance: SPF includes change as providers update their infrastructure, DKIM keys should be rotated periodically, a new marketing tool can start sending unaligned mail without warning, and a single fat-fingered DNS edit can quietly break the whole chain. That is the part that does not end at p=reject.

DMARC Engine handles the moving parts for you. We host your DMARC, SPF and DKIM records through a one-time delegation (see /docs/delegating-your-dns), keep your SPF flattened and under the lookup limit as Zoho and your other providers change IPs, ingest and translate every aggregate report so you do not read XML, and take the domain from p=none to p=reject in safe stages without dropping legitimate mail. After enforcement, we keep monitoring and email you the moment a record breaks, a policy weakens or a new failing source appears, as described in /monitor and /docs/monitoring-and-change-alerts.

If you would rather check your current state first, run your domain through the DMARC checker, SPF checker and DKIM checker. When you are ready to reach enforcement without babysitting DNS, start with DMARC Engine and let the platform carry your Zoho-hosted domain the rest of the way.