Authentifier les emails envoyés via Zendesk : configuration et vérification

Portée et conditions préalables

Utilisez ce guide pour l’envoi de Zendesk Support à partir d’une adresse de support externe de domaine personnalisé. Ajoutez cette adresse à Zendesk avant de configurer l’autorisation de domaine. Les adresses sur les domaines de boîtes aux lettres publiques ne peuvent pas utiliser DNS contrôlé par le client, et un itinéraire de connecteur Gmail nécessite une vérification distincte. Le transfert entrant vers une adresse d’assistance ne constitue pas une preuve que l’authentification sortante est configurée.

Configurer l'itinéraire documenté

• Étape 1. Inventoriez chaque domaine externe utilisé par les adresses de support. Enregistrer le courant SPF politique et sélecteur enregistrements avant de les modifier.
• Étape 2. Ajouter include:mail.zendesk.com à la politique SPF TXT unique du domaine tout en préservant les autres expéditeurs autorisés. L'exemple de Zendesk pour son seul service est v=spf1 include:mail.zendesk.com -all. Ses instructions actuelles nécessitent l'inclusion dans la première couche de recherche ; validez la politique résultante plutôt que de l'imbriquer de manière invisible dans une autre inclusion.
• Étape 3. Publiez deux CNAME pour chaque domaine externe : Zendesk1. _domainkey pointant vers zendesk1._domainkey.zendesk.com, et Zendesk2. _domainkey pointant vers zendesk2._domainkey.zendesk.com. Les étiquettes d'hôte sont relatives au domaine externe, sauf si votre console DNS a besoin du nom complet.
• Étape 4. Confirmez les deux CNAME les réponses sont disponibles auprès DNS faisant autorité et via les résolveurs utilisés pour la vérification. Conservez les deux dossiers ; La méthode documentée de Zendesk permet la rotation de sa clé sans remplacement manuel de la clé.
• Étape 5. Seulement une fois que DNS est prêt, ouvrez le Centre d'administration, Canaux, Discussions et e-mails, E-mail. Sous Paramètres de messagerie, activez Domaine personnalisé pour DKIM et enregistrez. Zendesk prévient que l’activation de l’option avant l’existence des CNAME peut entraîner des échecs de livraison.
• Étape 6. Générez une réponse de ticket ordinaire à partir de chaque identité de support pertinente. Enregistrez le message brut livré et inspectez les résultats d'authentification du destinataire, pas seulement l'avertissement de l'interface de l'agent.

Risques spécifiques au produit

L'erreur de commande la plus risquée consiste à activer la signature de domaine personnalisé avant de publier les deux CNAME. Si cela s'est produit, réparez les enregistrements et évaluez le courrier en file d'attente avec le propriétaire du support. Évitez un domaine à l'échelle du domaine DMARC relaxation comme solution de contournement pour un itinéraire. La validation SPF peut également échouer lorsqu'une autre inclusion dans la même stratégie n'est pas valide ; ajouter à nouveau Zendesk ne résout pas ce problème. N’autorisez pas les systèmes tiers à envoyer à partir d’un sous-domaine appartenant à Zendesk.

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 CNAME en conflit ne sont pas corrigés 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 page SPF identifie include:smtp.zendesk.com et include:support.zendesk.com comme alternatives plus anciennes. Examinez toute migration avec le propriétaire DNS plutôt que de conserver indéfiniment les autorisations en double. Le connecteur Gmail possède sa propre recommandation SPF ; ne le traitez pas silencieusement comme la même route de ticket de domaine externe. La rotation trimestrielle des clés indiquée dépend de la conservation des deux CNAME gérés.

Travailler sur un cas de diagnostic fictif

Cas écrit fictif uniquement : ZD-01 suppose qu'une réponse à un ticket utilise From help@studio.example avec une signature d=studio.example défaillante au niveau du sélecteur zendesk1, et DNS faisant autorité ne dispose pas de ce CNAME . SPF et les autres signatures sont inconnus ; l’échec complet DMARC n’est pas établi. Le propriétaire du support doit arrêter l'expansion, restaurer les prérequis DNS documentés et retester l'itinéraire du ticket plutôt que d'assouplir l'ensemble de la politique de domaine. Une avancée qui fonctionne n’est pas une preuve contraire. 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.