SPF, DKIM et DMARC pour Zoho CRM.
Zoho CRM authentifie votre domaine d'envoi depuis un seul endroit — Setup → Channels → Email → Email Deliverability → Email Authentication — où vous ajoutez votre domaine, le vérifiez à l'aide d'un code envoyé par e-mail, puis Zoho vous remet un enregistrement DKIM (obligatoire) ainsi qu'une valeur SPF (recommandée) à publier dans le DNS. Le détail qui déroute tout le monde : Zoho CRM envoie vos messages via l'infrastructure transactionnelle propre à Zoho (transmail.net), avec un envelope-from/Return-Path appartenant à Zoho, si bien que SPF ne s'aligne jamais sur votre domaine. C'est ce qui fait de DKIM — un enregistrement TXT doté d'un sélecteur généré automatiquement et d'une clé publique — le mécanisme qui porte réellement votre validation DMARC, et c'est précisément pourquoi Zoho marque DKIM comme obligatoire et SPF comme seulement recommandé. DMARC est un troisième enregistrement, distinct, que vous ajoutez vous-même. Validez DKIM et publiez DMARC : votre courrier CRM s'authentifie alors comme provenant de votre propre domaine, au lieu d'afficher une mention « via zoho ».
Pourquoi authentifier Zoho CRM ?
L'authentification de votre domaine Zoho CRM détermine si vos e-mails commerciaux et marketing atteignent la boîte de réception, tout simplement. Depuis février 2024, Gmail et Yahoo exigent de chaque expéditeur en masse (environ 5 000 messages par jour ou plus) qu'il passe SPF, DKIM et DMARC avec alignement, et Microsoft a commencé à imposer la même chose sur les envois à fort volume vers Outlook.com/Hotmail/Live en 2025. Zoho CRM est directement dans la ligne de mire car c'est un expéditeur en masse par conception — séquences, e-mails de masse, notifications de workflow. Tant que vous n'authentifiez pas, Zoho signe votre courrier sortant avec son propre domaine : les destinataires voient donc qu'il ne provient pas cryptographiquement de vous, votre adresse From ne s'aligne pas, et DMARC ne peut pas passer. Il existe une particularité propre à Zoho qui rend DKIM non négociable : Zoho CRM utilise un domaine appartenant à Zoho (sur son infrastructure d'envoi transmail.net) comme envelope-from SMTP, si bien que SPF est toujours évalué par rapport à Zoho — jamais par rapport à votre domaine From — et ne s'aligne donc jamais. Les propres conseils de dépannage de Zoho l'expliquent clairement : si DKIM est configuré, vous passerez DMARC même si l'alignement SPF échoue ; sautez DKIM et vous n'avez aucune authentification alignée du tout. Configurer DKIM (et une politique DMARC) est ce qui supprime la mention « via », permet à DMARC de passer sur l'alignement DKIM, et bâtit une réputation d'envoi sous votre propre domaine.
La réalité SPF pour Zoho CRM
Zoho répertorie Zoho CRM comme un fournisseur « include » : sur la page Email Deliverability, il vous remet une valeur SPF Zoho à fusionner dans l'unique enregistrement SPF TXT de votre domaine racine — la ligne du centre de données américain est v=spf1 include:zoho.com ~all. Publiez-la, mais comprenez précisément ce qu'elle fait et ne fait pas pour le courrier CRM. Zoho CRM envoie via l'infrastructure transactionnelle de Zoho (transmail.net) en utilisant un envelope-from/Return-Path appartenant à Zoho ; la vérification SPF du courrier envoyé par le CRM est donc évaluée par rapport au domaine de Zoho et au propre enregistrement SPF de Zoho — le SPF de votre domaine n'est même pas consulté, et le résultat ne peut jamais s'aligner sur votre domaine From. (C'est aussi pourquoi certaines configurations Zoho affichent include:transmail.net ; l'ajouter à VOTRE SPF ne change rien pour le courrier CRM, car l'enveloppe est un domaine Zoho, pas le vôtre — et c'est pourquoi EasyDMARC et d'autres disent qu'il n'est « pas nécessaire » de l'ajouter.) DMARC ne compte SPF que lorsqu'il s'aligne ; pour le courrier CRM, SPF n'apporte donc rien — précisément la raison pour laquelle Zoho rend DKIM obligatoire et SPF simplement « recommandé ». Alors pourquoi publier include:zoho.com du tout ? Parce que le même domaine héberge souvent aussi des boîtes aux lettres Zoho Mail (et parfois Zoho Campaigns), et pour ce courrier-là l'enveloppe EST votre domaine — là, SPF est évalué par rapport à votre enregistrement et S'ALIGNE bien, si bien que l'include est le SPF correct et requis. Si vos boîtes aux lettres résident plutôt sur Google Workspace ou Microsoft 365, fusionnez ces include-là plutôt que celui de Zoho. Deux points de vigilance. D'abord, le centre de données : include:zoho.com correspond aux États-Unis ; l'UE utilise include:zoho.eu, l'Inde include:zoho.in, l'Australie include:zoho.com.au, la Chine include:zoho.com.cn, le Japon include:zoho.jp — faites correspondre à la région indiquée dans l'URL de votre compte Zoho. Ensuite, include:zoho.com n'est PAS plat : il imbrique include:spf.zoho.com, include:zcsend.net, include:spf.zohomail.com et include:popspf.zohomail.com, si bien qu'il consomme environ 5 de vos 10 recherches DNS SPF (RFC 7208). Si vous n'utilisez que Zoho Mail, include:zohomail.com est bien plus léger (environ 2 recherches) ; si vous utilisez plusieurs services Zoho, include:one.zoho.com les consolide en un seul include. Conservez exactement un seul enregistrement SPF TXT sur le domaine et fusionnez l'include avec tout autre expéditeur — deux enregistrements SPF constituent en soi une PermError.
Deux façons de le configurer
Authentification de domaine DKIM (obligatoire — porte DMARC)
- Obligatoire dans Zoho CRM : un enregistrement TXT avec un sélecteur généré automatiquement + une clé publique
- Signe le courrier comme d=yourdomain.com, il S'ALIGNE donc et passe DMARC
- Le seul mécanisme aligné pour le courrier CRM — SPF ne peut pas s'aligner ici
- Validez-le sur la page Email Deliverability après publication
SPF include:zoho.com (recommandé — rôle d'appoint seulement)
- Zoho vous remet v=spf1 include:zoho.com ~all à fusionner dans votre SPF racine
- Pour le courrier CRM, le SPF de votre domaine n'est même pas évalué (Zoho possède l'enveloppe sur transmail.net), il ne peut donc pas y porter DMARC
- Reste néanmoins le SPF correct et aligné pour les boîtes aux lettres Zoho Mail sur le même domaine
- Coûte environ 5 de vos 10 recherches SPF — utilisez la variante du centre de données/plus légère si nécessaire
Étape par étape
- 1
Ouvrir Email Authentication
Connectez-vous en tant qu'administrateur et allez dans Setup → Channels → Email → Email Deliverability, puis ouvrez l'onglet Email Authentication. C'est là que Zoho génère pour vous les enregistrements DKIM (obligatoire) et SPF (recommandé) ; DMARC n'est pas ici — vous l'ajoutez vous-même chez votre hébergeur DNS.
- 2
Ajouter et vérifier votre domaine d'envoi
Cliquez sur + Add Domain et saisissez une adresse e-mail From sur le domaine depuis lequel vous envoyez du courrier CRM (par ex. sales@yourdomain.com). Zoho envoie un code de vérification par e-mail à cette adresse — saisissez-le (Enter Code → Verify) pour confirmer que vous contrôlez le domaine. Une fois vérifié, Zoho affiche les enregistrements DKIM et SPF à publier.
- 3
Copier l'enregistrement DKIM
Zoho affiche un enregistrement DKIM TXT : un Host de la forme <selector>._domainkey (le sélecteur est une longue chaîne générée automatiquement, souvent une valeur numérique/horodatée comme 1522905413783) et une Value commençant par v=DKIM1; k=rsa; p=… Copiez les deux exactement. Notez aussi la valeur SPF affichée par Zoho (include:zoho.com ou la variante de votre centre de données). Laissez cette page ouverte — vous y reviendrez pour cliquer sur Validate Records.
- 4
Publier l'enregistrement DKIM TXT
Chez votre hébergeur DNS, ajoutez un enregistrement TXT avec Host = <selector>._domainkey et Value = la chaîne v=DKIM1; k=rsa; p=… fournie par Zoho. Conservez le type TXT (le DKIM de Zoho CRM est un enregistrement TXT, pas un CNAME). Si votre registrar ajoute automatiquement le domaine, saisissez seulement <selector>._domainkey, pas le FQDN complet.
- 5
Ajouter ou fusionner l'include SPF
Sur le domaine racine (host @ ou vide), publiez v=spf1 include:zoho.com ~all — ou la variante de votre centre de données (zoho.eu, zoho.in, zoho.com.au, zoho.com.cn, zoho.jp). Si un enregistrement v=spf1 existe déjà, fusionnez l'include dans cet unique enregistrement plutôt que d'ajouter un second SPF TXT. Rappelez-vous que cet include coûte environ 5 recherches sur la limite de 10 ; utilisez include:zohomail.com (environ 2 recherches) si le domaine n'utilise que Zoho Mail.
- 6
Publier l'enregistrement DMARC
Zoho ne crée pas DMARC. Ajoutez un enregistrement TXT au host _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Commencez à p=none (surveillance uniquement) afin que rien ne soit affecté pendant que vous confirmez que DKIM signe et s'aligne ; vous le durcirez plus tard.
- 7
Cliquer sur Validate Records
Une fois le DNS propagé (généralement quelques minutes, jusqu'à 24–48 heures), retournez dans Email Deliverability et cliquez sur Validate Records pour le domaine. DKIM doit apparaître comme validé — tant que ce n'est pas le cas, Zoho risque de ne pas signer votre courrier avec votre clé. Si la validation cale, revérifiez le host du sélecteur pour un doublement de domaine et confirmez que la valeur TXT n'a pas été tronquée.
- 8
Envoyer un test et lire les en-têtes
Envoyez un e-mail CRM vers un compte Gmail, ouvrez-le et choisissez ⋮ → Afficher l'original. Vous devez obtenir DKIM: PASS avec d=yourdomain.com et DMARC: PASS. SPF affichera généralement le domaine d'enveloppe de Zoho plutôt que le vôtre (non aligné) — c'est attendu pour Zoho CRM et sans conséquence, car l'alignement DKIM porte DMARC.
- 9
Utiliser des adresses From vérifiées
Assurez-vous que les adresses From depuis lesquelles vos utilisateurs et vos workflows envoient se trouvent sur le domaine authentifié et sont configurées comme adresses From vérifiées dans le CRM. Le courrier envoyé depuis une adresse gratuite (gmail.com) ou un domaine non authentifié ne sera pas signé DKIM en votre nom et ne bénéficiera pas de cette configuration.
Enregistrements à ajouter
Zoho CRM génère les valeurs exactes dans son assistant de configuration — celles-ci illustrent la forme de ce que vous ajouterez chez votre hébergeur DNS.
| Type | Hôte | Valeur |
|---|---|---|
| TXT | 1522905413783._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…(public key from Zoho's Email Deliverability page)Obligatoire. À titre indicatif — le sélecteur (le nombre avant ._domainkey) et la clé sont générés automatiquement par domaine par Zoho CRM. Copiez le Host et la Value exacts depuis Email Authentication. Il s'agit d'un enregistrement TXT, pas d'un CNAME. |
| TXT | @ | v=spf1 include:zoho.com ~allSPF racine — recommandé. Utilisez la variante de votre centre de données (zoho.eu, zoho.in, zoho.com.au, zoho.com.cn, zoho.jp). Conservez UN seul enregistrement SPF et fusionnez cet include. Coûte environ 5 recherches DNS. Remarque : pour le courrier envoyé par le CRM, le SPF de votre domaine n'est même pas évalué (Zoho possède l'enveloppe sur transmail.net) — DKIM porte DMARC ; l'include ne s'aligne que pour Zoho Mail sur le même domaine. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez vous-même — Zoho ne le crée jamais. Un seul par domaine ; commencez à p=none. Pour le courrier CRM, il passe sur l'alignement DKIM ; validez donc DKIM avant de durcir vers quarantine/reject. |
Conservez exactement un seul enregistrement SPF (v=spf1) TXT sur votre domaine racine — fusionnez-y tous vos expéditeurs. Avoir deux enregistrements SPF constitue en soi une erreur.
Le budget de 10 requêtes DNS
SPF est plafonné à une limite stricte de 10 requêtes DNS — dépassez-la et il renvoie une permerror et cesse de valider partout. Voici ce que coûte la configuration de Zoho CRM sur ce budget.
Zoho CRM utilise 5 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
DKIM est l'enregistrement qui compte le plus pour Zoho CRM, car c'est le seul mécanisme qui s'aligne sur votre domaine. Sur la page Email Deliverability → Email Authentication, Zoho génère un enregistrement DKIM pour vous : un enregistrement TXT (et non un CNAME, contrairement à Google Workspace ou Microsoft 365) dont le Host est <selector>._domainkey.yourdomain.com et dont la Value est v=DKIM1; k=rsa; p=<public key>. Le sélecteur est une longue chaîne générée automatiquement que Zoho attribue (souvent une valeur numérique/horodatée telle que 1522905413783), alors ne vous attendez pas à un nom convivial comme « zoho » — copiez ce que Zoho affiche. Publiez ce TXT chez votre hébergeur DNS exactement tel qu'il est fourni ; si votre registrar ajoute automatiquement votre domaine, saisissez uniquement le libellé <selector>._domainkey pour éviter de le doubler. Ensuite — et c'est l'étape que les gens sautent — retournez dans Zoho et cliquez sur Validate Records pour que Zoho confirme la clé et commence à signer. Zoho détient la clé privée correspondante et signe le courrier CRM sortant avec elle ; une fois validés, les messages portent donc une signature DKIM de d=yourdomain.com. Comme Zoho CRM utilise son propre envelope-from et que SPF ne peut donc pas s'aligner, cette signature DKIM est ce qui porte votre validation DMARC — Zoho documente lui-même qu'une configuration DKIM complète passera DMARC même si l'alignement SPF échoue. Deux modes de défaillance à surveiller : une clé publique de 2048 bits peut dépasser la limite de 255 caractères d'une chaîne unique dans un TXT et doit être stockée en morceaux entre guillemets fractionnés (la plupart des panneaux gèrent cela), et une clé altérée/tronquée est la raison habituelle pour laquelle un enregistrement publié refuse toujours de se valider.
DMARC
DMARC est un enregistrement de politique distinct que vous publiez vous-même — Zoho CRM ne le crée jamais. Ajoutez un enregistrement TXT à _dmarc.yourdomain.com commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance uniquement : il ne change rien à la distribution tandis que les serveurs de réception vous envoient par e-mail des rapports agrégés (rua) afin que vous puissiez confirmer que votre courrier Zoho CRM passe DKIM aligné sur votre domaine. Cela compte davantage pour Zoho que pour la plupart des expéditeurs : parce que SPF ne peut pas s'aligner (Zoho possède l'envelope-from), DMARC repose ici entièrement sur l'alignement DKIM ; ne durcissez donc pas la politique tant que vous n'avez pas vu, dans les rapports, votre courrier CRM passer sur DKIM. Surveillez le flux rua pendant une semaine ou deux, assurez-vous que chaque expéditeur légitime du domaine — Zoho CRM, Zoho Mail et tout outil tiers — s'authentifie, puis montez à p=quarantine et enfin p=reject. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine organisationnel, quel que soit le nombre d'expéditeurs que vous utilisez ; n'ajoutez jamais un second enregistrement DMARC juste pour Zoho. Notez que les règles de Google et Yahoo pour les expéditeurs en masse n'exigent que p=none comme seuil plancher, mais c'est p=reject qui empêche réellement les attaquants d'usurper votre domaine.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au seul badge « validated » de Zoho — confirmez-le sur un vrai message. Envoyez un e-mail CRM vers un compte Gmail, ouvrez-le et choisissez ⋮ → Afficher l'original. Vous devez obtenir DKIM: PASS avec signed-by / d=yourdomain.com et DMARC: PASS. Attendez-vous à ce que SPF affiche le propre domaine d'enveloppe de Zoho plutôt que le vôtre et soit signalé comme non aligné — c'est normal pour Zoho CRM et ce n'est pas un échec, car c'est l'alignement DKIM qui satisfait DMARC. Côté Zoho, la page Email Deliverability devrait répertorier le domaine comme validé. Vous pouvez contrôler ponctuellement les enregistrements bruts avec dig TXT <selector>._domainkey.yourdomain.com et dig TXT _dmarc.yourdomain.com. Passez ensuite votre domaine dans le bilan de santé du domaine de Qualisend pour confirmer que les enregistrements DKIM, SPF et DMARC se résolvent tous et que votre SPF reste sous la limite de 10 recherches (include:zoho.com à lui seul en consomme environ 5) ; et dès que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — Zoho devrait apparaître comme une source aligné DKIM et passante, même si SPF s'affiche comme non aligné.
Pièges courants
- Configuration DNS
DKIM est obligatoire, pas optionnel. Comme Zoho CRM envoie avec son propre domaine envelope-from (sur transmail.net), SPF ne s'aligne jamais sur votre domaine — DKIM signé comme d=yourdomain.com est le SEUL mécanisme qui porte votre validation DMARC. Publier SPF mais sauter DKIM vous laisse sans aucune authentification alignée.
- Casse l'authentification
Pour le courrier CRM pur, le SPF de votre domaine est sans objet. La vérification SPF s'exécute contre le domaine d'enveloppe de Zoho et le SPF de Zoho, pas le vôtre — ajouter include:zoho.com (ou include:transmail.net) ne fait donc rien pour le courrier CRM. Cela n'a d'utilité que si le même domaine envoie aussi via Zoho Mail ou Zoho Campaigns, où l'enveloppe EST votre domaine et où SPF s'aligne.
- Configuration DNS
include:zoho.com n'est PAS une seule recherche DNS — il imbrique include:spf.zoho.com, include:zcsend.net, include:spf.zohomail.com et include:popspf.zohomail.com, si bien qu'il consomme environ 5 de vos 10 recherches SPF. Si vous n'utilisez que Zoho Mail (pas Zoho Campaigns), include:zohomail.com est plus léger (environ 2 recherches) ; pour plusieurs services Zoho, include:one.zoho.com les consolide.
- Couverture
Votre centre de données change l'include. Les comptes américains utilisent include:zoho.com, mais l'UE utilise include:zoho.eu, l'Inde include:zoho.in, l'Australie include:zoho.com.au, la Chine include:zoho.com.cn et le Japon include:zoho.jp. Utiliser l'include de la mauvaise région n'autorisera pas les bons serveurs — faites correspondre au domaine de l'URL de votre compte Zoho.
- Configuration DNS
Le DKIM de Zoho CRM est un enregistrement TXT, pas un CNAME. Contrairement à Google Workspace et Microsoft 365 (qui utilisent des CNAME de sélecteur), vous collez la clé publique de Zoho dans un enregistrement TXT à <selector>._domainkey. L'ajouter en tant que CNAME cassera la validation.
- Configuration DNS
Doublement du champ Host : de nombreux registrars ajoutent automatiquement votre domaine, de sorte que saisir <selector>._domainkey.yourdomain.com produit <selector>._domainkey.yourdomain.com.yourdomain.com. Saisissez seulement le libellé <selector>._domainkey si le panneau ajoute le domaine pour vous.
- Configuration DNS
Publier l'enregistrement DKIM ne suffit pas — vous devez retourner sur la page Email Deliverability de Zoho et cliquer sur Validate Records. Tant que Zoho n'affiche pas le domaine comme validé, il risque de ne pas signer votre courrier avec votre clé.
- Couverture
L'adresse From doit être une adresse vérifiée sur le domaine authentifié. Le courrier envoyé depuis une adresse gratuite (gmail.com, outlook.com) ou un domaine différent ne sera pas signé DKIM en votre nom et n'en tire aucun bénéfice.
Construisez votre enregistrement SPF
Zoho CRM est présélectionné ci-dessous. Ajoutez toutes les autres plateformes par lesquelles vous envoyez, puis publiez l'enregistrement fusionné unique.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF Zoho CRM — FAQ
Lectures complémentaires
Une fois publié, confirmez que tout se résout correctement avec la vérification de l'état du domaine, puis identifiez qui envoie en votre nom grâce à l'analyseur de rapports DMARC. Parcourez toutes les sources d'envoi dans le générateur. L'authentification ne représente toutefois que la moitié de la délivrabilité — une IP ou un domaine d'envoi inscrit sur une liste vous fait toujours atterrir dans les spams, quelle que soit la propreté de votre SPF ; il vaut donc la peine de surveiller les listes noires avec la surveillance des listes noires.
Authentifié — maintenant, gardez votre liste propre
Réussir SPF, DKIM et DMARC vous mène jusqu'à la boîte de réception ; une liste propre vous y maintient. Vérifiez la vôtre — commencez gratuitement avec 100 crédits, sans carte bancaire.