Définir le parcours CRM et la limite administrative
Le guide d'authentification des e-mails de Zoho CRM nécessite un profil administratif. Il décrit la vérification du domaine et les informations requises DKIM, avec SPF recommandé. Le chemin documenté est Configuration > Canaux > E-mail > Délivrabilité des e-mails > Authentification des e-mails. Ajoutez un domaine, vérifiez le code envoyé par e-mail, puis utilisez Validate Records pour obtenir les valeurs DNS et validez après publication. Authentification des e-mails Zoho CRM
Traitez cela comme le flux de travail du produit, et non comme une preuve d'une organisation existante. Enregistrez le compte CRM, le service régional, le domaine d'envoi et les catégories de messages en cours d'examen. La correspondance individuelle d'une équipe commerciale, une opération de courrier de masse et un expéditeur organisationnel ne doivent pas être regroupées en un seul itinéraire non examiné. L'inventaire proposé doit montrer quelle équipe est propriétaire de chaque utilisation et quelles preuves établiront son identité d'expéditeur réelle.
L’exigence plus large de mise en œuvre du catalogue reste ouverte. Aucun compte n'a été consulté, aucun code de vérification demandé et aucun domaine client inspecté pour ce manuscrit. L'examen doit toujours établir l'applicabilité actuelle à l'édition et à la configuration de l'organisation.
Obtenir les enregistrements du compte sélectionné
Le guide DNS répertorie les valeurs SPF régionales, notamment one.zoho.com pour les États-Unis et les variantes distinctes de l'UE, IN, AU, CN et JP. Ses instructions utilisent les valeurs de configuration SPF / DKIM générées et Enregistrements TXT. Les politiques SPF existantes sont modifiées plutôt que complétées par des politiques concurrentes ; le nom d'hôte et la valeur DKIM affichés appartiennent au compte. Paramètres DNS du CRM
Utilisez la région comme champ de demande de modification explicite. Un administrateur qui se souvient d'un mécanisme d'un autre service Zoho ne doit pas considérer cette mémoire comme la source de vérité pour cette route CRM. Comparez les instructions actuelles du compte avec la documentation conservée et faites une pause lorsqu'elles diffèrent. La résolution proposée est une clarification du fournisseur, et non un mélange improvisé d’inclusions régionales.
Conservez le nom exact du propriétaire et la valeur complète, ainsi que le compte et la date demandeurs. Ne réutilisez pas un échantillon sélecteur ou modifier une clé publique pour la faire ressembler à un enregistrement existant. Une valeur générée est une entrée de configuration dont la propriété et l'applicabilité nécessitent encore un examen.
Examinez SPF comme une politique complète
SPF évalue l'identité SMTP spécifiée par le protocole ; il ne recherche pas simplement le domaine visible dans l'adresse d'expéditeur d'un vendeur. Une inclusion proposée doit donc être associée à l’itinéraire d’envoi réel et au propriétaire de la politique concerné. Si d'autres applications utilisent déjà le domaine, conservez leur autorisation légitime lors de l'examen d'une modification.
Plusieurs sélectionnés Enregistrements SPF produire une erreur plutôt qu’une union utile de listes d’expéditeurs. La combinaison de politiques n'est pas non plus une opération de collage mécanique : conservez l'ordre des mécanismes prévu, le comportement de terminaison et les sources autorisées, et examinez les limites des termes dépendants du DNS. Ces limites concernent l'évaluation et non le décompte de chaque paquet réseau émis par un résolveur.
Une politique de syntaxe valide ne prouve pas qu'un message observé a utilisé un chemin autorisé. L’ensemble de preuves proposé doit distinguer une révision de politique d’un résultat de message et doit identifier les éléments de preuve manquants dans l’enveloppe. Cela évite d'interpréter un nouveau statut CRM comme un audit complet de tous les autres systèmes utilisant le domaine. RFC 7208 , section 2.4; RFC 7208 , section 3.2; RFC 7208 , section 4.6.4
Préserver la différence entre la publication DNS et la vérification d'identité
Le champ de nom de propriétaire d'un éditeur DNS n'est pas la représentation filaire finale. Déterminez si l’interface ajoute le nom de zone et comparez le nom de clé complet prévu avec l’enregistrement résultant. Dans la notation de fichier maître DNS , un @ autonome désigne l'origine actuelle ; cela n'en fait pas un caractère générique couvrant chaque sous-domaine. Les interfaces des fournisseurs peuvent utiliser leurs propres conventions.
Le stockage de clés DKIM utilise les enregistrements TXT à l'emplacement du sélecteur et du domaine de signature approprié. Le sélecteur de signature et la valeur d= identifient ensemble la recherche pertinente. Une clé publique d'apparence correcte sur un sélecteur non lié ne valide pas la signature en cours d'examen. Conservez les données clés complètes et distinguez plusieurs chaînes de caractères dans un enregistrement TXT des enregistrements distincts.
Ne demandez pas de clé de signature privée pour un examen DNS de routine. La configuration DNS publique et un extrait réduit des messages reçus devraient suffire à identifier la limite qui nécessite une enquête. RFC 1035 , section 5.1; RFC 1035 , section 3.3.14; RFC 6376 , section 3.5; RFC 6376 , section 3.6.2.2
Évaluer l'identité reçue plutôt qu'une étiquette de statut
CRM documente également la reconnaissance des domaines authentifiés via un autre service Zoho , avec des prérequis et une fenêtre de mise à jour périodique. Considérez ce statut comme une preuve de configuration du produit, et non comme une affirmation universelle selon laquelle chaque produit Zoho ou itinéraire de message se comporte de manière identique. Remarque sur l'authentification interservices
L'acceptation finale proposée consiste à examiner un message du représentant autorisé de chaque itinéraire de matériaux. Enregistrez son domaine d'auteur, son domaine de signature DKIM , ses résultats de sélecteur et de récepteur de confiance. Comparez l'identité de passage avec le domaine de l'auteur sous le DMARC alignement mode. Gardez cette évaluation séparée d'une étiquette indiquant qu'une politique DMARC existe.
Si le message observé ne correspond pas à l'inventaire, étudiez d'abord la sélection de l'itinéraire et les horodatages des preuves. N'affaiblissez pas la politique d'une organisation simplement pour éliminer un avertissement du tableau de bord. Un échantillon aligné valide est utile mais limité : il n'établit pas le placement dans la boîte de réception, la qualité du consentement, l'engagement commercial ou la sécurité de la demande commerciale du message. RFC 9989 , section 4.4
Feuille de travail d'acceptation pour un transfert d'opérations de vente
Utilisez cette feuille de travail originale proposée pour rendre visibles les limites du compte et de l'itinéraire. Chaque ligne nécessite un propriétaire et une référence de preuve plutôt qu'une coche non prise en charge.
- Portée : compte CRM, édition, région, domaines d'expéditeur et catégories de messages distinctes.
- Autorité : administrateur de l'application, propriétaire DNS et approbateur des communications pour toute modification visible de l'expéditeur.
- Point de contrôle du domaine : preuve de la vérification du domaine du compte, sans conserver son code à usage unique.
- Plan DNS : noms de propriétaires, types et valeurs émis, comparaison des enregistrements existants et référence de modification approuvée.
- Examen SPF : la politique complète concernée, les expéditeurs autorisés préservés et l'évaluation de la limite d'évaluation.
- Acceptation du message : itinéraire, horodatage, domaine de l'auteur, identité de signature et résultats d'authentification fiables.
- Version : réviseur, propriétaire de restauration et questions non résolues en matière de production ou d'applicabilité.
Cette feuille de calcul n'a pas été exécutée. Un domaine passant un point de contrôle de configuration n'est pas autorisé à marquer chaque ligne comme terminée.
Diagnostic fictif : le raccourci régional
Une organisation commerciale fictive ouvre un nouveau compte CRM dans une région différente de celle de son ancien déploiement. L'administrateur commence avec un mécanisme SPF mémorisé et une ancienne capture d'écran du sélecteur. Un réviseur remarque qu'aucun des deux artefacts n'est lié aux paramètres générés par le nouveau compte, la modification est donc suspendue avant la publication.
La correction proposée consiste à obtenir les valeurs du compte courant, à cartographier la politique pertinente et à préserver les expéditeurs non liés. L'organisation planifie ensuite une acceptation séparée pour son expéditeur organisationnel principal et ses autres itinéraires CRM importants. Rien dans ce scénario ne prouve que l'ancien enregistrement était malveillant ou que le fournisseur a échoué ; cela montre pourquoi la configuration copiée constitue une preuve faible. L'exemple est fictif, sans requêtes DNS , envois de messages ou modifications de compte effectuées.