Utilisez ce guide pour optimiser votre système de messagerie 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 lorsque vous utilisez Zendesk.

Cet article inclut les meilleures pratiques et conseils de configuration suivants :

  • Recommandation 1 : Configurer un enregistrement PTR pour les serveurs SMTP qui envoient 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 à l’aide de scripts et de formulaires Web
  • Meilleures pratiques pour l’envoi d’e-mails de confiance

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 à Support ont un enregistrement Pointer (PTR). Les enregistrements PTR fournissent une garantie 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 se traduire par mail.domaine.com si quelqu’un de domain.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 ou de mots-clés indiquant qu’une adresse IP appartient à un FAI.

Exemple de l’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’un enregistrement manquant :

  • host 1.2.3.4
  • Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)

Exemple de l’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. L’enregistrement HELO pouvant être résolu selon la RFC 5321 ( §2.3.5), doit appartenir au domaine de l’expéditeur de l’e-mail et correspondre à un enregistrement MX. Support suppose que les serveurs SMTP qui envoient des e-mails à Support ont un nom d’hôte HELO pouvant être résolu.

Exemple de l’enregistrement correct pour domain.com :

  • HELO mail.domain.com

Exemple de salutations HELO qui sont considérées comme un niveau de 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 cet article de Wikipedia : Liste des codes de retour du 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 pour le compte du domaine.

Vous trouverez ci-dessous deux exemples de l'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, ajoutez une couche de sécurité supplémentaire à vos e-mails entrants en activant l’authentification de l’expéditeur avec SPF, DKIM, DMARC et ARC. Pour en savoir plus, consultez l’article : Authentification des e-mails entrants

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

Pour les comptes transférant du trafic vers Zendesk, nous vous conseillons d’ajouter des en-têtes ARC afin que nous puissions incorporer votre évaluation d’authentification du trafic quand il arrive 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 à Support à l’aide de formulaires Web ou de scripts automatisés est déconseillé et n’est pas pris en charge actuellement. Les clients qui veulent quand même envoyer ce type d’e-mails doivent suivre les règles décrites ci-dessous.

  • Tous les envois de formulaires Web devraient exiger ou utiliser un CAPTCHA, voire les deux. Zendesk ne peut pas empêcher les attaques de spam que vous autorisez et encouragez.
  • 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 à la RFC 5322.
  • Les messages doivent contenir des en-têtes Subject:, From:, To:et Reply-To: 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 dont les e-mails doivent être traités. 
  • La salutation HELO doit avoir un nom DNS pouvant être résolu valide.
  • Transférez tous les e-mails d’un formulaire Web par le biais d’une e-mail du service d’assistance externe, afin d’assurer la redondance des données et pour réduire le risque de suspension ou d’interruption du trafic.
  • Si vous envoyez des e-mails à une e-mail du service d’assistance Zendesk native (assistance@sous-domaine.zendesk.com), votre formulaire doit être capable de traiter les erreurs réseau temporaires et/ou 4xx des réponses pour plus de résilience.
  • Ne codez pas en dur un relais MX pour l’un de nos enregistrements MX. Chaque relais doit effectuer une recherche MX.
  • N’utilisez pas la fonctionnalité Marquer comme spam pour les soumissions à partir de votre formulaire Web. Cela aura un impact négatif sur la réputation d’envoi de votre formulaire.
  • Support client Zendesk ne fournit pas assistance pour les fonctionnalités de votre formulaire Web.

Meilleures pratiques pour l’envoi d’e-mails de confiance

Zendesk ne fait pas confiance :

  • E-mails se faisant passer pour 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.
  • E-mails avec une adresse d’expéditeur frauduleuse, une signature DKIM non valide ou non alignée ou une vérification SPF en échec
    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 assistance Zendesk, par exemple, assistance@votredomaine.com >> assistance@sous-domaine.zendesk.com. Si Zendesk détecte un transfert d’e-mails, Zendesk adopte d’autres approches pour authentifier le serveur SMTP d’envoi. Cependant, essayez de configurer le serveur de transfert de façon à conserver la signature DKIM et à ne pas altérer le corps de l’e-mail d’origine ni les en-têtes sensibles, car cela peut provoquer des échecs. Essayez aussi d’utiliser les en-têtes ARC chaque fois que cela est possible. 
  • Les e-mails qui utilisent des noms de domaine non valides, inexistants ou non résolus dans les en-têtes d’expéditeur et de destinataire de l’e-mail risquent d’être suspendus ou rejetés. 

Support applique un niveau de confiance faible aux e-mails 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