Utilisez ce guide pour vous assurer que votre système de messagerie est optimisé pour une intégration fluide avec Zendesk. En suivant les meilleures pratiques décrites dans cet article, vous pouvez accroître 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 recommandations de configuration et les meilleures pratiques suivantes :

Recommandation 1 : Configurer un enregistrement PTR pour les serveurs SMTP qui envoient des e-mails à Zendesk

Vérifiez que toutes les adresses IP que vous utilisez pour envoyer des e-mails à Assistance ont un enregistrement PTR. Les enregistrements PTR fournissent une assurance 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 être résolue par mail.domaine.com si quelqu’un de domaine.com envoie un e-mail à Assistance.

Idéalement, un enregistrement PTR devrait appartenir au domaine qui envoie les e-mails à assistance Il ne doit pas contenir de numéros d’adresse IP ou 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 : Configurer le nom d’hôte de la salutation HELO et EHLO

Le nom HELO est utilisé par les serveurs SMTP pour se saluer. L’enregistrement HELO étant résolvable selon la RFC 5321 (§2.3.5), doit appartenir au domaine de l’expéditeur de l’e-mail et correspondre à un enregistrement MX. Assistance attend des serveurs SMTP qui envoient des e-mails à Assistance qu'ils aient un nom d'hôte HELO résolvable.

Exemple d’enregistrement correct pour domain.com :

  • HELO mail.domain.com

Exemples de salutations HELO considérées comme ayant une confiance faible :

  • HELO mail.otherdomain.com
  • HELO localhost
  • HELO 1.2.3.4
  • HELO invalid.tld
  • HELO not.existing.domain.com
    Pour en savoir plus, consultez Liste des codes retour des serveurs SMTP de Wikipedia.

Recommandation 3 : Enregistrements SPF

Les domaines qui envoient des e-mails à Assistance doivent avoir un enregistrement SPF valide qui autorise les adresses IP à envoyer des e-mails pour le compte du domaine.

Vous trouverez ci-dessous deux exemples d’enregistrement SPF correct pour 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 pour le compte 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 : SPF, DKIM, DMARC et ARC

Pour réduire le volume d’e-mails frauduleux et de spam que vous recevez, vous pouvez ajouter une couche de sécurité supplémentaire à vos e-mails entrants en activant l’authentification avec l’alignement SPF, DKIM, DMARC et ARC. Pour en savoir plus, consultez Authentification des e-mails entrants (SPF, DKIM, DMARC et ARC).

Recommandation 5 : Ajout d’en-têtes ARC

Pour les comptes qui transfèrent le trafic à Zendesk, nous vous conseillons d’ajouter des en-têtes ARC afin de pouvoir incorporer votre évaluation de l’authentification du trafic quand il est arrivé sur vos serveurs de transfert.

Meilleures pratiques pour l’envoi d’e-mails à l’aide de scripts et de formulaires Web

L'envoi d'e-mails à Assistance via des formulaires Web ou des scripts automatisés n'est pas recommandé et n'est actuellement pas pris en charge. Les clients qui veulent encore envoyer ce type d’e-mails doivent suivre les règles décrites ci-dessous.

  • Tous les envois de formulaires Web doivent nécessiter une authentification ou utiliser CAPTCHA, ou les deux. Zendesk ne peut pas empêcher les attaques de spam que vous autorisez et encouragez.
  • Lorsque vous envoyez des e-mails à Assistance en utilisant des formulaires Web, des applications Web ou des scripts d ' automatisme, les e-mails doivent être formatés correctement, conformément à la RFC 5322.
  • Les messages doivent contenir des en-têtes Subject:, From:, To: et Reply-To: correctement formatés.
  • L’envoi de l’adresse IP doit avoir un enregistrement PTR (résolution DNS inversée).
  • Assistance vous encourage à ajouter des enregistrements SPF valides, à signer ces e-mails avec la clé DKIM publiée sur la zone DNS du domaine d'envoi et à faire publier une politique DMARC spécifiant la façon dont les e-mails doivent être traités.
  • La salutation HELO doit avoir un nom DNS résolvable valide
  • Transférer tout e-mail provenant d’un formulaire Web par le biais d’un e-mail du service d’assistance externe, à des fins de redondance des données et pour réduire la probabilité de suspensions ou de baisse du trafic
  • Si vous envoyez à une adresse Zendesk Support native (Support@votre_sousdomaine.zendesk.com) alors votre formulaire devrait pouvoir gérer les erreurs réseau transitoires et, ou les réponses 4xx pour la résilience
  • Ne codez pas en dur un relais MX vers l’un de nos enregistrements MX. Chaque relais doit effectuer une recherche MX
  • N’utilisez pas la fonctionnalité Marquer comme spam pour les envois à partir de votre formulaire Web. Cela aura un impact négatif sur la réputation d’envoi de votre formulaire
  • Zendesk Customer Support ne fournit pas Support pour les fonctionnalités de votre formulaire Web

Meilleures pratiques pour l’envoi d’e-mails fiables

Zendesk ne fait pas confiance à :

  • Les e-mails qui usurpent l’identité de l’expéditeur de l’e-mail sans qu’un enregistrement SPF d’autorisation soit publié dans la zone DNS du propriétaire du domaine

  • Les e-mails avec une adresse d’expéditeur frauduleuse, une signature DKIM non valide ou non alignée ou un échec de la vérification SPF

    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 Zendesk Support, par exemple, Support@votredomaine.com >> Support@votre_sousdomaine.zendesk.com. Si Zendesk détecte le transfert d’e-mails, Zendesk adopte d’autres approches pour authentifier le serveur SMTP envoyeur. Cependant, essayez de configurer le serveur de transfert pour préserver la signature DKIM et ne pas altérer le corps de l’e-mail d’origine et les en-têtes sensibles, car cela peut provoquer un échec. Essayez aussi d’utiliser les en-têtes ARC dans la mesure du possible.
  • Les e-mails qui utilisent des noms de domaine non valides, inexistants ou non résolvables dans leurs en-têtes d’expéditeur et de destinataire sont susceptibles d’être suspendus ou rejetés.

Assistance exerce un faible niveau de confiance envers les 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.

Réalisé par Zendesk