Questions fréquentes

echo.email analyse un e-mail par adresse et explique le résultat. Les réponses ci-dessous décrivent le fonctionnement du service et le sens de chaque vérification du rapport.

Comment fonctionne echo.email ?

La page d’accueil fournit une nouvelle adresse composée de trois mots, par exemple power.file.tube@echo.email. Un message envoyé à cette adresse arrive sur le serveur mail d’echo.email. Le serveur enregistre l’échange SMTP et transmet le message pour analyse. Quelques secondes plus tard, la page affiche un rapport sur l’authentification, le contenu, la conformité et la livraison. Rien à installer, et aucun compte n’existe.

Combien de temps l’adresse reste-t-elle valide ?

L’adresse reste active tant que la page reste ouverte. La page se signale toutes les deux secondes, et un rechargement dans les 10 minutes conserve la même adresse dans le même onglet. Une fois la page fermée depuis plus de 10 minutes, le serveur mail refuse tout nouveau courrier pour cette adresse avec une erreur permanente.

Le premier message arrivé est retenu. Les messages suivants pour la même adresse sont refusés, chaque rapport correspond donc à un seul e-mail. Les messages de plus de 10 Mo sont refusés pendant l’échange SMTP.

Combien de temps les rapports sont-ils conservés ?

Chaque rapport, le message stocké et les images téléchargées sont supprimés automatiquement 24 heures après l’arrivée du message. Pendant ces 24 heures, le lien du rapport fonctionne pour toute personne qui le possède. Ensuite, le lien ne fonctionne plus. Le rapport d’exemple est la seule exception, car il provient d’un message de test envoyé à cet effet.

Que devient le contenu du message ?

echo.email stocke le message entier, c’est-à-dire les en-têtes, le corps et les pièces jointes, avec les détails de la session SMTP comme l’adresse IP d’envoi, le nom HELO et la version TLS. Les données sont stockées dans l’UE, et le serveur mail fonctionne à Falkenstein, en Allemagne. Toute personne disposant du lien du rapport voit le message complet. Pour un test, choisissez donc un contenu que vous pouvez partager. Les newsletters contiennent souvent des liens de suivi et un lien de désabonnement propre à un destinataire. Une copie envoyée à une liste de test garde ces liens privés.

Deux adresses permettent de joindre directement l’exploitant : contact@echo.email pour les questions et les signalements, et privacy@echo.email pour les demandes liées aux données. La politique de confidentialité donne tous les détails.

Que vérifie le contrôle SPF ?

SPF liste les serveurs autorisés à envoyer du courrier avec un domaine dans le return path. echo.email prend le domaine de l’expéditeur d’enveloppe (l’adresse MAIL FROM, aussi appelée return path) et évalue l’enregistrement SPF de ce domaine pour l’adresse IP du serveur qui livre le message. Seul un pass compte comme bon résultat. Avec softfail, neutral ou none, le destinataire n’a aucune preuve SPF de l’expéditeur.

Le nom HELO n’est pas vérifié, comme le font les grands fournisseurs de messagerie pour le courrier en masse. Le rapport affiche chaque enregistrement et chaque mécanisme du parcours, pour que le chemin vers le résultat final reste visible.

Pourquoi le nombre de requêtes DNS est-il important ?

Une évaluation SPF a droit à 10 requêtes DNS au maximum. Les mécanismes include, a, mx, ptr, exists et redirect comptent chacun dans cette limite, y compris ceux des includes imbriqués. Au-delà de la limite, le résultat devient une erreur permanente, et les destinataires traitent alors le message comme s’il n’avait aucun SPF valide. Les requêtes vides, c’est-à-dire sans enregistrement en retour, ont une limite séparée de deux. Les longues chaînes d’includes de services tiers en sont la cause habituelle. Réduire la liste des services règle le problème.

Que prouve DKIM ?

DKIM ajoute une signature cryptographique aux en-têtes du message. Le domaine signataire publie la clé publique dans le DNS sous un sélecteur. echo.email récupère la clé et vérifie la signature par rapport aux en-têtes et au corps tels qu’ils sont arrivés. Un pass signifie que les parties signées sont arrivées sans modification et que le domaine signataire s’en porte garant.

