Aller au contenu
DMARC
← Blog

Zoho Mail : SPF, DKIM et alignement DMARC

Par Thomas · RSSI virtuel · 05 septembre 2026

Zoho Mail occupe une place à part parmi les suites de messagerie : hébergement du courrier professionnel, calendrier, outils collaboratifs, le tout à un tarif qui séduit les petites structures comme les organisations soucieuses de leur souveraineté des données. Cette dernière préoccupation a une conséquence directe sur l'authentification, souvent sous-estimée : Zoho répartit ses clients sur plusieurs centres de données régionaux, et la configuration SPF n'est pas la même selon celui qui héberge le compte.

Par défaut, un domaine ajouté à Zoho Mail émet bien sous son propre nom — l'enveloppe et l'en-tête From portent le domaine de l'organisation — mais rien ne garantit encore que DMARC passe. Tant que l'enregistrement SPF n'autorise pas les serveurs de Zoho et que la signature DKIM n'est pas activée dans la console d'administration, les messages sortent sans authentification alignée. Un destinataire appliquant p=reject les rejette alors, quand bien même ils proviennent d'une boîte parfaitement légitime.

Ce guide détaille les trois briques qui rendent Zoho Mail compatible avec DMARC : l'enregistrement SPF et son include régional, le sélecteur DKIM généré puis vérifié dans la console, et l'alignement qui en découle. Puis la question du centre de données — la source d'erreur la plus spécifique à Zoho —, les pièges de configuration courants, et la contre-épreuve finale par les rapports RUA.

SPF : l'include qui dépend du centre de données

L'enregistrement SPF autorise les serveurs de Zoho à émettre pour le domaine. Sa forme dépend de la région d'hébergement du compte :

exemple.fr.  TXT  "v=spf1 include:zoho.eu ~all"

L'include zoho.eu vaut pour les comptes hébergés dans le centre de données européen ; un compte sur le centre américain utilise zoho.com, un compte indien zoho.in, et ainsi de suite. C'est le point le plus spécifique à la plateforme : copier un include vu dans une documentation générique, sans vérifier la région réelle du compte, produit un SPF qui authentifie mal — les serveurs qui émettent réellement ne sont pas ceux que l'include autorise, et SPF échoue de façon intermittente selon le serveur sortant retenu par Zoho.

Un domaine ne doit porter qu'un seul enregistrement SPF. Si le domaine émet aussi via un autre service — un ESP pour les campagnes, une application transactionnelle —, les include se combinent dans le même enregistrement, jamais dans deux enregistrements distincts (ce qui déclencherait un permerror). La limite de dix requêtes DNS du SPF reste à surveiller : chaque include consomme des lookups, et un enregistrement qui empile trop de services finit par dépasser le plafond.

DKIM : le sélecteur généré dans la console

Contrairement à SPF, DKIM ne se configure pas seulement dans la zone DNS : il se pilote depuis la console d'administration Zoho. Le parcours est en deux temps. D'abord, la console génère une paire de clés pour le domaine et affiche un enregistrement TXT à publier, sous un sélecteur choisi — par défaut zmail, personnalisable :

zmail._domainkey.exemple.fr.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq…"

Ensuite — et c'est l'étape que l'on oublie le plus souvent —, il faut revenir dans la console une fois le TXT propagé et activer la signature. Publier la clé ne suffit pas : tant que la case n'est pas cochée côté Zoho, les messages sortent sans signature DKIM, et le TXT reste inerte dans la zone. Cette double action — publier puis activer — est la particularité opérationnelle de Zoho en matière de DKIM.

La signature produite porte d=exemple.fr, le domaine organisationnel lui-même. L'alignement DKIM est donc acquis dès l'activation, y compris en mode strict.

Deux détails d'exploitation méritent attention. La longueur de clé, d'abord : Zoho propose des clés de 1024 ou 2048 bits ; 2048 est le choix par défaut recommandé, plusieurs opérateurs de messagerie traitant désormais 1024 comme faible. La rotation, ensuite : renouveler une clé DKIM chez Zoho consiste à générer un nouveau sélecteur, publier le TXT correspondant, l'activer, puis retirer l'ancien une fois la propagation confirmée. C'est une bascule sans coupure — à condition de ne pas supprimer l'ancien sélecteur avant que le nouveau ne soit effectif, sans quoi une fenêtre de messages part sans signature valide. La remplacement du matériel de signature suit partout ce même principe de recouvrement.

L'alignement DMARC : le scénario favorable

DMARC ne valide un message que si SPF ou DKIM passe et s'aligne avec le domaine du champ From. Zoho Mail se place ici dans le cas favorable, à l'image d'un hébergement de courrier classique.

