Utilisez ce guide pour vous assurer que votre système de messagerie est optimisé pour une intégration transparente avec Zendesk. En suivant les meilleures pratiques décrites dans cet article, vous pouvez améliorer le niveau de confiance de votre serveur de messagerie et minimiser le risque de problèmes lors de l’utilisation de Zendesk.
Cet article inclut les meilleures pratiques et les conseils de configuration suivants :
- Recommandation 1 : Configuration d’un enregistrement PTR pour les serveurs SMTP envoyant des e-mails à Zendesk
- Recommandation 2 : Configurez le nom d’hôte de salutation HELO et EHLO
- Recommandation 3 : Enregistrements SPF
- Recommandation 4 : DMARC et DKIM
- Meilleures pratiques pour l’envoi d’e-mails en utilisant les scripts et les formulaires Web
- Meilleures pratiques pour l’envoi d’e-mails dignes de confiance
Recommandation 1 : Configuration d’un enregistrement PTR pour les serveurs SMTP envoyant des e-mails à Zendesk
Vérifiez que toutes les adresses IP que vous utilisez pour envoyer des e-mails à Support ont un enregistrement pointeur (PTR). Les enregistrements PTR fournissent une preuve supplémentaire que l’adresse IP donnée a une connexion avec le propriétaire du domaine. Par exemple, l’adresse IP 1.2.3.4 devrait donner mail.domaine.com si un utilisateur de domaine.com envoie un e-mail à Support.
Idéalement, un enregistrement PTR doit appartenir au domaine qui envoie les e-mails à Support. Elle ne doit pas contenir de numéros d’adresse IP ni de mots-clés indiquant qu’une adresse IP appartient à un FAI Résidentiel.
Exemple d’enregistrement correct pour domain.com :
host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. domain name pointer mail.domain.com
Exemple d’enregistrement manquant :
host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)
Exemple d’enregistrement qui ne doit pas être utilisé pour envoyer un e-mail :
host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. domain name pointer 4-3-2-1-cable-subscribers.isp.com
Recommandation 2 : Configurez le nom d’hôte de salutation HELO et EHLO
Le nom HELO est utilisé par les serveurs SMTP pour se saluer mutuellement. Pour que cet enregistrement HELO soit résolu selon RFC 5321 (?2.3.5), il doit appartenir au domaine de l’expéditeur de l’e-mail et correspondre à un enregistrement MX. Support s’attend à ce que les serveurs SMTP qui envoient des e-mails à Support aient un nom d’hôte HELO pouvant être résolu.
Exemple d’enregistrement correct pour domain.com :
HELO mail.domain.com
Exemple de messages de salutation HELO considérés comme n’ayant pas de niveau de confiance :
HELO mail.otherdomain.com
HELO localhost
HELO 1.2.3.4
HELO invalid.tld
-
HELO not.existing.domain.com
Pour en savoir plus, consultez cet article de Wikipedia : Liste des codes de retour de serveur SMTP
Recommandation 3 : Enregistrements SPF
Les domaines qui envoient des e-mails à Support doivent avoir un enregistrement SPF valide qui autorise les adresses IP à envoyer des e-mails de la part du domaine.
Vous trouverez ci-dessous deux exemples d'enregistrement SPF correct dans la situation suivante :
domain.com
SMTP servers with address 1.2.3.4
MX record mail.domain.com pointing on 1.2.3.4.
Les deux exemples permettraient à 1.2.3.4 d'envoyer des e-mails de la part de domain.com.
domain.com. 3600 IN TXT "v=spf1 mx:domain.com ~all”
domain.com. 3600 IN TXT "v=spf1 ip4:1.2.3.4 ~all”
Recommandation 4 : DMARC et DKIM
Pour réduire le volume d’e-mails frauduleux et de spam que vous recevez, ajoutez une couche de sécurité supplémentaire à vos e-mails entrants en activant l’authentification de l’expéditeur avec l’alignement SPF, DKIM et DMARC. Pour en savoir plus, consultez l’article : Authentification des e-mails entrants (SPF, DKIM, DMARC).
Meilleures pratiques pour l’envoi d’e-mails en utilisant les scripts et les formulaires Web
L’envoi d’e-mails à Support en utilisant des formulaires Web ou des scripts automatisés est déconseillé et n’est pas pris en charge actuellement. Les clients qui souhaitent toujours envoyer ces types d’e-mails doivent suivre les règles présentées ci-dessous.
- Tous les formulaires Web d’envoi doivent nécessiter une authentification ou utiliser CAPTCHA, voire les deux. Zendesk ne peut pas empêcher les attaques de spam que vous autorisez et encouragez à la fois.
- Quand vous envoyez des e-mails à Support en utilisant des formulaires Web, des applications Web ou des scripts d’automatisation, les e-mails doivent être formatés correctement, conformément à RFC 5322.
- Les messages doivent contenir des en-têtes Sujet :, De :, À :et Répondre à : correctement formatés.
- L’adresse IP d’envoi doit avoir un enregistrement PTR (résolution DNS inverse).
- Support vous encourage à ajouter des enregistrements SPF valides, à signer ces e-mails avec la clé DKIM publiée dans la zone DNS du domaine d’envoi et à publier une politique DMARC spécifiant la façon de traiter les e-mails.
- La salutation HELO doit avoir un nom DNS résolue valide.
- Transférer tous les e-mails d’un formulaire Web par le biais d’une adresse d’assistance externe, afin d’assurer la redondance des données et de réduire les risques de suspension.
- Si vous envoyez un message à une adresse d’assistance Zendesk native (support@ sous-domaine.zendesk.com), votre formulaire doit être capable de traiter les erreurs réseau momentanées et/ou
4xx
réponses pour plus de résilience. - Ne codez pas en code un relais MX pour aucun de vos enregistrements MX. Chaque relais doit effectuer une recherche MX.
- N’utilisez pas la fonctionnalité Marquer comme spam pour les envois provenant de votre formulaire Web. Cela aura un impact négatif sur la réputation d’envoi de votre formulaire.
- L’assistance client Zendesk ne fournit pas d’assistance pour la fonctionnalité de votre formulaire Web.
Meilleures pratiques pour l’envoi d’e-mails dignes de confiance
Zendesk ne fait pas confiance :
- Les e-mails qui « imitent » l’expéditeur de l’e-mail sans avoir d’enregistrement SPF d’autorisation publié dans la zone DNS du propriétaire du domaine.
- Les e-mails avec une adresse d’expéditeur usurpée, une signature DKIM non valide ou une vérification SPF ratée
Remarque : Zendesk essaie de détecter les e-mails transférés si vous transférez des e-mails de votre domaine à un sous-domaine d’assistance Zendesk, par exemple support@votredomaine.com >> support@sous-domaine.zendesk.com. Si Zendesk détecte un transfert d’e-mails, Zendesk essaie d’authentifier le serveur SMTP d’envoi. Cependant, configurez le serveur SMTP de transfert pour conserver la signature DKIM et ne pas falsifier le corps du message d’origine et les en-têtes sensibles.
- Les e-mails qui utilisent des noms de domaine non valides, inexistants ou non résolus dans les en-têtes de l’expéditeur et du destinataire de l’e-mail
Support applique un niveau de confiance faible aux e-mails qui ont été envoyés via un serveur SMTP avec un enregistrement PTR manquant ou une salutation HELO non valide.
Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.
Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.
0 commentaire