Le rapport indique le domaine signataire (d=), le sélecteur (s=), les en-têtes signés (h=) ainsi que le type et la taille de la clé. Une limite de longueur du corps (l=) est signalée, car elle permet d’ajouter du contenu après la signature.

Qu’est-ce que DMARC ?

DMARC relie SPF et DKIM au domaine de l’adresse From visible. Le domaine From publie une politique sous _dmarc.<domain>. Elle indique aux destinataires comment traiter le courrier dont l’authentification échoue : none, quarantine ou reject. Un message réussit DMARC quand SPF ou DKIM réussit pour un domaine aligné sur le domaine From.

DMARC n’ajoute aucune authentification propre. Son intérêt tient à l’exigence d’alignement et aux rapports agrégés (rua=) que les destinataires envoient au propriétaire du domaine.

Que veut dire aligné ?

L’alignement compare un domaine authentifié au domaine From. L’alignement souple exige le même domaine organisationnel, donc mail.example.com est aligné sur example.com. L’alignement strict exige exactement le même nom d’hôte. Le domaine organisationnel vient de la Public Suffix List, qui sait que des noms comme example.co.uk forment un seul domaine enregistrable. Quand le rapport dit aligné sans autre précision, la comparaison porte sur le domaine From.

Qu’est-ce que BIMI ?

BIMI publie un logo de marque que les fournisseurs de messagerie affichent à côté du courrier authentifié. L’enregistrement se trouve sous default._bimi.<domain> et pointe vers un logo SVG (l=) et, pour la plupart des fournisseurs, vers un Verified Mark Certificate (a=). BIMI ne s’applique qu’aux domaines dont la politique DMARC est appliquée, c’est-à-dire quarantine ou reject à 100 pour cent. echo.email affiche l’enregistrement et indique si la politique DMARC remplit cette condition.

Pourquoi le DNS inverse est-il important ?

Chaque adresse IP qui envoie du courrier a besoin d’un enregistrement PTR qui pointe vers un nom d’hôte. Ce nom d’hôte a besoin d’un enregistrement A ou AAAA qui pointe vers la même adresse IP. Cet aller-retour s’appelle forward-confirmed reverse DNS, ou FCrDNS. Les grands fournisseurs de messagerie considèrent le FCrDNS comme le minimum pour un serveur d’envoi, et le courrier venant d’une adresse IP sans enregistrement PTR est souvent refusé d’emblée.

Qu’est-ce qu’un DNS inverse générique ?

Certains enregistrements PTR suivent un modèle de nommage de fournisseur d’accès, comme 192-0-2-10.dynamic.example.net. Ces noms évoquent une connexion résidentielle ou un serveur que personne n’a configuré pour le courrier, et les filtres s’en méfient. Un nom dédié dans le propre domaine de l’expéditeur, comme mail.example.com, désigne un serveur mail configuré volontairement.

Quel nom HELO convient le mieux ?

Le serveur d’envoi se présente avec un nom HELO ou EHLO au début de l’échange SMTP. Un bon nom appartient au serveur d’envoi, se résout dans le DNS et correspond à l’enregistrement PTR de l’adresse IP d’envoi. Les adresses IP seules, les noms comme localhost et les chaînes aléatoires sont typiques des logiciels malveillants et du spam snowshoe, et les filtres en tiennent compte.

Pourquoi vérifier TLS ?

Le TLS opportuniste chiffre l’échange SMTP quand le serveur de réception propose STARTTLS. echo.email propose STARTTLS sur chaque connexion et enregistre la version TLS et le chiffrement choisis par l’expéditeur. Le courrier envoyé sans TLS circule en clair entre les deux serveurs, et Google et Yahoo exigent TLS des expéditeurs en masse. Le rapport compte aussi les liens et les images chargés en simple http, car ces requêtes circulent elles aussi sans chiffrement.

Pourquoi vérifier IPv6 ?

Deux questions déterminent si un message est prêt pour IPv6. La première est de savoir si l’expéditeur atteint les serveurs mail uniquement en IPv6. Un message arrivé en IPv6 répond directement oui. Un message arrivé en IPv4 compte quand même comme compatible IPv6 si l’hôte d’envoi a un enregistrement AAAA, si le DNS inverse de cette adresse IPv6 désigne le même hôte et si SPF réussit pour cette adresse. La plupart des serveurs mail choisissent IPv4 ou IPv6 à chaque connexion, donc le message suivant du même hôte arrive souvent en IPv6. La seconde question est de savoir si chaque hôte qui fournit les images et les liens du message a un enregistrement AAAA. Ainsi, un lecteur sur un réseau uniquement IPv6 ou derrière un NAT de niveau opérateur charge quand même le contenu. Le rapport indique que le message est prêt pour IPv6 quand les deux réponses sont oui.