Côté DKIM, la signature porte le domaine lui-même — l'alignement est direct. Côté SPF, l'enveloppe des messages sortants est elle aussi au domaine de l'organisation, puisque c'est Zoho qui héberge le courrier de ce domaine : SPF s'aligne donc naturellement, sans sous-domaine d'enveloppe à déclarer comme chez certains ESP. Deux mécanismes passent alignés, et cette redondance protège : si une redirection casse SPF en chemin, DKIM survit. Les enregistrements décortiqués ligne à ligne montrent comment poser la consigne _dmarc une fois SPF et DKIM en place — d'abord en p=none le temps d'observer, puis en durcissant.

Le piège du centre de données

La quasi-totalité des configurations Zoho qui échouent tiennent à un désaccord de région. Le compte est hébergé sur un centre de données donné — choisi à l'inscription, parfois sans y prêter attention — mais l'include SPF, la console DKIM et les enregistrements MX doivent tous correspondre à cette même région. Un domaine dont le compte vit sur le centre européen mais dont le SPF pointe include:zoho.com verra ses messages échouer à SPF de manière déroutante : la documentation semble suivie, et pourtant l'authentification ne passe pas.

Le réflexe de diagnostic consiste à vérifier, dans la console, la région d'hébergement effective, puis à aligner tous les enregistrements sur elle. Les MX de Zoho suivent la même logique régionale que l'include SPF ; un MX correct mais un include d'une autre région est un cas classique, précisément parce que les deux se configurent à des moments différents. La migration d'un compte d'un centre de données à un autre — opération que Zoho propose — impose d'ailleurs de reprendre l'include SPF au passage, un point que la bascule ne rappelle pas toujours. C'est une vérification de quelques minutes qui épargne des heures de tâtonnement.

Alias de domaine et sous-domaines

Zoho Mail permet de rattacher plusieurs domaines et alias à une même organisation. Chaque domaine qui émet du courrier constitue un périmètre d'authentification distinct : il lui faut son propre enregistrement SPF et sa propre clé DKIM, publiés dans SA zone. Un alias qui réutilise l'infrastructure d'un domaine principal sans publier ses propres enregistrements enverra sous une identité non authentifiée — et DMARC échouera pour cet alias précis, même si le domaine principal est irréprochable.

La règle vaut aussi pour les sous-domaines. Un sous-domaine qui émet — facturation, support, notifications — hérite bien de la politique DMARC du parent via le tree-walk de DMARCbis, mais pas de son enregistrement SPF ni de sa clé DKIM : ceux-là restent à publier là où le courrier part réellement. Confondre héritage de politique et héritage de configuration est une erreur fréquente qui laisse un sous-domaine actif sans authentification alignée, sous une politique héritée qui, elle, le fera rejeter.

Les erreurs de configuration courantes

Plusieurs pièges reviennent dans le corpus de rapports que l'analyseur DMARC gratuit traite au quotidien.

Publier la clé DKIM sans l'activer. Le TXT est en place, mais la signature n'est jamais apposée faute d'avoir coché l'activation dans la console. Symptôme : SPF passe, DKIM est absent des rapports.

Empiler deux enregistrements SPF. Ajouter un second enregistrement v=spf1 au lieu de fusionner les include dans un seul provoque un permerror qui invalide SPF entièrement — pas seulement l'ajout.

Copier un include de la mauvaise région. Le cas Zoho par excellence, décrit plus haut.

Durcir la politique trop tôt. Passer à p=reject avant d'avoir confirmé, rapports à l'appui, que tout le trafic légitime s'aligne — courrier humain comme notifications applicatives — revient à risquer le rejet de ses propres messages.

La contre-épreuve : les rapports RUA

La seule preuve qu'une configuration tient n'est pas la console Zoho, mais ce que rapportent les destinataires. Une fois l'enregistrement _dmarc publié avec une adresse rua=, les rapports agrégés arrivent sous quelques jours et détaillent, source par source, ce qui s'aligne et ce qui échoue. La lecture des rapports DMARC agrégés confirme que le trafic Zoho est bien attribué au domaine : DKIM aligné, SPF aligné, et aucune source Zoho qui échouerait sur les deux mécanismes.

Une cadence simple suffit : une première lecture quelques jours après la publication de l'enregistrement _dmarc, une fois que plusieurs destinataires ont rapporté, puis un coup d'œil hebdomadaire tant que la politique reste en p=none. Le trafic Zoho apparaît sous un ensemble d'adresses stable, propre à la région du compte : une ligne de base alignée se reconnaît vite, et toute source Zoho nouvelle ou non alignée ressort immédiatement — signe, le plus souvent, d'un service émettant depuis une autre région ou d'un sélecteur DKIM jamais activé.

C'est cette vérification, tenue sur plusieurs jours, qui autorise à durcir la politique sans risque. Tant que les rapports montrent du trafic légitime non aligné — un service oublié, une région mal configurée —, la montée vers p=reject reste prématurée. Une fois l'alignement confirmé sur l'ensemble des flux, le passage en politique stricte se fait sereinement. L'analyseur en ligne recompose cet état à partir des enregistrements publiés et des rapports reçus, et situe le domaine sur le chemin qui mène à p=reject.

Guides liés

À propos de l'auteur

Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.