Avis publié le 4 novembre 2026English Русский Українська العربية Deutsch Español Français Italiano 日本語 한국어 Polski Português ภาษาไทย Türkçe Tiếng Việt 简体中文

Comment nous vérifions votre courrier électronique

Nous vérifions où une copie particulière a atterri et ce qui peut être établi concernant sa configuration d'envoi et son contenu. Les résultats décrivent les boîtes aux lettres de test aux heures de contrôle enregistrées. La couverture peut être partielle : un résultat disponible n'établit pas que les contrôles manquants ont été réussis.

Où l'e-mail est arrivé

Vous envoyez un e-mail depuis votre propre système d'envoi aux adresses de test sélectionnées. Nous recherchons sa copie chez chaque fournisseur et enregistrons son dossier et l'heure de détection. Ceci observe des boîtes aux lettres particulières ; il ne prédit pas une campagne entière.

Boîte de réception, spam, autres dossiers: La copie a été trouvée dans ce dossier. Les promotions et les newsletters comptent comme reçues, mais pas comme boîte de réception principale.
E-mail introuvable: Une recherche réussie n'a trouvé aucune copie correspondante lors de la vérification. Cela ne prouve pas un refus de livraison ou un placement de spam.
Impossible de vérifier: La lecture de la boîte aux lettres a échoué ou les preuves sont insuffisantes. Nous ne remplaçons pas le spam ou la boîte de réception par un résultat inconnu.

Comment le pourcentage de la boîte de réception est calculé

Boîte de réception principale ÷ copies externes reçues × 100

Par exemple : 3 Boîtes de réception + 6 Spam + 1 introuvable = 10 boîtes mail sélectionnées. Neuf exemplaires ont été reçus ; la part de la boîte de réception est de 3/9, soit 33 %. Lisez toujours le numérateur, le dénominateur et la couverture d’observation.

La boîte aux lettres de diagnostic LDM est exclue des décomptes externes et du pourcentage de la boîte de réception. Les copies manquantes, les rebonds et les boîtes aux lettres indisponibles sont également exclus de ce pourcentage. Un échantillon insuffisant laisse la note globale inconnue. Le seuil d'affichage d'une note est une règle technique du service, et non une garantie statistique pour votre audience.

États techniques et correspondance de copie

Dans l'API, une recherche confirmée sans copie est placement=not_received, provider_availability.status=disponible, raison=mailbox_read_succeeded. measured_at enregistre le temps de lecture.

Un résultat not_received enregistré avec un échec de lecture confirmé devient seed_unavailable avec la raison = mailbox_read_failed. Un résultat inachevé reste en attente, avec des échecs de lecture dans provider_availability. Les preuves lues manquantes n’établissent pas une recherche terminée.

L’historique de livraison et l’échec d’une livraison de contrôle de service ne remplacent pas une mesure enregistrée. Chaque copie conserve son fournisseur, son heure de réception et l'identité du message disponible. Un rapport peut contenir différents domaines De : il s'agit d'une différence entre les copies, et non d'une preuve qu'un message sans rapport a été trouvé. La correspondance dépend des identifiants et de la recherche disponible. Un UID IMAP est lié à sa boîte aux lettres et à UIDVALIDITY ; déplacer un message peut changer son UID. Microsoft Graph possède ses propres règles d'identité. Une recherche limitée peut manquer une copie.

Observations sur 24 heures

Résultat initial et contrôles ultérieurs

La collecte initiale se termine normalement après une dizaine de minutes. Chaque copie externe reçue a sa propre fenêtre de 24 heures à compter de sa première détection confirmée. Les contrôles ultérieurs observent cette même copie ; nous n'envoyons pas de nouveaux emails pour dessiner le graphique.

Des observations sont programmées toutes les heures. Le graphique compact affiche les points de contrôle sélectionnés à 0/3/6/12/18/24 heures. Une couleur confirme le dossier uniquement à l'heure de mesure enregistrée. L'emplacement entre les contrôles est inconnu, même lorsque les résultats adjacents correspondent.

Les points futurs, les lacunes et les erreurs restent des états distincts. Une erreur ultérieure n’efface pas le dossier confirmé précédent, mais ne confirme pas non plus le dossier actuel. Une fenêtre terminée ne signifie pas que chaque mesure a réussi.

Les notifications de modification et l'e-mail final dépendent des paramètres activés et de la vérification du destinataire. Leur statut est indiqué dans le rapport. Les destinataires désabonnés ne reçoivent pas de notifications.

Signification des horodatages des graphiques

Une tentative planifiée ne constitue pas une mesure réussie. Les files d'attente, les limites des fournisseurs et les erreurs peuvent retarder ou ignorer une vérification. Les points confirmés dans le graphique et la liste complète des tentatives sont des décomptes différents. Un calendrier inconnu n'établit pas l'absence d'observations réelles.

