Faux positifs DNS sur mail.faktify.fr, sous-domaine d’envoi

Merci — le rapport était assez précis pour qu'on aille droit au but. Tout est corrigé et en ligne. Mais sur un point, tu avais tort, et c'est le plus intéressant.

Le SPF n'était pas mal détecté. Il était périmé.

Tu demandes de « corriger la détection SPF lorsqu'un domaine ne publie qu'un TXT ». Elle fonctionne. Voici la chronologie :

| 14 h 31 | tu prépares mail.faktify.fr pour l'envoi — et la veille l'audite |
| 14 h 35 | Mail confirme ton SPF et ta clé DKIM : les enregistrements sont là |

La veille a mesuré quatre minutes avant que tu publies. Elle n'a pas mal lu : à cet instant, il n'y avait rien à lire. Puis son verdict est resté affiché cinq heures.

Le vrai défaut n'est donc pas la détection — c'est que Mail savait depuis 14 h 35, et que personne ne le lui demandait. Deux modules qui connaissent le même fait sans se parler.

Corrigé à la racine : vérifier un domaine d'envoi remet désormais la veille à zéro sur ce domaine. Le verdict se corrige au tour suivant, dans la minute. Tu n'auras rien à faire.

Les deux défauts que tu as vraiment trouvés

« Aucun serveur de noms déclaré : le domaine ne résout plus. » En gravité sérieuse. C'est faux, et deux fois : un NS marque un point de délégation, pas la capacité à résoudre. Ton sous-domaine est servi par la zone de faktify.fr — comme la quasi-totalité des sous-domaines — et il résout parfaitement, ton courrier en est la preuve. On t'annonçait une panne alors que ta configuration était juste. Le constat dit maintenant : « Pas de délégation propre : ce nom est servi par la zone de son parent. »

Les contrôles web sur un nom qui n'héberge rien. Tu l'as mieux formulé que nous : « Ajouter ces enregistrements uniquement pour faire taire la veille serait trompeur. » Tu as raison, et c'est le pire qu'un outil de surveillance puisse produire — pousser à dégrader une configuration correcte pour obtenir une pastille verte. Sans A ni AAAA, il n'y a pas de site : HTTPS, robots.txt, sitemap.xml, llms.txt et les en-têtes sont désormais « sans objet », et l'absence d'adresse se lit « c'est cohérent : ce nom sert le courrier, pas un site ».

Ce que ça donne chez toi, maintenant

Réaudité à 19 h 44, zéro constat sérieux. Il reste quatre « attention », et je te les laisse parce qu'ils disent quelque chose :

• spf — « ~all laisse passer les usurpations, simplement marquées comme suspectes. » C'est le seul conseil réellement utile du lot. -all les fait refuser. À ne changer qu'une fois sûr que tout ce qui envoie pour ce domaine est dans l'include.
• dmarc — un DMARC même en p=none te donnerait les rapports d'authentification. Sur un domaine d'expédition, ça vaut le coup.
• mx et caa — à ignorer sur un sous-domaine d'envoi. Le constat MX le dit d'ailleurs lui-même.

Ta question de fond

Tu demandes comment configurer un domaine technique pour qu'il ne soit contrôlé que sur l'authentification e-mail. Aujourd'hui : rien à configurer. La veille le déduit de ce qu'elle observe — pas d'adresse, donc pas de site à auditer ; un SPF ou un MX, donc un nom qui sert le courrier.

C'est délibérément une déduction et non un réglage : un réglage se pose une fois, s'oublie, et ment le jour où le domaine change d'usage. Ce qu'on mesure ne ment pas.

Tout est documenté dans la notice, section « Un sous-domaine n'est pas un domaine cassé » du module Veille — et https://letock.fr/notice.md est régénérée à chaque publication, donc elle ne peut pas être en retard sur ce que tu viens de lire.