Délivrabilité : Différence entre versions

De
Sauter à la navigation Sauter à la recherche
(typo)
 
(3 révisions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
 
[[Category:E-mail]]
 
[[Category:E-mail]]
<h1>Délivrabilité</h1>
 
  
 
Plus de 80% des emails envoyés sont du spam. Pour se protéger de cela, de nombreux systèmes permettent d'éliminer les mails ne respectant pas certaines règles.
 
Plus de 80% des emails envoyés sont du spam. Pour se protéger de cela, de nombreux systèmes permettent d'éliminer les mails ne respectant pas certaines règles.
  
<h2>Tester sa configuration</h2>
+
<h1>Tester sa configuration</h1>
  
 
Nous pouvons toujours vous aiguiller sur la bonne configuration de votre domaine pour une délivrabilité optimale. Néanmoins, si vous souhaitez vérifier vous-même votre configuration ou gagner du temps en apportant vos premiers diagnostics lors de la création d'un ticket support, voici quelques outils utiles.
 
Nous pouvons toujours vous aiguiller sur la bonne configuration de votre domaine pour une délivrabilité optimale. Néanmoins, si vous souhaitez vérifier vous-même votre configuration ou gagner du temps en apportant vos premiers diagnostics lors de la création d'un ticket support, voici quelques outils utiles.
  
<h3>mail-tester</h3>
+
<h2>mail-tester</h2>
  
 
Le site http://www.mail-tester.com/ vous permet de vérifier la bonne configuration d'un poste et d'un domaine.
 
Le site http://www.mail-tester.com/ vous permet de vérifier la bonne configuration d'un poste et d'un domaine.
 
Envoyez un email à l'adresse indiquée (avec un vrai titre et un vrai contenu) et vérifiez votre note.
 
Envoyez un email à l'adresse indiquée (avec un vrai titre et un vrai contenu) et vérifiez votre note.
  
<h3>mxtooolbox</h3>
+
<h2>mxtooolbox</h2>
  
 
Le site https://mxtoolbox.com/ vous permet de tester vos règles SPF, vos signatures DKIM, la connexion au serveur SMTP, de vérifier le blacklistage de votre MX, etc.
 
Le site https://mxtoolbox.com/ vous permet de tester vos règles SPF, vos signatures DKIM, la connexion au serveur SMTP, de vérifier le blacklistage de votre MX, etc.
 
Ce dernier est très utile pour diagnostiquer un élément précis sur votre domaine.
 
Ce dernier est très utile pour diagnostiquer un élément précis sur votre domaine.
  
<h2>Rejets de mails</h2>
+
<h1>Rejets de mails</h1>
  
<h3>Les types de rejets</h3>
+
<h2>Les types de rejets</h2>
  
 
En fonction de la sévérité de l'erreur, le serveur destinataire peut appliquer plusieurs actions.
 
En fonction de la sévérité de l'erreur, le serveur destinataire peut appliquer plusieurs actions.
Ligne 30 : Ligne 29 :
  
  
<h3>Causes de rejet</h3>
+
<h2>Causes de rejet</h2>
  
 
Voici les causes de rejet de mails les plus courantes :
 
Voici les causes de rejet de mails les plus courantes :
Ligne 42 : Ligne 41 :
 
* l'IP du serveur expéditeur est reconnue comme expéditeur de spams (vérifiable ici https://mxtoolbox.com/SuperTool.aspx?action=blacklist )
 
* l'IP du serveur expéditeur est reconnue comme expéditeur de spams (vérifiable ici https://mxtoolbox.com/SuperTool.aspx?action=blacklist )
  
<h3>Messages de rejet</h3>
+
<h2>Messages de rejet</h2>
  
<h4>Remote server replied: 550 5.7.0 Your server IP address [x.x.x.x] does not have a valid reverse DNS entry [x.x.x.x.rev.provider.tld]</h4>
+
<h3>Remote server replied: 550 5.7.0 Your server IP address [x.x.x.x] does not have a valid reverse DNS entry [x.x.x.x.rev.provider.tld]</h3>
See http://spamauditor.org/best-practices/check_dynamic_reverse_dns/ for more information. Protection provided by MagicSpam 2.0.18-1 http://www.magicspam.com
+
<i>See http://spamauditor.org/best-practices/check_dynamic_reverse_dns/ for more information. Protection provided by MagicSpam 2.0.18-1 http://www.magicspam.com</i>
  
Avoir un rDNS personnalisé et correctement configuré est la première règle à respecter lors de la mise en place d'un serveur email.
+
<b>Cause</b>
  
Cette erreur provient de la nature du Reverse DNS utilisé par le serveur SMTP expéditeur : Un serveur de mails ne peut pas utiliser un rDNS par défaut de la forme [IP.provider.tld]. Il faut personnaliser ce rDNS pour que ses emails soient acceptés.
+
Cette erreur provient de la nature du reverse DNS utilisé par le serveur SMTP expéditeur : Un serveur SMTP n'est pas jugé digne de confiance s'il utilise un rDNS par défaut de la forme [IP.provider.tld].
  
Si le provider réseau utilisé ne permet pas de personnaliser son rDNS, alors il faut utiliser serveur ou relai SMTP qui lui sera convenablement configuré avec un rDNS portant un nom personnalisé et relatif au service hébergé.
+
<b>Rappel</b>
  
Dans le cas contraire, alors la plupart des destinataires rejetteront les emails provenant du serveur estimant qu'il s'agit d'un botnet (ordinateur infecté) n'ayant pas été configuré et envoyant donc du spam.
+
Le rDNS (reverse DNS) est le FQN (nom de domaine ou sous-domaine) retourné lorsque l'on effectue une requête DNS sur une IP. Le FQN défini en rDNS doit pointer avec un pointage DNS de type A ou CNAME vers l'IP en question.
  
En effet, comme il s'agit de la forme par défaut des rDNS de la vaste majorité des providers, cela indique que le rDNS n'a pas été configuré par un humain pour mettre en place un serveur de mails bien préparé pour authentifier les envois au maximum.
+
<b>Explications</b>
Cela commence par le fait d'utiliser un rDNS en rapport avec le service hébergé.
 
  
Avec un rDNS par défaut, alors le risque que le mail provenant d'un tel serveur soit un botnet est proche de 100% et par conséquent, ces mails seront fréquemment rejetés et ce, même si tout est correct au niveau SPF, DKIM et autres vérifications.
+
Avoir un rDNS personnalisé et correctement configuré est la première règle à respecter lors de la mise en place d'un serveur email. Cela indique que le serveur a été configuré consciencieusement pour mettre en place un serveur de mails qui authentifie ses envois.
  
 +
Avec un rDNS par défaut, alors le risque que le mail provenant d'un tel serveur soit un botnet (ordinateur infecté) est proche de 100% (car les PC infectés envoient beaucoup plus de mails que les serveurs email réels) et par conséquent, ces mails seront fréquemment rejetés et ce, même si tout est correct au niveau SPF, DKIM et autres vérifications.
  
<h4>Recipient address rejected: User unknown in relay recipient table</h4>
 
host smtp.example.tld [133.7.133.7] said: 550 5.1.1 <recipient@example.tld>: Recipient address rejected: User unknown in relay recipient table (in reply to RCPT TO command)
 
  
Ce message signifie généralement que le destinataire n'existe pas sur le serveur de destination. Faute de frappe ? Faute de syntaxe dans le formatage de votre destinataire ? Faute de recopie orale de l'adresse ? Adresse supprimée ? Serveur destinataire mal configuré ? Dans ce cas, il convient de contacter le destinataire par un autre moyen et de vérifier la bonne orthographe de l'adresse.
+
<b>Solution</b>
  
 +
Pour configurer votre rDNS correctement, en pratique, dans 99% des cas :
 +
* Il faut choisir un sous-domaine relatif au service hébergé à faire pointer vers l'IP du serveur SMTP (exemple : mail.domain.tld pointe vers 1.2.3.4).
 +
* Puis, il faut changer au niveau du provider réseau ou fournisseur de serveur le rDNS de l'IP pour correspondre à ce sous-domaine (ex: 1.2.3.4 pointe vers mail.domain.tld).
 +
* Enfin, le HELO du serveur SMTP devra aussi être identique à ce sous-domaine/rDNS (exemple mil.domain.tld).
  
<h4>Remote-MTA: dns; smtp.mailchannels.net | 550 5.7.1 [CS] Message blocked. | [ESA] Sender Blocked</h4>
+
On obtient ainsi une boucle où l'IP du SMTP, son rDNS et le HELO correspondent tous.
  
Notre relai MailChannels a refusé de relayer votre mail.
+
Note: Si le provider réseau utilisé ne permet pas de personnaliser son rDNS, alors il faut soit changer pour un provider permettant cela, soit utiliser serveur SMTP ou un relai SMTP pour votre serveur actuel, qui lui, sera convenablement configuré avec un rDNS personnalisé.
 +
 
 +
 
 +
<h3>Recipient address rejected: User unknown in relay recipient table</h3>
 +
<i>host smtp.example.tld [133.7.133.7] said: 550 5.1.1 <recipient@example.tld>: Recipient address rejected: User unknown in relay recipient table (in reply to RCPT TO command)</i>
 +
 
 +
<b>Cause</b>
 +
 
 +
Ce message signifie généralement que le destinataire n'existe pas sur le serveur de destination.
 +
 
 +
<b>Solution</b>
 +
 
 +
Il faut vérifier les points suivants :
 +
* Faute de frappe ?
 +
* Faute de syntaxe dans le formatage de votre destinataire ?
 +
* Faute de recopie orale de l'adresse ?
 +
* Adresse supprimée ?
 +
* Serveur destinataire mal configuré ?
 +
 
 +
Généralement, il convient de contacter le destinataire par un autre moyen et de vérifier la bonne orthographe de l'adresse et la bonne configuration de son côté.
 +
 
 +
 
 +
<h3>Remote-MTA: dns; smtp.mailchannels.net | 550 5.7.1 [CS] Message blocked. | [ESA] Sender Blocked</h3>
  
 
Le message d'erreur est le suivant :  
 
Le message d'erreur est le suivant :  
Ligne 82 : Ligne 105 :
 
</pre>
 
</pre>
  
Cause: Votre mail a été détecté comme spam, ou parfois, votre adresse d'expéditeur est bloquée pour d'autres envois précédents considérés comme spam. Cela peut venir aussi bien du sujet du mail que du contenu du mail (mots clés ressemblant à du spam), parfois d'autres critères mis en place par MailChannels.
+
<b>Cause</b>
 +
Notre relai MailChannels a refusé de relayer votre mail.
 +
 
 +
Votre mail a été détecté comme spam, ou parfois, votre adresse d'expéditeur est bloquée pour d'autres envois précédents considérés comme spam. Cela peut venir aussi bien du sujet du mail que du contenu du mail (mots clés ressemblant à du spam), parfois d'autres critères mis en place par MailChannels.
 +
 
 +
<b>Explications complémentaires</b>
 +
 
 +
MailChannels est un relai de mails qui optimise votre délivrabilité en s'assurant que ses IP ne soient jamais blacklistées. Cela nécessite cependant de filtrer le spam sortant. Il peut donc arriver dans de rares cas qu'il y aie des faux positifs, c'est à dire des mails légitimes détectés comme spams.
 +
 
 +
<b>Solutions</b>
 +
 
 +
Vous pouvez tenter de modifier le titre ou le contenu de votre mail afin que celui-ci ne ressemble pas à un spam du point de vue du robot qui va traiter votre mail.
  
Solutions: Vous pouvez tenter de modifier le titre ou le contenu de votre mail afin que celui-ci ne ressemble pas à un spam du point de vue du robot qui va traiter votre mail.
 
 
Si cela est impossible ou si vous pensez qu'il faut corriger l'algorithme de détection anti spam, cliquez sur le lien fourni dans le message de rejet, pour indiquer à MailChannels qu'il s'agit d'un faux positif. La situation sera examinée par un vrai humain chez MailChannels, généralement sous 6h maximum. Si après 6h vous ne parvenez toujours pas à envoyer ce mail, contactez votre support HaiSoft qui fera le nécessaire auprès de MailChannels pour ajuster le filtre et autoriser cet envoi.
 
Si cela est impossible ou si vous pensez qu'il faut corriger l'algorithme de détection anti spam, cliquez sur le lien fourni dans le message de rejet, pour indiquer à MailChannels qu'il s'agit d'un faux positif. La situation sera examinée par un vrai humain chez MailChannels, généralement sous 6h maximum. Si après 6h vous ne parvenez toujours pas à envoyer ce mail, contactez votre support HaiSoft qui fera le nécessaire auprès de MailChannels pour ajuster le filtre et autoriser cet envoi.

Version actuelle datée du 20 mars 2020 à 09:59


Plus de 80% des emails envoyés sont du spam. Pour se protéger de cela, de nombreux systèmes permettent d'éliminer les mails ne respectant pas certaines règles.

Tester sa configuration

Nous pouvons toujours vous aiguiller sur la bonne configuration de votre domaine pour une délivrabilité optimale. Néanmoins, si vous souhaitez vérifier vous-même votre configuration ou gagner du temps en apportant vos premiers diagnostics lors de la création d'un ticket support, voici quelques outils utiles.

mail-tester

Le site http://www.mail-tester.com/ vous permet de vérifier la bonne configuration d'un poste et d'un domaine. Envoyez un email à l'adresse indiquée (avec un vrai titre et un vrai contenu) et vérifiez votre note.

mxtooolbox

Le site https://mxtoolbox.com/ vous permet de tester vos règles SPF, vos signatures DKIM, la connexion au serveur SMTP, de vérifier le blacklistage de votre MX, etc. Ce dernier est très utile pour diagnostiquer un élément précis sur votre domaine.

Rejets de mails

Les types de rejets

En fonction de la sévérité de l'erreur, le serveur destinataire peut appliquer plusieurs actions.

  • Rejet temporaire, votre mail reste dans la file (jusqu'à 48h)
  • Rejet permanent, vous recevez un mail de "bounce" vous indiquant la cause du rejet

Le mail peut également être accepté par le serveur SMTP de destination, mais être filtré comme spam.


Causes de rejet

Voici les causes de rejet de mails les plus courantes :

  • Vous n'avez pas de règle SPF, pas de DKIM sur votre domaine, le niveau de confiance attribué à vos emails est très faible car aucune vérification d'authenticité de l'expéditeur ne peut être effectuée.
  • Votre règle SPF n'est pas correctement configurée et n'autorise pas votre serveur à envoyer des emails.
  • Votre mail n'a pas été envoyé depuis le bon serveur SMTP : Seul le serveur SMTP de votre prestataire de mails est habilité à relayer les emails de votre domaine. Ce dernier doit être autorisé dans la règle SPF de votre domaine.
  • Le destinataire n'existe pas.
  • Votre signature DKIM est incorrecte.
  • Le contenu de votre mail est suspicieux (liens, texte, pièces jointes)
  • l'IP du serveur expéditeur est reconnue comme expéditeur de spams (vérifiable ici https://mxtoolbox.com/SuperTool.aspx?action=blacklist )

Messages de rejet

Remote server replied: 550 5.7.0 Your server IP address [x.x.x.x] does not have a valid reverse DNS entry [x.x.x.x.rev.provider.tld]

See http://spamauditor.org/best-practices/check_dynamic_reverse_dns/ for more information. Protection provided by MagicSpam 2.0.18-1 http://www.magicspam.com

Cause

Cette erreur provient de la nature du reverse DNS utilisé par le serveur SMTP expéditeur : Un serveur SMTP n'est pas jugé digne de confiance s'il utilise un rDNS par défaut de la forme [IP.provider.tld].

Rappel

Le rDNS (reverse DNS) est le FQN (nom de domaine ou sous-domaine) retourné lorsque l'on effectue une requête DNS sur une IP. Le FQN défini en rDNS doit pointer avec un pointage DNS de type A ou CNAME vers l'IP en question.

Explications

Avoir un rDNS personnalisé et correctement configuré est la première règle à respecter lors de la mise en place d'un serveur email. Cela indique que le serveur a été configuré consciencieusement pour mettre en place un serveur de mails qui authentifie ses envois.

Avec un rDNS par défaut, alors le risque que le mail provenant d'un tel serveur soit un botnet (ordinateur infecté) est proche de 100% (car les PC infectés envoient beaucoup plus de mails que les serveurs email réels) et par conséquent, ces mails seront fréquemment rejetés et ce, même si tout est correct au niveau SPF, DKIM et autres vérifications.


Solution

Pour configurer votre rDNS correctement, en pratique, dans 99% des cas :

  • Il faut choisir un sous-domaine relatif au service hébergé à faire pointer vers l'IP du serveur SMTP (exemple : mail.domain.tld pointe vers 1.2.3.4).
  • Puis, il faut changer au niveau du provider réseau ou fournisseur de serveur le rDNS de l'IP pour correspondre à ce sous-domaine (ex: 1.2.3.4 pointe vers mail.domain.tld).
  • Enfin, le HELO du serveur SMTP devra aussi être identique à ce sous-domaine/rDNS (exemple mil.domain.tld).

On obtient ainsi une boucle où l'IP du SMTP, son rDNS et le HELO correspondent tous.

Note: Si le provider réseau utilisé ne permet pas de personnaliser son rDNS, alors il faut soit changer pour un provider permettant cela, soit utiliser serveur SMTP ou un relai SMTP pour votre serveur actuel, qui lui, sera convenablement configuré avec un rDNS personnalisé.


Recipient address rejected: User unknown in relay recipient table

host smtp.example.tld [133.7.133.7] said: 550 5.1.1 <recipient@example.tld>: Recipient address rejected: User unknown in relay recipient table (in reply to RCPT TO command)

Cause

Ce message signifie généralement que le destinataire n'existe pas sur le serveur de destination.

Solution

Il faut vérifier les points suivants :

  • Faute de frappe ?
  • Faute de syntaxe dans le formatage de votre destinataire ?
  • Faute de recopie orale de l'adresse ?
  • Adresse supprimée ?
  • Serveur destinataire mal configuré ?

Généralement, il convient de contacter le destinataire par un autre moyen et de vérifier la bonne orthographe de l'adresse et la bonne configuration de son côté.


Remote-MTA: dns; smtp.mailchannels.net | 550 5.7.1 [CS] Message blocked. | [ESA] Sender Blocked

Le message d'erreur est le suivant :

Action: failed
Status: 5.7.1
Remote-MTA: dns; smtp.mailchannels.net
Diagnostic-Code: smtp; 550 5.7.1 [CS] Message blocked. If this is a false
positive, please report this to your hosting service provider. See
https://console.mailchannels.net/insights/bounce?auid=haisoft[...]

Cause Notre relai MailChannels a refusé de relayer votre mail.

Votre mail a été détecté comme spam, ou parfois, votre adresse d'expéditeur est bloquée pour d'autres envois précédents considérés comme spam. Cela peut venir aussi bien du sujet du mail que du contenu du mail (mots clés ressemblant à du spam), parfois d'autres critères mis en place par MailChannels.

Explications complémentaires

MailChannels est un relai de mails qui optimise votre délivrabilité en s'assurant que ses IP ne soient jamais blacklistées. Cela nécessite cependant de filtrer le spam sortant. Il peut donc arriver dans de rares cas qu'il y aie des faux positifs, c'est à dire des mails légitimes détectés comme spams.

Solutions

Vous pouvez tenter de modifier le titre ou le contenu de votre mail afin que celui-ci ne ressemble pas à un spam du point de vue du robot qui va traiter votre mail.

Si cela est impossible ou si vous pensez qu'il faut corriger l'algorithme de détection anti spam, cliquez sur le lien fourni dans le message de rejet, pour indiquer à MailChannels qu'il s'agit d'un faux positif. La situation sera examinée par un vrai humain chez MailChannels, généralement sous 6h maximum. Si après 6h vous ne parvenez toujours pas à envoyer ce mail, contactez votre support HaiSoft qui fera le nécessaire auprès de MailChannels pour ajuster le filtre et autoriser cet envoi.