Lire un rapport SenderRadar bloc par bloc

Un rapport SenderRadar se lit de haut en bas : l'identité du domaine organisationnel, puis le domaine recherché, puis les sous-domaines, puis le comportement wildcard. Chaque bloc commence par des badges qui résument l'état, et se déplie pour montrer l'enregistrement brut et son analyse. Cette page décrit chaque bloc, chaque badge, et ce qu'il convient de faire quand une valeur n'est pas celle attendue.

L'en-tête : date d'analyse et date d'expiration#

La ligne sous le nom du domaine indique la date de l'analyse et la date jusqu'à laquelle le rapport reste consultable (trente jours). Les valeurs affichées sont celles observées à la date d'analyse ; si le domaine a été modifié depuis, il faut relancer une analyse pour voir l'état actuel.

Le bloc Whois du domaine organisationnel#

Le rapport s'ouvre sur les informations d'enregistrement du domaine organisationnel : bureau d'enregistrement (registrar), titulaire lorsqu'il est publié, dates de création, de modification et d'expiration, statut (par exemple clientTransferProhibited), serveurs de noms, contact abuse et présence de DNSSEC.

Ce bloc sert à situer le domaine : un domaine créé il y a quelques jours, sans DNSSEC et avec des serveurs de noms génériques n'a pas le même profil qu'un domaine enregistré depuis quinze ans. Une date d'expiration proche mérite une vérification auprès du registrar. Le registre peut ne pas répondre ; le bloc l'indique alors sans bloquer le reste du rapport.

Le bloc « Domaine recherché » et le bloc « Domaine organisationnel »#

Si le nom saisi est un sous-domaine, le rapport affiche deux blocs : celui du sous-domaine, puis celui du domaine organisationnel dont il dépend. S'il s'agit déjà du domaine organisationnel, un seul bloc apparaît. Chacun comporte trois lignes.

Ligne MX#

Chaque hôte MX est précédé d'un badge : le nom du prestataire reconnu, ou « Non classifié » quand le motif n'est pas connu. « Aucun MX » signifie que le domaine ne reçoit pas de courrier. Ce n'est pas une anomalie pour un sous-domaine d'envoi pur, mais un domaine qui n'a ni MX ni politique DMARC restrictive reste utilisable par un tiers pour envoyer en son nom. Dans le détail, le tableau donne l'hôte, sa priorité (la plus basse est contactée en premier) et sa classification.

Ligne SPF#

Le premier badge est le statut de l'enregistrement : ok en vert ; permerror en rouge quand l'enregistrement est inexploitable (syntaxe invalide, plusieurs enregistrements SPF, limite dépassée) ; d'autres statuts en orange signalent un avertissement. « Aucun SPF » indique l'absence d'enregistrement.

Deux badges complètent le statut :

• n/10 lookups : le nombre de résolutions DNS consommées par les mécanismes include, a, mx, ptr, exists et redirect. La RFC 7208 en autorise dix ; au-delà, les récepteurs renvoient permerror et l'enregistrement ne protège plus rien. Un compteur à 8 ou 9 impose de surveiller chaque ajout de prestataire.
• all= suivi du qualifier : -all (hardfail) rejette tout expéditeur non listé, ~all (softfail) le marque sans le rejeter, ?all ne décide rien, +all autorise tout le monde et vide l'enregistrement de son sens.

Le détail déplié ajoute :

• Void lookups : résolutions qui ont renvoyé NXDOMAIN ou aucune réponse. Au-delà de deux, la RFC demande un permerror. Il s'agit en général d'un include vers un prestataire quitté ou d'un nom mal orthographié.
• Bloque tout envoi : « Oui » si l'enregistrement se réduit à v=spf1 -all, ce qui est la configuration recommandée pour un domaine qui n'envoie jamais.
• Taille enregistrement : en octets, avec un avertissement au-delà de 512, seuil historique des réponses UDP.
• Utilise des macros : les lettres de macros présentes (%{i}, %{d}...). Les macros sont légitimes mais rendent l'évaluation dépendante de chaque message ; le compteur de lookups ne peut alors être qu'estimé.
• Profondeur include max : niveau d'imbrication le plus profond. Un arbre profond est fragile : chaque prestataire intermédiaire peut casser la chaîne.
• Arbre des mécanismes : chaque mécanisme, son qualifier, et son statut d'évaluation, avec l'indentation des include. C'est là que l'on repère un prestataire oublié ou un include en double.

Ligne DMARC#

Le badge principal est la politique : p=reject en vert, p=quarantine en orange, p=none ou absence de p en rouge. « Aucun DMARC » signifie qu'aucun enregistrement n'a été trouvé à _dmarc.<domaine>. Un badge « valide (RFC 7489) » confirme que l'enregistrement est syntaxiquement correct ; dans le cas contraire, le détail liste les raisons.

Le détail déplié donne chaque balise :

• Politique (p) : ce que le récepteur doit faire d'un message non aligné. La trajectoire habituelle est none (observation), puis quarantine, puis reject.
• Politique sous-domaines (sp) : politique appliquée aux sous-domaines sans enregistrement propre. Absente, elle vaut p. Un sp=none sous un p=reject laisse les sous-domaines ouverts.
• Pourcentage (pct) : part des messages auxquels la politique s'applique. Un pct=10 en reject n'est pas un reject.
• Alignement DKIM (adkim) et Alignement SPF (aspf) : r (relâché, même domaine organisationnel) ou s (strict, domaine identique). Le relâché est la valeur par défaut et convient dans la plupart des cas.
• Failure options (fo) : conditions d'envoi des rapports forensiques.
• Rapports agrégés (rua) et Rapports forensiques (ruf) : adresses destinataires. Sans rua, aucune visibilité sur les échecs ; c'est la première balise à renseigner.

Un sous-domaine sans enregistrement propre affiche « Hérité de » suivi du domaine organisationnel : la RFC 7489 prévoit qu'il reprend la politique de ce dernier (sp si elle est définie, sinon p).

La table des sous-domaines identifiés#

Chaque ligne correspond à un sous-domaine connu, avec trois colonnes de badges compacts. En MX, un badge unique nomme le prestataire ; un + accompagne un prestataire reconnu mêlé à des hôtes non classifiés ; « Mixte » signale plusieurs prestataires. En SPF, le statut en vert ou en orange. En DMARC, la politique p= du sous-domaine, en vert pour reject. Cliquer sur une ligne charge le détail complet, identique à celui des blocs principaux.

La lecture utile est transversale : repérer les sous-domaines qui envoient (MX ou SPF présents) et qui restent en p=none ou sans SPF, alors que l'apex est protégé.

Le bloc Wildcard DNS#

Quand il apparaît, ce bloc indique que *.<domaine> répond pour n'importe quel nom inexistant. Il affiche la configuration générique renvoyée (MX, SPF, DMARC du joker, ou « Aucun » pour chacun) et précise combien de sous-domaines testés ne renvoyaient que cette configuration et ont été masqués de la table. Un wildcard avec MX mérite attention : il accepte du courrier pour une infinité d'adresses, et un wildcard sans DMARC laisse chaque nom inventé hériter de la politique du domaine organisationnel, à condition qu'elle existe.

Pour aller plus loin#

Un rapport SenderRadar décrit ce qui est publié ; il ne dit pas comment un message réel est traité à l'arrivée. Pour tester l'envoi d'un email ou surveiller un domaine dans la durée, des outils dédiés existent, à choisir selon les volumes et les contraintes de chaque expéditeur.