La première détection dans le spam n'implique pas un placement antérieur dans la boîte de réception. Un changement de dossier est détecté entre les vérifications ; son heure exacte et sa cause peuvent être inconnues. Le résultat final conserve le dernier dossier confirmé et son heure, y compris les observations incomplètes ; une mesure réussie à minuit exactement n'est pas garantie.

Expéditeur et serveur

L'envoi des tests s'effectue à partir d'une copie sauvegardée : d'abord la copie de diagnostic LDM avec une identité adaptée, sinon une copie externe adaptée. Si une correspondance fiable n'est pas disponible, la copie sélectionnée est marquée comme incertaine. Les détails identifient sa source, son heure, son origine et son adresse IP disponible. Nous ne comblons pas les résultats manquants avec des passes provenant d'autres copies.

Authentification à partir du domaine

De est l’adresse indiquée dans le message. Recevoir une copie et faire correspondre l'adresse saisie pour le test ne l'authentifie pas. Nous affichons l'authentification à partir du domaine séparément, uniquement lorsque des preuves suffisantes lient une vérification DMARC réussie à cette copie. Cela ne vérifie pas une boîte aux lettres ou une personne particulière.

SPF: Vérifie si l'IP est autorisée à envoyer pour le domaine de l'enveloppe SMTP, utilisé pour l'adresse de retour. Il peut différer de From.
DKIM: Vérifie une signature et l'intégrité des parties de message signées. Le domaine de signature peut différer de From. Aucune signature et une signature dont la validation a échoué sont des résultats différents.
DMARC: Nécessite une vérification SPF ou DKIM réussie avec un domaine aligné sur le De visible. Une politique p=none signifie une surveillance et non un échec d’authentification.

Si les contrôles n'authentifient pas le domaine, nous l'affichons comme non vérifié. Si les preuves sont insuffisantes, le résultat reste inconnu. Une différence entre le domaine saisi et From est signalée séparément. Une authentification réussie ne garantit pas le placement dans la boîte de réception.

Sources de preuves, versions de résumé et de spécification

Nous utilisons une validation locale enregistrée du message d'origine ou un résultat de serveur de réception fiable. Un en-tête Authentication-Results arbitraire ne constitue pas une preuve. La provenance SMTP est importante : une adresse IP dans Reçu peut appartenir à un relais ; l'enveloppe SMTP et HELO ne peuvent pas être reconstruits à partir du visible From seul. L'authentification nécessite un résultat DMARC réussi lié au domaine de cette même copie ; les documents plus anciens sans reliure suffisante restent inconnus.

Le résumé technique All Clear nécessite des vérifications réussies SPF, DKIM, DMARC et PTR, des données sources connues et des requêtes de liste de blocage terminées sans résultat. Un problème confirmé génère des problèmes détectés ; preuves manquantes ou erreurs produites Impossible de vérifier. Des problèmes et des preuves incomplètes peuvent coexister. Les résultats contradictoires pour le même domaine et la même adresse IP restent visibles.

La disponibilité de SPF, DKIM et DMARC est indépendante : l'absence de preuve SMTP pour SPF n'invalide pas une vérification de signature DKIM disponible. Chaque méthode conserve son résultat exact et son motif de disponibilité. Il s’agit de conventions de résumé de test, et non d’exigences minimales de chaque fournisseur. Le résultat de l’authentification de domaine distinct nécessite ses propres preuves à l’appui. SPF conserve les résultats de réussite, d'échec, d'échec logiciel, neutre, aucun et les erreurs ; un chemin inverse SMTP nul utilise l’identité HELO. Une recherche de clé DKIM a besoin de son sélecteur ; un sélecteur inconnu n'établit pas de DKIM cassé.

Un alignement DMARC strict nécessite des domaines identiques ; l’alignement détendu utilise le domaine organisationnel selon les règles de l’évaluateur. La spécification actuelle est la RFC 9989, qui rend obsolète les RFC 7489 et RFC 9091. Les résultats locaux enregistrés utilisaient mailauth 4.6.8 et ses règles d'évaluation de domaine ; l'ouverture d'un rapport ne les recalcule pas selon la nouvelle spécification.

Version de la méthode enregistrée : 2026-10-01 ; révision actuelle de l'interprétation des résultats : 2026-11-04. La révision de l'évaluateur est affichée uniquement là où elle a été enregistrée ; une révision manquante dans un rapport plus ancien n’est pas remplacée par la date d’aujourd’hui. Nous utilisons des règles conservatrices versionnées : les preuves insuffisantes restent inconnues. Les cas reproductibles confirmés étendent les règles versionnées uniquement après des tests de régression ; les cas non pris en charge restent inconnus. Les règles n’apprennent pas automatiquement des résultats des tests. La date de révision de ce document ne modifie pas la version du moteur ni les résultats historiques.

