Question
Comment m'assurer que mon système de messagerie fonctionne bien avec Zendesk ?
Réponse
Zendesk s'efforce de maintenir votre boîte de réception à l'abri du spam, mais vous pouvez prendre certaines mesures pour sécuriser les canaux que vous utilisez pour interagir avec les clients. Cet article explique comment accroître le niveau de confiance de votre serveur de messagerie.
Cet article contient les sections suivantes :
- Enregistrement PTR pour les serveurs SMTP envoyant des e-mails à Zendesk
- Nom d'hôte de salutation HELO et EHLO
- Enregistrements SPF
- DMARC et DKIM
- Envoi d'e-mails à l'aide de scripts et de formulaires Web
- E-mails auxquels Zendesk ne fait pas confiance
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 de pointeur (PTR). Les enregistrements PTR fournissent une confiance 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 doit être résolue en mail.domain.com si un utilisateur de domain.com envoie un e-mail à Support.
Idéalement, un enregistrement PTR doit appartenir au même domaine qui envoie les e-mails à Support. 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 à ne pas utiliser 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
Nom d'hôte de salutation HELO et EHLO
Le nom HELO est utilisé par les serveurs SMTP pour se saluer. L'enregistrement HELO pouvant être résolu conformément à laRFC 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 salutations HELO considérées comme de faible 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 du serveur SMTP.
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”
DMARC et DKIM
Pour réduire le nombre 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 alignement SPF, DKIM et DMARC. Pour en savoir plus, consultez l’article : Authentification des e-mails entrants (SPF, DKIM, DMARC).
Envoi d'e-mails à l'aide de scripts et de formulaires Web
L'envoi d'e-mails à l'assistance à l'aide de formulaires Web ou de scripts automatisés n'est pas recommandé ni pris en charge actuellement. Les clients qui veulent toujours envoyer ce type d'e-mails doivent suivre les règles décrites ci-dessous.
- Tous les envois de formulaires Web doivent exiger une authentification ou utiliser CAPTCHA, ou les deux. Nous ne pouvons pas empêcher les attaques de spam que vous autorisez et encouragez à la fois.
- Quand vous envoyez des e-mails à l'assistance à l'aide de formulaires Web, d'applications Web ou de 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 inversée).
- L'assistance 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.
- Transférez n'importe quel e-mail d'un formulaire Web par le biais d'une adresse d'assistance externe à des fins de redondance des données et pour réduire les risques de suspension.
- Si vous envoyez un e-mail à une adresse d'assistance Zendesk native (sous-domainesupport@ .zendesk.com), votre formulaire doit pouvoir gérer les erreurs réseau passagères et/ou
4xx
réponses pour la résilience. - Ne codez pas en dur un relais MX vers nos enregistrements MX. Chaque relais doit effectuer une recherche MX.
- N'utilisez pas la fonctionnalité Marquer comme spampour les envois à partir de votre formulaire Web. Cela aura un impact négatif sur la réputation d'envoi de votre formulaire.
- L'assistance client Zendesk ne prend pas en charge les fonctionnalités de votre formulaire Web.
E-mails auxquels Zendesk ne fait pas confiance
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 autorisant soit publié dans la zone DNS du propriétaire du domaine.
- E-mails avec une adresse d'expéditeur falsifiée, une signature DKIM non valide ou un échec de la vérification SPF.*
- Les e-mails qui utilisent des noms de domaine non valides, inexistants ou impossibles à résoudre dans les en-têtes d'expéditeur et de destinataire de l'e-mail.
Support n'accorde qu'un faible niveau de confiance aux e-mails envoyés via un serveur SMTP avec un enregistrement PTR manquant ou une salutation HELO non valide.
*Zendesk essaie de détecter les e-mails transférés si vous transférez les e-mails de votre domaine vers un sous-domaine d'assistance Zendesk, par exemple assistance@votredomaine.com >> assistance@sous-domaine.zendesk.com. Si Zendesk détecte le transfert d'e-mails, Zendesk utilise d'autres approches pour authentifier le serveur SMTP expéditeur. Cependant, configurez le serveur SMTP de transfert pour conserver la signature DKIM et ne pas altérer le corps de l'e-mail d'origine ni les en-têtes sensibles.
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 Commentaires
Vous devez vous connecter pour laisser un commentaire.