Diagnostic Email

Les serveurs receveurs ne notent pas SPF, DKIM et DMARC séparément. Un message peut passer SPF et finir quand même en spam si la signature DKIM est cassée, ou passer les deux et atterrir en spam si l'alignement DMARC échoue entre l'en-tête From: visible et le domaine qui a réellement authentifié le message. Chaque mécanisme vérifie une chose différente : SPF autorise quels serveurs peuvent envoyer, DKIM prouve que le corps du message n'a pas été modifié en transit, et DMARC relie les deux dans une politique que le serveur receveur peut appliquer.

Les enregistrements MX et le statut de blacklist sortent de cette chaîne d'authentification mais affectent la délivrabilité tout aussi directement. Un domaine avec un SPF/DKIM/DMARC irréprochable garde un courrier entrant cassé si ses MX pointent vers un serveur mort, et son courrier sortant finit quand même en spam si l'IP d'envoi figure sur une liste noire DNS (RBL) que le filtre anti-spam du destinataire consulte.

Un diagnostic complet lance les six vérifications sur le même domaine en une seule passe : SPF, DMARC, BIMI, DKIM, MX et statut RBL, chacune notée indépendamment puis regroupée en un score global. C'est la différence avec les pages dédiées à un seul enregistrement - il montre comment les éléments interagissent entre eux, pas seulement si un enregistrement pris isolément est syntaxiquement valide.

• SPF - quels serveurs sont autorisés à envoyer des emails pour le domaine (RFC 7208)
• DKIM - signature cryptographique prouvant que le message n'a pas été modifié après signature (RFC 6376)
• DMARC - politique reliant les résultats SPF/DKIM au domaine From: visible, avec rapports (RFC 7489)
• MX - quels serveurs reçoivent le courrier entrant du domaine, par ordre de priorité (RFC 5321)
• RBL - présence des IP d'envoi du domaine sur des listes noires DNS consultées par les filtres anti-spam
• BIMI - affichage optionnel du logo de marque dans les messageries compatibles, conditionné à une politique DMARC stricte

Chaque vérification renvoie un statut parmi quatre : réussi, avertissement, échec, ou informatif (réservé aux constats neutres comme "rien à vérifier" plutôt qu'un verdict réussite/échec). Les vérifications sont regroupées en six catégories - SPF, DMARC, DKIM, MX, RBL et BIMI - chacune affichée dans sa propre carte avec le nom du test, ce qui a été trouvé, et une recommandation de correction avec un exemple de syntaxe quand le test échoue.

Le score global pondère les réussites au maximum, les avertissements partiellement, les constats informatifs presque au maximum, et les échecs à zéro, puis fait la moyenne sur l'ensemble des vérifications exécutées. Un domaine dans la tranche haute a une authentification qui fonctionne et des IP d'envoi propres ; un domaine dans la tranche moyenne a en général un seul mécanisme cassé (souvent DKIM ou l'alignement DMARC) qui tire vers le bas un SPF et un MX par ailleurs corrects ; un score bas signifie en général que plusieurs mécanismes sont soit absents, soit mal configurés.

La section RBL résout l'enregistrement A du domaine et les adresses de ses serveurs MX, puis interroge chacune de ces IP auprès de plusieurs listes noires DNS publiques (Spamhaus, Spamcop, Barracuda, SORBS et CBL notamment) selon le format de requête en octets inversés que ces listes attendent. Une présence sur l'une d'elles est un signal fort que le courrier envoyé depuis cette IP est rejeté ou mis en spam par les serveurs receveurs abonnés à la même liste - indépendamment du fait que SPF, DKIM ou DMARC soient corrects.

Un diagnostic complet sert au tri, pas à la correction : une fois qu'il signale quelle catégorie échoue, la correction demande en général un niveau de détail propre au mécanisme que la vue combinée n'a pas la place d'afficher. Un échec SPF gagne à être traité sur la page SPF dédiée, car les échecs SPF viennent souvent de la limite des 10 requêtes DNS ou d'une chaîne d'include redondante - des détails qu'un résumé sur une ligne ne peut pas montrer. Même logique pour deviner un sélecteur DKIM ou pour planifier le déploiement d'une politique DMARC : chacun a assez de subtilité pour mériter sa propre page une fois que ce diagnostic a indiqué où chercher.

L'ordre pratique pour corriger plusieurs échecs à la fois : d'abord MX (un routage entrant cassé est en général le plus urgent et le moins susceptible d'avoir une cause subtile), puis SPF et DKIM dans l'ordre qui convient puisque l'alignement DMARC dépend des deux, et la politique DMARC en dernier puisque la durcir avant que les mécanismes sous-jacents ne passent commence à rejeter du courrier légitime. Les inscriptions en liste noire (RBL) sont en général des symptômes : un compte compromis, un relais ouvert, une IP mutualisée avec un mauvais voisin. Elles se traitent donc en dernier, sauf si des emails rebondissent déjà.