Portée et conditions préalables
Zoho Assist prend en charge l'envoi de domaines d'entreprise via son flux de vérification de domaine de messagerie. Ce guide couvre ce produit DKIM configuration, pas toutes les applications Zoho . L'administrateur Assist doit avoir accès à la configuration de la messagerie et à un propriétaire DNS capable de publier la clé publique générée. La vérification d'un domaine dans un autre service Zoho ne doit pas être considérée comme un achèvement ici.
Configurer l'itinéraire documenté
- Étape 1. Ouvrez Paramètres, Général, Configuration de la messagerie dans Zoho Assist. Sélectionnez Vérification du domaine et Ajouter et vérifier un nouveau domaine.
- Étape 2. Entrez la partie domaine de l'adresse de l'expéditeur de l'entreprise prévue et choisissez Générer la clé. Enregistrez le nom d'hôte et la valeur renvoyés dans la demande de modification, en vérifiant que le domaine est celui réellement utilisé pour l'envoi.
- Étape 3. Dans le gestionnaire DNS faisant autorité, créez un Enregistrement TXT avec ce nom d'hôte et la valeur complète fournie. L'exemple de nom d'hôte de la documentation est une illustration, pas un sélecteur vous devez réutiliser lorsque le compte en donne un différent.
- Étape 4. Vérifiez comment le fournisseur DNS traite un nom complet. S'il ajoute automatiquement le nom de la zone, entrez uniquement l'étiquette relative nécessaire pour obtenir le nom d'hôte final exact.
- Étape 5. Revenez à l'écran de vérification du domaine et choisissez Vérifier maintenant. Assist indique que le temps de vérification dépend du TTL de l'enregistrement et peut prendre quelques heures. Un statut positif confirme que le service a trouvé son enregistrement ; il ne s'agit pas d'une garantie de boîte de réception du destinataire.
- Étape 6. Déclenchez la notification Assist appropriée à partir de l'adresse prévue de l'entreprise vers une boîte aux lettres de test externe approuvée. Collectez le message après tout traitement sortant et inspectez le domaine de signature DKIM .
- Étape 7. Enregistrez le type de notification, l'identité du locataire et de l'expéditeur. Répétez l’opération pour un domaine différent plutôt que de supposer que tous les techniciens et modèles partagent la même identité authentifiée.
Risques spécifiques au produit
Si l'entrée TXT est présente mais qu'Assist ne peut pas la vérifier, comparez le nom complet et la clé complète aux valeurs générées actuellement. Plusieurs enregistrements TXT sur le même sélecteur DKIM , la duplication accidentelle de domaine et les modifications apportées sur un hôte DNS inactif méritent tous notre attention. La procédure Assist citée spécifie DKIM , pas un Assist universel SPF inclure ou une coutume Return-Path recette. N'ajoutez pas de valeurs DNS spéculatives pour donner l'impression qu'une liste de contrôle est complète. L'authentification peut améliorer la confiance mais ne peut pas garantir le placement dans la boîte de réception.
Prouver l'itinéraire à la réception
Utilisez une boîte aux lettres externe approuvée et enregistrez le message brut complet avec son horodatage et son identifiant de message. Aucun test de locataire en direct n'est revendiqué dans ce guide. Ce qui suit est une feuille de travail d'acceptation à remplir pendant la mise en œuvre, et non un enregistrement des résultats observés.
- Champ de preuve : visible depuis ; Ce qu'il faut enregistrer : adresse et domaine réels ; Question d'acceptation : s'agit-il de l'identité de l'expéditeur prévu ?
- Champ de preuve : Enveloppe ; Ce qu'il faut enregistrer : Return-Path et domaine SPF signalé par le récepteur ; Question d'acceptation : quel domaine SPF a-t-il réellement authentifié ?
- Champ de preuve : SPF ; Ce qu'il faut enregistrer : résultat du récepteur de confiance et identité évaluée ; Question d'acceptation : est-ce que cela a réussi et cette identité s'aligne-t-elle ?
- Champ de preuve : DKIM ; Ce qu'il faut enregistrer : chaque d= domaine, s= résultat du sélecteur et du récepteur ; Question d'acceptation : est-ce qu'au moins une signature de passage s'aligne ?
- Champ de preuve : DMARC; Ce qu'il faut enregistrer : résultat du récepteur et politique applicable ; Question d'acceptation : existe-t-il un chemin de dépassement aligné ?
- Champ de preuve : itinéraire ; Ce qu'il faut enregistrer : produit, compte et type de message ; Question d'acceptation : le test a-t-il utilisé le chemin de production ?
DMARC a besoin d’au moins un chemin SPF ou DKIM aligné et passant. Une signature transmise provenant d'un domaine de service non lié ne suffit pas. Strict alignement nécessite une égalité de domaine exacte ; l’alignement détendu utilise la relation organisation-domaine applicable. Vérifiez les paramètres d'alignement réels du domaine avant de déclarer le succès. Un sous-domaine n'est pas une correspondance stricte automatique. SPF utilise l'identité SMTP , pas le nom d'affichage ou Reply-To. Consultez le glossaire d'alignement lors de l'enregistrement de la décision.
Utiliser Authentication-Results du système de réception auquel vous faites confiance, et non un en-tête fourni par un expéditeur arbitraire. Capturez toutes les signatures plutôt que de vous arrêter au premier échec. Pour le courrier transféré, comparez un test direct avec une copie transférée : le transfert peut modifier l'évaluation SPF ou altérer le contenu signé. Ne diagnostiquez pas ces effets en ajoutant l'adresse du transitaire à l'autorisation de votre fournisseur.
Diagnostiquer les pannes sans élargir l’accès
Comparez d'abord DNS faisant autorité avec les noms d'enregistrement configurés exacts, puis vérifiez la visibilité récursive et la validation du service. Un nom erroné, une clé tronquée ou contradictoire CNAME n'est pas corrigé en attendant les caches. Conservez une seule stratégie SPF chez un propriétaire et vérifiez la limite de dix termes de recherche DNS pour les inclusions et les redirections évaluées avant de fusionner un autre expéditeur. Les sélecteurs DKIM appartiennent à des configurations de signature individuelles ; n'écrasez pas l'enregistrement d'une autre application pour forcer un résultat de validation.
Si l'authentification réussit mais que la livraison est mauvaise, inspectez séparément la réponse, la réputation, le contenu et les autorisations d'envoi du destinataire. Le pass DMARC ne promet pas d’acceptation ou de placement dans la boîte de réception. Si aucun des deux chemins ne s’aligne, arrêtez l’expansion et corrigez la configuration réelle de l’expéditeur. N'affaiblissez pas la politique DMARC de l'ensemble du domaine pour masquer une seule défaillance de produit.
Remise et récupération
Enregistrez la différence DNS approuvée, les résultats de la recherche publique, l'état du service et la feuille de calcul des messages reçus expurgés avec un propriétaire nommé. Gardez les informations d’identification et les clés privées hors des tickets. En cas d'échec, suspendez la tâche d'envoi concernée ou utilisez un itinéraire précédemment testé sous le contrôle du propriétaire du service. Restaurer uniquement les enregistrements modifiés appartenant à cette intégration ; conserver les clés publiques nécessaires aux messages en vol. Retestez après une restauration, une rotation de clé, une migration de domaine ou un changement de relais sortant. Fermez la modification uniquement lorsque le propriétaire du produit et l'administrateur de messagerie peuvent expliquer la chaîne d'identité observée.
Confirmer la limite du fournisseur
La source publique n'établit pas de sélecteur universel, de calendrier de chevauchement de rotation, de droit à l'adresse de l'expéditeur ou de recette d'enveloppe personnalisée. Conservez ces questions avec Assist Support, le cas échéant ; ne les déduisez pas d'un autre produit Zoho . Son langage de placement dans la boîte de réception est une simplification excessive : une signature valide ne remplace pas les décisions de filtrage du destinataire.
Travailler sur un cas de diagnostic fictif
Cas écrit fictif uniquement : ZA-01 suppose que shop.example est vérifié dans une autre application Zoho , mais Assist n'a pas vérifié sa clé générée pour les notifications de support@shop.example . Aucune signature Assist reçue ni aucun résultat d'enveloppe n'est connu. Le propriétaire d'Assist doit terminer le flux de travail de domaine de ce produit et collecter une notification contrôlée ; le statut vert de l'autre application ne peut pas fermer la ligne des preuves d'assistance. Aucun locataire, DNS , commande de serveur ou message n'a été utilisé pour ce cas.
Séparez un message qui passe de la préparation à l'application
RFC 9989 La section 7.4 nécessite DKIM valide pour une publication de domaine p=reject et met en garde contre l'interopérabilité du courrier indirect. Un seul résultat SPF aligné ne justifie pas en soi le déploiement d’une politique de rejet. Examinez tous les itinéraires légitimes et la propriété des politiques séparément de la configuration de ce fournisseur.