Comment la taille de l’e-mail est-elle mesurée ?

La taille de l’e-mail est le nombre d’octets transmis : tous les en-têtes, chaque partie MIME, les pièces jointes et le surcoût de l’encodage base64 ou quoted-printable. Gmail tronque les messages qui contiennent plus d’environ 102 Ko de HTML et masque le reste derrière un lien. La partie tronquée contient souvent le lien de désabonnement et le pixel de suivi.

Qu’est-ce que le poids des images ?

Le poids des images est la taille totale des images distantes appelées par des balises <img>. Il est mesuré en téléchargeant chaque image une fois. Ce chiffre est un minimum, car les images des attributs srcset et les arrière-plans CSS ne sont pas comptés. Un message lourd se charge lentement sur une connexion mobile et consomme le forfait de données du lecteur.

Qu’est-ce que le surpoids des images ?

Le surpoids des images estime les octets qu’un expéditeur économise en servant chaque image à une taille plus proche de sa taille d’affichage dans le message. Une image jusqu’à deux fois sa taille d’affichage compte comme zéro surpoids, car les écrans haute densité utilisent ces pixels supplémentaires. Au-delà de deux fois la taille d’affichage, les pixels supplémentaires ajoutent des octets sans ajouter de détail. Les images de moins de 1 Ko, comme les espaceurs, ne sont pas comptées.

Comment echo.email traite-t-il les images ?

L’analyse télécharge une fois chaque image distante et enregistre le statut HTTP, les redirections, la taille, le type de contenu et les dimensions en pixels. Elle compare ensuite ces dimensions avec la taille déclarée dans le HTML. Télécharger une image revient à faire ce que fait un logiciel de messagerie quand un lecteur ouvre le message, donc le suivi des ouvertures enregistre une ouverture. Les téléchargements partent du réseau Cloudflare, et les requêtes vers des adresses privées ou internes sont refusées.

Les liens sont extraits du HTML et regroupés par hôte, avec les paramètres de requête décodés pour une lecture plus facile. echo.email ne suit jamais les liens ordinaires, car suivre un lien risque de confirmer un abonnement, de déclencher une action ou d’enregistrer un clic. La seule exception est l’URL de désabonnement en un clic décrite plus bas.

Qu’est-ce que List-Unsubscribe ?

List-Unsubscribe est un en-tête défini par la RFC 2369. L’en-tête contient un ou plusieurs moyens de quitter la liste, sous forme d’adresse mailto:, d’URL https: ou des deux. Les fournisseurs de messagerie utilisent cet en-tête pour afficher leur propre bouton de désabonnement à côté du nom de l’expéditeur. Les URL en simple http sont dépassées, et https est la forme attendue.

Qu’est-ce que le désabonnement en un clic ?

La RFC 8058 ajoute un second en-tête, List-Unsubscribe-Post, avec la valeur fixe List-Unsubscribe=One-Click. Quand les deux en-têtes sont présents, le fournisseur de messagerie envoie une requête POST à l’URL https et le destinataire quitte la liste sans visiter de page web. Google et Yahoo exigent le désabonnement en un clic des expéditeurs en masse.

echo.email envoie la même requête POST et affiche la réponse. Tout statut 2xx compte comme un succès. La requête désabonne uniquement l’adresse temporaire d’echo.email.

Que signifie un désabonnement sans interaction ?

Un désabonnement sans interaction aboutit sans que le destinataire ouvre un navigateur ou confirme quoi que ce soit. Le one-click de la RFC 8058 est la méthode préférée. Une adresse mailto: dans List-Unsubscribe compte aussi. Le désabonnement par e-mail est cependant plus lent et ne donne aucune confirmation au destinataire, donc les fournisseurs le traitent comme une solution de repli.

Pourquoi un lien de désabonnement dans le message reste-t-il nécessaire ?

