Zoho Mail: SPF, DKIM and DMARC alignment

example.com.  TXT  "v=spf1 include:zohomail.com ~all"

zmail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq…"

DMARC alignment: the favourable case

DMARC only validates a message if SPF or DKIM passes and aligns with the From domain. Zoho Mail sits here in the favourable case, like classic mail hosting.

On the DKIM side, the signature carries the domain itself — alignment is direct. On the SPF side, the envelope of outgoing messages is also on the organisation's domain, since Zoho hosts that domain's mail: SPF therefore aligns naturally, with no envelope subdomain to declare as with some ESPs. Two mechanisms pass aligned, and that redundancy protects: if a forward breaks SPF along the way, DKIM survives; if a gateway rewrites the body and invalidates the signature, SPF holds. A softfail qualifier (~all) stays prudent while the setup is being confirmed, before any move to a stricter -all. The worked examples, from the simplest to the strictest show how to set the _dmarc instruction once SPF and DKIM are in place — first at p=none while observing, then tightening.

The data-centre trap

Almost all Zoho configurations that fail come down to a region mismatch. The account is hosted on a given data centre — chosen at sign-up, sometimes without much attention — but the SPF include, the DKIM console and the MX records must all match that same region. A domain whose account lives on the European centre but whose SPF points to include:zohomail.com will see its messages fail SPF in a baffling way: the documentation seems to have been followed, and yet authentication does not pass.

The diagnostic reflex is to check, in the console, the actual hosting region, then align every record on it. Zoho's MX records follow the same regional logic as the SPF include; a correct MX but an include from another region is a classic case, precisely because the two are configured at different moments. Migrating an account from one data centre to another — an operation Zoho offers — also requires revisiting the SPF include in passing, a point the switch does not always flag. It is a check of a few minutes that saves hours of trial and error.

Domain aliases and subdomains

Zoho Mail allows several domains and aliases to be attached to one organisation. Each domain that sends mail is a distinct authentication perimeter: it needs its own SPF record and its own DKIM key, published in ITS zone. An alias that reuses a main domain's infrastructure without publishing its own records will send under an unauthenticated identity — and DMARC will fail for that particular alias, even if the main domain is flawless.

The rule holds for subdomains too. A subdomain that sends — billing, support, notifications — does inherit the parent's DMARC policy through the DMARCbis tree walk, but not its SPF record or its DKIM key: those still have to be published where the mail actually leaves from. Confusing inheritance of policy with inheritance of configuration is a frequent mistake that leaves an active subdomain without aligned authentication, under an inherited policy that will have it rejected.

Common configuration mistakes

Several traps recur in the body of reports the free DMARC analyzer processes daily.

Publishing the DKIM key without enabling it. The TXT is in place, but the signature is never applied because enabling was not ticked in the console. Symptom: SPF passes, DKIM is absent from reports.

Stacking two SPF records. Adding a second v=spf1 record instead of merging the includes into one triggers a permerror that invalidates SPF entirely — not just the addition.

Copying an include from the wrong region. The Zoho case par excellence, described above.

Tightening the policy too early. Moving to p=reject before confirming, reports in hand, that all legitimate traffic aligns — human mail as well as application notifications — means risking the rejection of one's own messages.

The final proof: RUA reports

The only proof that a configuration holds is not the Zoho console, but what recipients report. Once a _dmarc record is published with a rua= address, aggregate reports arrive within a few days and detail, source by source, what aligns and what fails. Reading the reports the receivers send back confirms that Zoho traffic is correctly attributed to the domain: DKIM aligned, SPF aligned, and no Zoho source failing both mechanisms.

A simple cadence is enough: a first read a few days after publishing the _dmarc record, once several recipients have reported, then a weekly glance while the policy stays at p=none. Zoho traffic appears under a stable set of addresses specific to the account's region: an aligned baseline is quick to recognise, and any new or unaligned Zoho source stands out immediately — usually the sign of a service sending from another region or a DKIM selector never enabled.

That verification, held over several days, is what licenses tightening the policy without risk. As long as reports show legitimate traffic that is not aligned — a forgotten service, a misconfigured region — the move to p=reject stays premature. Once alignment is confirmed across every flow, the shift to a strict policy is made calmly. The online analyzer reconstructs this state from the published records and the reports received, and places the domain on the path that leads to p=reject.