Doc Delivrabilité email

Votre serveur dédié envoie des emails pour différentes raisons :

  • vos applications peuvent envoyer des emails
  • les tâches planifiées (Crontab) peuvent envoyer des emails en cas d’erreur
  • nos scripts d’infogérance (sauvegardes, détection de problème, proposition de mises à jour etc.) envoient des emails.

Configuration de vos applications

Vous pouvez choisir deux possibilités pour envoyer vos emails :

  • envoi en local
  • utilisation d’un service externe

Envoi en local

Vous pouvez configurer vos applicatifs pour envoyer vos emails ainsi :

  1. Utiliser le binaire /usr/sbin/sendmail
  2. Utiliser le serveur SMTP 127.0.0.1 sur le port TCP/25 (sans authentification/chiffrement)

Nous conseillons d’utiliser la 2e solution car vous pourrez positionner des paramètres beaucoup plus fin, notamment le Return-Path qui vous permet de recevoir sur une adresse personnalisés les erreurs « user unknown » etc.

Par exemple si vous utiliser du PHP, nous vous conseillons d’utiliser la bibliothèque PHPMailer.

Service externe

Vous pouvez choisir d’utiliser un service externe pour envoyer vos emails. Attention, si cela n’utilise pas le port 25, vous devez nous demander d’ouvrir le port (en général TCP/465 ou TCP/587).

Pré-requis

Voici un check-up pour s’assurer d’avoir une bonne délivrabilité :

https://wiki.evolix.org/HowtoPostfix#d%C3%A9livrabilit%C3%A9

Si vous passez par un prestataire externe, une majorité des points seront OK (mais pas tous, vous devez notamment gérer au moins SPF et DMARC).

Si vous faites l’envoi en local

  • la partie reverse DNS en IPv4 et IPv6 est de notre ressort, cela devrait être bien configuré sur votre serveur, sinon ouvrez nous un ticket
  • pour la partie SPF : si votre serveur est hébergé chez nous vous devez ajouter include:spf.protection.evolix.net dans l’enregistrement TXT du domaine concerné, sinon vous devez ajouter les IPv4 et IPv6 de votre serveur
  • pour la partie DMARC : mettez au minimum l’enresgitrement DNS _dmarc IN TXT "v=DMARC1; p=none pour le domaine concerné
  • pour la partie DKIM : ouvrez-nous un ticket en précisant le ou les domaines concernés afin que l’on vous fournisse la clé à mettre dans vos zones DNS
  • en cas d’envoi massif : demandez-nous de configurer un envoi ralenti vers certains fournisseurs

Note : si l’on gère vos zones DNS, on s’occupera bien sûr d’ajouter les renregistrements DNS adéquats.

Pour plus d’informations à propos de SPF/DKIM/DMARC, lire notre blog https://blog.evolix.com/configurez-spf-dkim-dmarc-pour-lenvoi-de-vos-emails/

Abus sur vos formulaires web

Si votre applicatif met à disposition à un formulaire web, vous devez éviter les abus sur les formulaires web.

Vous devez mettre en place un CAPTCHA qui s’assure de façon plus ou moins poussée que c’est bien un humain qui remplit votre formulaire. Au passage, il est conseillé de ne pas uniquement envoyer le résultat par email mais de le stocker (au moins temporairement) en local en parallèle.

Ce formulaire peut envoyer une notification vers des adresses email prédéfinis, mais vous devez éviter autant que possible d’envoyer des emails qui ont été remplis par l’utilisateur car cela peut provoquer des erreurs chez certains fournisseurs (« user unknown », rate-limiting, etc.) et votre serveur risque d’être blacklisté.

Que pouvez-vous envoyer ?

Une adresse email est une donnée à caractère personnel, vous veillerez à être en règle avec le règlement RGPD.

Au delà du RGPD, il y a un ensemble de règles informelles :

  • vous devez recueillir le consentement des utilisateurs au moins en opt-in et nous vous conseillons fortement de le faire en double opt-in
  • vous devez garder une trace de ce consentement (nous pourrions vous le demander pour des raisons techniques lors d’une résolution de problème)
  • nous vous conseillons de respecter au maximum la Nétiquette
  • vous devez faire une utilisation raisonnable de l’envoi des emails pour éviter que les utilisateurs considère vos envois comme du spam et le signale à son fournisseur de messagerie qui pourrait blacklister votre serveur.