Dans la plupart des pays, les lois sur le marketing exigent un moyen visible de quitter la liste dans le message lui-même, en général un lien en pied de page. Les en-têtes servent au fournisseur de messagerie, et le lien en pied de page sert au lecteur. echo.email cherche un lien avec un texte de désabonnement ou une URL qui ressemble à un désabonnement. Cette détection est une heuristique et choisit parfois le mauvais lien. Un paramètre de suivi distinct sur le lien en pied de page permet de distinguer, dans les statistiques de l’expéditeur, les désabonnements par le pied de page et par l’en-tête.

Qu’est-ce que List-Id ?

List-Id (RFC 2919) nomme la liste de diffusion à laquelle appartient un message, par exemple News <news.example.com>. Google et Yahoo n’exigent pas cet en-tête. Les serveurs de réception et les destinataires l’utilisent pour trier et filtrer le courrier par flux, donc l’ajouter est une bonne pratique.

Qu’est-ce que la liste des bonnes pratiques ?

La liste suit les exigences que Google et Yahoo ont publiées en 2024 pour les expéditeurs en masse : SPF aligné, DKIM aligné, DNS inverse confirmé (FCrDNS), TLS, un domaine From qui n’appartient pas à un service de messagerie gratuit et pour lequel DMARC n’échoue pas, une politique DMARC publiée, au moins une méthode d’authentification alignée, le désabonnement en un clic et un lien de désabonnement visible. Chaque ligne indique oui ou non. Une ligne rouge est une cause probable d’un moins bon placement en boîte de réception chez les grands fournisseurs. Le score maximal est la base pour le courrier en masse.

Certaines lignes ne comptent que si elles s’appliquent. Les deux lignes de désabonnement comptent quand le message porte un en-tête d’envoi en masse : List-Unsubscribe, List-Unsubscribe-Post, List-Id, ou Precedence avec la valeur bulk, list ou junk. Pour un message personnel sans aucun de ces en-têtes, ces lignes ne comptent pas. L’alignement SPF ne compte pas dans le score quand l’expéditeur d’enveloppe a été réécrit avec SRS et que DMARC réussit grâce à un DKIM aligné. Après une réécriture SRS, SPF vérifie le domaine du serveur qui a réécrit l’adresse au lieu du domaine From. Les services de transfert utilisent SRS par conception, et certains serveurs d’envoi appliquent SRS à tout le courrier sortant, ce qui fait perdre l’alignement SPF. Le score indique le nombre de lignes réussies sur le nombre de lignes comptées.

Comment le message est-il affiché ?

La vue de rendu affiche la partie HTML dans un cadre isolé (sandbox). Le navigateur effectue le rendu, donc le résultat correspond à un navigateur de bureau plutôt qu’à un logiciel de messagerie ou à un appareil précis. Les scripts, les formulaires et les liens sont désactivés dans l’aperçu. D’autres vues montrent le message avec les images bloquées et avec le texte alternatif à la place de chaque image. C’est ainsi que beaucoup de lecteurs voient d’abord un message.

Que montre la section MIME ?

MIME est la structure interne d’un message : les parties, leurs types de contenu, jeux de caractères, encodages de transfert et les délimiteurs qui les séparent. Une newsletter typique contient un conteneur multipart/alternative avec une partie text/plain et une partie text/html. Une partie texte absente, un délimiteur de fin absent ou une imbrication inhabituelle ressort dans l’arborescence.

Que montre la section Message brut ?

La section Message brut affiche le message tel qu’il a été reçu, avec des statistiques : taille totale, nombre de lignes, ligne la plus longue, caractères hors ASCII et sauts de ligne sans CR. La RFC 5322 limite une ligne à 998 caractères, et certains serveurs coupent ou refusent les lignes plus longues. Les sauts de ligne sans retour chariot (CR) sont une cause fréquente d’échecs DKIM, car les serveurs en chemin les réécrivent.

La vue du message brut commence par les en-têtes de trace que mx.echo.email enregistre à la livraison : Return-Path, Authentication-Results, Received-SPF et Received. En dessous se trouve le message exactement tel qu’il a été reçu, et le lien de téléchargement fournit le fichier .eml intact.

Quelles listes de blocage le rapport vérifie-t-il ?