PTR, DNS et listes de blocage

IP → PTR → A/AAAA →même adresse IP

PTR passe lorsque l'adresse IP pointe vers un nom d'hôte dont les enregistrements A/AAAA contiennent cette même adresse IP. Il n'est pas nécessaire que le nom d'hôte corresponde au domaine From. Un enregistrement manquant ou une incompatibilité IP fait échouer la vérification ; une erreur de recherche ou des preuves manquantes signifient qu'il n'a pas pu être vérifié.

Les résultats du PTR et de la liste de blocage décrivent l'adresse IP indiquée au moment de la vérification. Les détails montrent la source IP ; une adresse des en-têtes peut appartenir à un relais. Ces résultats n’authentifient pas le domaine From.

Les vérifications de la liste de blocage IP utilisent l'adresse IP identifiée pour la copie du message enregistré sélectionné. Nous montrons l'IP et sa source. Une adresse issue des en-têtes de message peut appartenir à un relais et n'authentifie pas elle-même l'expéditeur. Si l'IP n'est pas disponible, le résultat reste inconnu ; nous ne remplaçons pas une adresse MX, une adresse déduite de From ou l’IP d’une autre copie. Nous interrogeons un ensemble limité de listes de blocage d'adresses IP. « Non répertorié dans les listes de blocage vérifiées » signifie uniquement que les vérifications nommées terminées n'ont trouvé aucune liste au moment de leur enregistrement. Les listes, les erreurs et les contrôles incomplets sont affichés séparément. Les vérifications de domaine ne remplacent pas les vérifications IP. Aucune annonce ne garantit une bonne réputation ou un placement dans la boîte de réception.

Il s'agit de résultats enregistrés : l'ouverture du rapport ne déclenche pas de nouveau contrôle. L’heure de réception de la copie est distincte de l’heure de vérification de la liste de blocage. Si l'heure de contrôle n'a pas été enregistrée, nous l'indiquons explicitement.

Qui configure PTR et en quoi HELO diffère

Le propriétaire IP ou le service d'envoi configure le PTR. Pour votre propre serveur, demandez au fournisseur IP de définir PTR sur un nom d'hôte tel que mail.example.org, puis pointez le A/AAAA de ce nom d'hôte vers la même adresse IP. Un enregistrement PTR dans la zone de domaine ordinaire ne configure pas la zone IP inversée. Une plateforme d'envoi gère les PTR pour ses propres serveurs.

La recherche directe vérifie le premier nom d'hôte PTR renvoyé : A pour IPv4, AAAA pour IPv6. Si plusieurs noms sont renvoyés, les autres ne sont pas comptés comme vérifiés ; leur décompte est conservé en détail. HELO/EHLO est le nom présenté par le serveur SMTP. Sa configuration et les exigences supplémentaires du fournisseur sont distinctes du résultat PTR. Si le nom ou la preuve du test est manquant, aucune correspondance n'est présumée.

Un enregistrement DNS est un paramètre publié et non une vérification de message réussie. Un enregistrement SPF TXT, une clé DKIM ou une politique DMARC à elle seule n'authentifie pas cette copie. MX identifie les serveurs de messagerie entrants et n'établit pas l'adresse IP sortante. Les vérifications des rapports enregistrés ne sont pas de nouvelles recherches DNS à chaque fois que vous ouvrez la page.

Contenu de l'e-mail

Un test de livraison analyse la copie reçue ; le vérificateur de brouillon séparé analyse le contenu téléchargé. Le MIME original provenant d'une copie externe peut prendre en charge l'authentification locale. Le contenu MIME peut techniquement être analysé sans preuve SMTP complète, mais les résultats du contenu, SpamAssassin et Rspamd ne sont affichés que si ces vérifications ont réellement été effectuées. La disponibilité de MIME seul ne signifie pas que ces vérifications ont été exécutées. Le rapport distingue les contrôles terminés, ignorés et indisponibles. Les scores de l'analyseur ne constituent pas un pourcentage de la boîte de réception ni une cause établie de spam.

SpamAssassin et Rspamd utilisent des règles et des seuils différents ; leurs résultats ne sont pas moyennés en une probabilité de livraison. Une capture d'écran enregistrée montre le message dans son contexte capturé, et non un test de chaque client de messagerie. Une capture d'écran manquante n'invalide pas une mesure de dossier.

Copie reçue

Nous analysons la copie du message disponible. Les parties incomplètes, cryptées ou indisponibles ne sont pas considérées comme vérifiées avec succès.