Confirmez l'itinéraire du serveur de messagerie Freshservice
Utilisez ce flux de travail pour un domaine appartenant à une entreprise dont le courrier est envoyé via le serveur de messagerie Freshservice. Le guide du fournisseur révisé exclut les adresses du domaine public et les serveurs de messagerie personnalisés. Avant de commencer, enregistrez la boîte aux lettres, le domaine, le transport d'envoi, l'espace de travail, le compte et l'organisation Freshworks. Ces distinctions sont importantes lorsque plusieurs comptes utilisent le même domaine.
Inventoriez les workflows du centre de services dont les notifications doivent fonctionner, y compris les réponses destinées aux clients et pertinentes pour votre configuration. Donnez à chacun un propriétaire, un De et une destination de réponse attendue. Le test d'un seul administrateur ne constitue pas une preuve de chaque espace de travail ou boîte aux lettres. Ne combinez pas une migration de transport, un renforcement de la politique de domaine et ce changement d'authentification en un seul déploiement introuvable.
Ouvrez la bonne page de configuration
Pour un seul espace de travail, le chemin documenté est Admin > Canaux > E-mail > Paramètres de messagerie et boîtes aux lettres > Configurer SPF et DKIM authentification par courrier électronique. Avec plusieurs espaces de travail, utilisez Admin > Paramètres globaux > Paramètres du compte > Service Desk Security. Un e-mail de domaine personnalisé vérifié utilisant le serveur de messagerie Freshservice fournit automatiquement le domaine ; il n'est ni ajouté ni modifié sur cette page. Source : Freshservice, guide étape par étape pour ajouter l'authentification des e-mails SPF et DKIM .
Si le domaine est manquant, étudiez la vérification et le transport de la boîte aux lettres au lieu de saisir des enregistrements DNS spéculatifs. Confirmez le compte et l’organisation auprès du propriétaire du centre de services. Une connexion SMTP personnalisée peut ressembler à une adresse d'assistance ordinaire lors de l'utilisation d'un service de signature différent. Résolvez cette limite avant de modifier un enregistrement de domaine partagé.
Publiez les enregistrements générés sans casser un autre compte
Choisissez Commencer, copiez les quatre CNAME générés et publiez-les sur DNS faisant autorité. Revenez, développez le domaine et utilisez Vérifier ; le panneau affiche l'état par enregistrement. Le fournisseur informe également le compte et les super administrateurs une fois l'opération terminée. Source : Guide de configuration de Freshservice.
Avant d'enregistrer DNS , mappez chaque propriétaire demandé à son enregistrement actuel et au service dépendant. S'il y a un sélecteur collision, n’écrasez pas un compte fonctionnel. Le guide propose une régénération pour différentes touches de sélection, tandis que son quatrième enregistrement reste inchangé. Les instructions multi-comptes dépendent du fait que les deux comptes appartiennent ou non à la même organisation Freshworks. Utilisez cette branche documentée exacte après avoir confirmé l'adhésion à l'organisation, ou demandez à l'assistance de résoudre l'ensemble d'enregistrements prévu. N'improvisez pas plusieurs cibles à la fois CNAME propriétaire.
La régénération est une modification d'une configuration de signature, et non une actualisation inoffensive. Préservez le statut et DNS du compte précédent et coordonnez la transition. Déterminer si un enregistrement en cours de suppression appartient à la configuration nouvellement tentée ou à une configuration fonctionnelle existante. Si ce n'est pas clair, arrêtez le retrait et obtenez les conseils du fournisseur ; la suppression d'enregistrements partagés pour effacer une boîte de dialogue peut perturber d'autres centres de services.
Comparez DNS faisant autorité avec le compte
Vérifiez chaque propriétaire final et alias cible par rapport aux valeurs générées. Un éditeur qui ajoute le domaine peut nécessiter uniquement l'étiquette d'hôte relative. Si un propriétaire acquiert le suffixe de zone deux fois, corrigez l'enregistrement plutôt que d'attendre. Vérifiez d'abord les réponses faisant autorité et ensuite la mise en cache récursive ; une estimation de propagation déclarée ne garantit pas qu'un enregistrement incorrect deviendra valide.
Ne présumez pas que chaque CNAME a le même rôle de protocole simplement parce que l’assistant regroupe SPF et DKIM . Inspectez les identités des messages reçus pour établir l’authentification efficace. Évitez d’ajouter une inclusion SPF non liée ou de remplacer une stratégie racine pour corriger un échec de recherche de sélecteur. Toute mise à jour SPF distincte nécessite une politique révisée, tous les expéditeurs légitimes et ses dépendances de recherche DNS.
Vérifiez les vrais messages du centre de services
Déclenchez des messages contrôlés à partir de chaque espace de travail et domaine d'envoi prévus sans utiliser le contenu du ticket privé. Conserver le message original reçu et le destinataire de confiance Authentication-Results. Enregistrez le compte/espace de travail exact, le domaine d'origine, l'identité de l'enveloppe, DKIM d=/s= et l'itinéraire de réponse attendu. Vérifier le workflow de réponse de manière indépendante ; une signature ne dit rien sur l'endroit où la réponse d'un client est traitée.
Exemple synthétique : une notification de help@example.com a une signature valide avec d=example.com et un pass DKIM confirmé par le destinataire. Cette correspondance exacte du domaine de signature peut fournir l'alignement DMARC chemin. Un deuxième espace de travail envoyant From help@different.example n'a pas été authentifié par le premier test, même si le même collaborateur gère les deux. La propriété du domaine et la configuration du compte ne sont pas transférées par familiarité organisationnelle.
SPF authentifie l'identité de l'enveloppe ; DKIM authentifie un domaine de signature ; DMARC a besoin d'au moins un chemin aligné de passage pour être visible sous le chemin applicable. alignement mode. Une signature appartenant à un fournisseur peut être valide sans s'aligner sur votre De personnalisé. À l’inverse, l’authentification peut réussir alors qu’un message atterrit toujours dans le spam. Séparez le résultat du protocole et le résultat de la livraison.
Préserver la récupération et les portes d'achèvement explicites
Si la vérification du produit échoue, conservez les échecs exacts par enregistrement et les résultats faisant autorité. Si la signature est absente après vérification, inspectez la configuration réelle du transport et de la boîte aux lettres. En cas d’échec de signature, étudiez la recherche de sélecteur/clé et les modifications après la signature. Pour un message aligné avec un mauvais placement, étudiez l'erreur de livraison et la gestion du destinataire plutôt que d'affaiblir la politique.
Enregistrez les enregistrements antérieurs et les paramètres de la boîte aux lettres et convenez d’un itinéraire de récupération avant les modifications de production. N'utilisez pas Remove Records avec désinvolture sur une configuration de domaine partagé en direct. L'acceptation nécessite l'état correct du produit, les réponses DNS et la preuve des messages reçus pour chaque compte et flux de travail concerné. Cet article conserve l'exigence initiale de preuves en direct : aucun test de locataire, DNS ou de livraison n'a été exécuté ici. Un examen indépendant, l’approbation des PME humaines et la publication restent en attente.
Enregistrez ce qui est inconnu avant de réutiliser les sélecteurs
Le cas écrit FS-01 suppose que le compte Helpdesk-A fonctionne pour example.com , tandis que Helpdesk-B propose le même domaine. Leur relation avec l'organisation Freshworks est inconnue et les valeurs d'enregistrement proposées n'ont pas été fournies. L'administrateur ne peut pas choisir la branche de la même organisation ou d'une organisation différente de la source uniquement à partir de l'orthographe du domaine. Confirmez l'adhésion et récupérez les propriétaires exacts générés avant de planifier les modifications ; préserver la configuration active de A tout en résolvant toute collision. Le quatrième enregistrement inchangé du fournisseur est une raison pour inspecter chaque enregistrement, et non une garantie que la régénération produit un espace de noms entièrement propre. DNS , la validation du produit de B et les résultats des messages reçus sont tous inconnus dans ce cas. Aucune régénération, suppression ou message ne s'est produit.
Préserver la limite d’application
RFC 9989 La section 7.4 nécessite DKIM valide, et non SPF seul, pour la publication de domaines. p=reject, et met en garde contre l'interopérabilité du courrier indirect et des listes de diffusion. Un seul test réussi de message direct ne prouve pas que chaque voie légitime est prête à faire l’objet d’une politique plus forte. Conserver la protection approuvée existante tout en diagnostiquant l’écart réel ; tout changement de politique nécessite sa propre décision.