Les serveurs de réception recherchent l’adresse IP d’envoi et les domaines d’expéditeur sur des listes de blocage DNS, et une inscription sur une liste répandue entraîne un courrier refusé ou filtré. Le rapport vérifie les mêmes listes que scan.mx : Spamhaus ZEN et AuthBL pour l’adresse IP, Spamhaus DBL et ZRD pour le domaine From et le domaine d’enveloppe, ainsi que SpamCop, GBUdb Truncate et PSBL pour les adresses IPv4. Chaque ligne indique listé ou non listé, avec un lien vers la page de retrait de l’opérateur de la liste.

Une inscription par politique sur Spamhaus PBL signale une plage d’adresses qui ne doit pas envoyer de courrier directement, comme une connexion domestique. Le courrier d’une telle adresse doit passer par le serveur mail du fournisseur. Les résultats sont mis en cache pendant deux heures, donc une correction apparaît dans un nouveau test au plus tard après deux heures.

Que signifie le score SpamAssassin ?

SpamAssassin est un filtre antispam open source utilisé par de nombreux serveurs de réception. Le serveur mail évalue chaque message de test avec SpamAssassin et ses règles standard, mises à jour chaque jour. Le rapport affiche le total, le seuil de spam de 5 et chaque règle déclenchée, en commençant par celles qui ont le plus de points. Les points négatifs comptent en faveur du message, par exemple pour une signature DKIM valide.

Les tests réseau recherchent l’adresse IP d’envoi et les domaines des liens sur Spamhaus (via DQS), URIBL, SURBL et les autres listes des règles standard. L’apprentissage bayésien et les réseaux d’empreintes partagés Razor, Pyzor et DCC restent désactivés. Le score dépend donc du message seul, et aucune information sur le message ne quitte le serveur pour un apprentissage.

Le score est indicatif et ne compte pas dans le score des bonnes pratiques. Chaque serveur de réception utilise son propre filtre, avec ses propres règles et seuils, et Gmail et Outlook n’utilisent pas du tout SpamAssassin. Un score supérieur à zéro est normal. Les règles qui ont le plus de points montrent où une modification aide le plus. Les messages de plus de 500 Ko ne sont pas évalués.

Pourquoi les domaines d’expéditeur ont-ils besoin de serveurs mail ?

Les réponses vont au domaine From, et les rebonds vont au domaine de l’expéditeur d’enveloppe. Les deux ont besoin d’un enregistrement MX, ou au moins d’un enregistrement d’adresse que les serveurs mail utilisent en solution de repli. Un null MX, c’est-à-dire un MX unique qui pointe vers un point (RFC 7505), déclare qu’un domaine n’accepte aucun courrier. Certains serveurs de réception refusent les messages venant d’un tel domaine.

Quels éléments HTML sont considérés comme à risque ?

Les scripts, formulaires, iframes, objects et embeds ont rarement leur place dans un e-mail. La plupart des logiciels de messagerie les suppriment, et les filtres antispam les comptent comme un signal d’hameçonnage. De simples liens et images remplissent le même rôle sans cette pénalité. La section Contenu affiche aussi la taille du HTML et la part de texte visible qu’il contient, car un message presque entièrement fait de balises ou d’images paraît suspect aux filtres.

Pourquoi signaler les raccourcisseurs de liens ?

Les raccourcisseurs publics comme bit.ly cachent la vraie destination. Les campagnes d’hameçonnage les utilisent beaucoup, donc les filtres se méfient des liens qui passent par eux. Les liens qui pointent directement vers le domaine de l’expéditeur construisent au contraire une réputation.

Que montre la section DNS ?

Chaque requête DNS faite pour le rapport apparaît dans la section DNS, regroupée par objectif : DNS inverse, SPF, DKIM, DMARC, BIMI, serveurs mail et vérification IPv6. Les requêtes vers les listes de blocage n’y figurent pas, car leurs noms contiennent une clé d’accès. Chaque entrée affiche le nom, le type d’enregistrement, le code de réponse, les réponses avec leur TTL et les éventuels enregistrements d’autorité. La liste montre quels enregistrements ont produit chaque résultat, ce qui aide quand une modification DNS récente n’a pas encore atteint tous les résolveurs.

Autres outils gratuits

scan.mx
Vérifie la configuration mail d’un domaine : MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Vérifie quels ports TCP sont ouverts sur une adresse IP, y compris le port 25.