Traitement des emails de retour

L’une des principales causes des problèmes de délivrabilité est l’envoi d’email répété d’emails à des adresses incorrectes (« user unknown » ou NPAI). Il est donc impératif que vous traitiez très réactivement les erreurs de vous recevez.

Tout d’abord, vous devez bien préciser dans votre code applicatif une adresse de « Return-Path » (ou expéditeur d’enveloppe). Cette adresse va recevoir toutes les erreurs d’envoi, notamment les erreurs « user unknown ».

Quand vous recevez une erreur du type « user unknown », vous devez réactivement empêcher de nouvels envois sur cette adresse email incorrecte.

Vous devez aussi réagir rapidement si un fournisseur vous indique que vous être en blacklist.

Si vous envoyez pas mal d’emails, ce traitement doit être fait automatiquement.

En cas de problème

Avant toutes choses, sachez que l’on surveille la file d’attente de votre serveur dédié. Si un grand nombre d’emails s’accumulent dedans, nous serons alertés et c’est nous qui vous contacterons en premier.

Comment nous reporter un problème

En cas de problème, merci de nous ouvrir un ticket en nous donnant le message d’erreur complet que vous avez obtenu. Si vous n’avez pas de message d’erreur, vous devez nous donner les adresses email expéditrice et destinatrice, ainsi que l’heure d’envoi.

Blacklists publiques

L’adresse IP de votre serveur peut être mis dans une blacklist (liste noire) publique. Vous pouvez vérifier si elle est listée sur https://multirbl.valli.org/ qui rassemble des centaines de backlist plus ou moins fiables.

Si votre adresse IP est listée dans une blacklist fiable, il faut comprendre pourquoi et corriger le problème. N’hésitez pas à nous reporter le problème au plus tôt. Pour information nous surveillons un certain nombre de blacklists de notre côté, mais pas toutes.

Gros fournisseurs de messagerie

L’envoi d’emails vers les gros fournisseurs de messagerie est souvent la source de problèmes les plus compliqués.

Évidemment pour envoyer vers les gros fournisseurs il est indispensable d’avoir appliqué toutes les bonnes pratiques notamment SPF, DKIM et DMARC qui sont quasiment obligatoires.

Voici quelques informations supplémentaires basées sur notre expérience qui peuvent être utiles :

  • FREE : il y a un système strict de rate-limiting en cas d’erreur, voir https://postmaster.free.fr/
  • ORANGE : en cas de problème, voir avec le service ABUSE
  • Hotmail/Outlook/Microsoft/Office365 : si vous n’envoyez pas assez d’emails par jour, votre IP est blacklistée et vous devez les contacter pour les débloquer. En cas de problème, faire un ticket support depuis sender.office.com et ce formulaire. Si vous envoyez plus de 100 emails par jour vers Hotmail/Outlook vous pouvez aussi suivre via SNDS ou vous inscrire au programme JERP. Plus d’infos sur Outlook.com Postmaster
  • GMAIL : depuis 20 ans, nous n’avons jamais eu de réponse de leur part en aucun cas, nous considérons donc qu’il est impossible de les contacter. Plus d’infos sur Gmail Help où vous pouvez vous inscrire à leur FBL
  • Yahoo : ils font du pseudo-greylisting et il semble conseillé d’essayer de ré-envoyer toutes les 4h pendant 48h. Plus de détails sur Yahoo Sender Hub où vous pouvez trouver leur Best practices de délivrabilité et où vous pouvez vous inscrire à leur FBL

Note : Orange / LaPoste / SFR utilisent des outils d’antispam en commun, vous pouvez donc être blacklisté vers les 3 fournisseurs en même temps !

Pour plus d’infos, nous contacter.

Maintenance

Nous recevons directement certaines alertes pour votre serveur, par exemple des alertes de spamtrap ou des alertes ou informations sur notre contact d’Abuse.

Dans ce cas nous vous contacterons pour que vous en preniez connaissance et corriger le problème si besoin. À noter qu’il n’est pas forcément nécessaire que vous deviez faire une correction, cela peut parfois être une fausse alerte ou un point de vigilance.