Surveillance de la santé du domaine e-mail : quoi contrôler et quand

Votre domaine e-mail, c'est surtout une poignée d'enregistrements DNS. Ils étaient corrects le jour où vous les avez publiés, puis quelqu'un a changé d'hébergeur, ajouté un outil d'envoi, fait tourner une clé ou fait le ménage dans des entrées TXT « inutilisées ». Rien n'annonce les dégâts. Les e-mails continuent de passer un temps, puis les rebonds et les placements en spam augmentent sans que personne sache depuis quand. Ce guide explique ce que recouvre la santé d'un domaine e-mail, quels enregistrements elle englobe, ce qui casse sans bruit, et en quoi un contrôle ponctuel diffère d'une surveillance qui tourne chaque jour.

La réponse en bref#

La santé d'un domaine e-mail, c'est la question « les enregistrements DNS qui permettent au monde entier de livrer des e-mails à ce domaine et de faire confiance à ceux qu'il envoie sont-ils présents, valides et inchangés ? ». Concrètement, cela représente six éléments : MX (peut-on vous livrer du courrier), SPF (quels serveurs peuvent envoyer en votre nom), DKIM (votre clé de signature est-elle publiée), DMARC (que doivent faire les destinataires quand les contrôles échouent), plus MTA-STS et BIMI, qui sont des options facultatives. Un contrôle ponctuel vous donne l'état à l'instant T. La surveillance répète le contrôle à intervalle régulier et vous prévient quand quelque chose change, ce qui compte parce que la plupart des pannes sont des régressions, pas des erreurs de configuration initiale. Lancez dès aujourd'hui le contrôle gratuit de la santé du domaine pour obtenir un état de référence, puis décidez si une surveillance quotidienne vaut le coup pour les domaines dont vous dépendez.

Ce que couvre un contrôle de santé du domaine#

Chaque enregistrement du tableau répond à une question différente, et chacun peut tomber en panne de son côté.

Les quatre premiers décident si vos e-mails sont livrés et inspirent confiance. Configurer DMARC et la vue d'ensemble de SPF, DKIM et DMARC ensemble expliquent comment les rédiger. MTA-STS et TLS-RPT et BIMI relèvent d'un durcissement facultatif : l'absence de l'un d'eux est une information, pas une urgence.

N'oubliez pas que les fournisseurs de messagerie l'exigent désormais. Les exigences de Google et Yahoo pour les expéditeurs attendent SPF, DKIM et un enregistrement DMARC des expéditeurs en masse, avec le domaine From aligné sur SPF ou DKIM, et Microsoft applique des règles similaires aux expéditeurs à gros volume vers les adresses Outlook.com. Un enregistrement qui disparaît discrètement peut vous faire passer de conforme à non conforme du jour au lendemain.

Ce qui casse sans que personne ne le remarque#

Les échecs d'authentification ressemblent rarement à des échecs. Les e-mails sont toujours acceptés, certains atterrissent en spam, et la cause est un enregistrement que personne n'a regardé depuis des mois. Voici ceux qui reviennent sans cesse.

• Une migration DNS fait perdre des enregistrements TXT. Vous changez d'hébergeur DNS, l'outil d'import copie les enregistrements A et CNAME, et les entrées TXT de SPF, DKIM et DMARC disparaissent ou sont abîmées. L'histoire complète est dans quand SPF, DKIM et DMARC cessent de fonctionner.
• Un second enregistrement SPF apparaît. Un outil marketing dit à quelqu'un d'« ajouter cet enregistrement TXT », et voilà le domaine avec deux enregistrements SPF. Les destinataires y voient une erreur permanente, donc SPF échoue pour tout.
• SPF dépasse 10 lookups DNS. Chaque nouvel outil ajoute un include:, et un jour l'enregistrement franchit la limite. SPF : trop de lookups DNS explique le décompte et la solution.
• Une clé DKIM est renouvelée ou supprimée. Le fournisseur passe à un nouveau sélecteur, ou quelqu'un supprime l'ancienne clé alors que les e-mails sont encore signés avec. Trouver votre sélecteur DKIM explique comment savoir quelle clé un expéditeur utilise vraiment.
• DMARC est supprimé ou ne reçoit jamais de rapports. Soit l'enregistrement a disparu, soit rua= ne pointe nulle part d'utile, et vous ne pouvez pas voir qui envoie en votre nom.
• Une clé DKIM trop courte persiste. Une clé de 1024 bits fonctionne encore, et c'est précisément pour cela qu'elle reste des années. La norme dit que les signataires devraient utiliser au moins 2048 bits.

Aucun de ces cas ne nécessite un attaquant. Ce sont de simples opérations de maintenance, et c'est pourquoi une revue humaine périodique les rate : rien ne paraît cassé tant que les chiffres ne bougent pas.

Contrôle ponctuel ou surveillance quotidienne#

Un contrôle ponctuel est le bon outil dans trois situations : après avoir publié ou modifié des enregistrements, quand vous diagnostiquez une plainte précise, et quand vous reprenez un domaine que vous n'avez pas configuré. Il est gratuit, prend quelques secondes et vous donne un instantané. Lancez le contrôle de santé du domaine pour une vue complète, ou le vérificateur SPF, DKIM et DMARC quand seuls les enregistrements d'authentification vous intéressent.

La surveillance répond à une autre question : qu'est-ce qui a changé depuis hier, et qui doit le savoir ? Les pannes ci-dessus se produisent toutes entre deux contrôles. Ce qui compte, c'est le délai entre « l'enregistrement a cassé » et « quelqu'un l'a remarqué », et avec un processus manuel, ce délai dure le temps qu'il faut aux taux de rebond pour déclencher une enquête. Un contrôle quotidien le ramène à un jour au maximum.

Une façon raisonnable de trancher :

1. Un seul domaine, rarement modifié, un seul outil d'envoi : un contrôle ponctuel après chaque changement suffit probablement.
2. Plusieurs domaines, plusieurs expéditeurs, ou plus d'une personne ayant accès au DNS : une surveillance quotidienne rentabilise son coût dès la première fois que quelqu'un modifie un enregistrement sans vous le dire.
3. Domaines parqués ou secondaires depuis lesquels vous n'envoyez jamais : vérifiez-les de temps en temps, car un enregistrement DMARC absent ou trop souple y est une invitation à l'usurpation.

Sur quoi déclencher une alerte#

Une alerte n'est utile que si elle est rare et précise. Les enregistrements pour lesquels il vaut la peine de réveiller quelqu'un sont ceux dont un changement signifie que les e-mails échouent maintenant. À titre indicatif, nous les séparerions ainsi.

À traiter le jour même :

• MX absent ou hôte MX qui ne se résout plus.
• SPF absent, SPF publié deux fois, erreur de syntaxe, ou plus de 10 lookups.
• DMARC absent ou invalide, y compris deux enregistrements DMARC.
• Un sélecteur DKIM dont vous dépendez qui ne renvoie plus de clé (le produit ne peut le signaler que pour les sélecteurs que vous lui avez indiqués).

À examiner cette semaine :

• SPF à 9 ou 10 lookups, à un ajout de l'échec.
• DMARC encore à p=none, ou aucune adresse rua= pour recevoir les rapports.
• Une clé DKIM de 1024 bits, ou une clé encore signalée comme en test (t=y).
• Un qualificateur ?all, ou le mécanisme ptr, déconseillé, dans SPF.

À titre informatif :

• Apparition ou disparition d'enregistrements MTA-STS et BIMI.

La surveillance de la santé du domaine de Qualisend les répartit en deux niveaux de gravité : 20 codes de problème couvrant MX, SPF, DKIM et DMARC, chacun marqué « bad » ou « warn », et une note du domaine qui correspond simplement à la pire gravité présente. Tout ce qui figure dans la première liste est « bad » et tout ce qui figure dans la deuxième est « warn ». Elle vous envoie un e-mail quand un problème apparaît et quand il disparaît. Les erreurs DNS comme les délais dépassés marquent le contrôle comme « impossible à vérifier » et ne déclenchent jamais d'alerte : les ennuis de résolveur ne deviennent donc pas de fausses alertes. Un problème disparaît après le deuxième contrôle sans anomalie, si bien que le retour au vert peut tarder jusqu'à deux jours, sauf si vous relancez un contrôle à la main.

Un état de référence et une routine#

Vous n'avez pas besoin d'une plateforme pour en tirer l'essentiel. Faites ceci une fois par domaine.

1. Notez vos expéditeurs. Listez chaque système qui envoie en tant que le domaine : fournisseur de messagerie, plateforme marketing, service transactionnel, CRM, helpdesk, facturation. Chacun doit figurer dans SPF et signer avec DKIM.
2. Lancez un contrôle de référence et conservez le résultat. Notez le nombre de lookups SPF, les sélecteurs DKIM qui existent et votre politique DMARC.
3. Consignez les sélecteurs DKIM utilisés par chaque expéditeur. Les noms de sélecteurs s'oublient facilement et se devinent mal par la suite. Comment trouver un sélecteur DKIM montre où les lire.
4. Publiez une adresse de rapport dans DMARC pour que les échecs laissent une trace. Lire les rapports et la surveillance DMARC expliquent quoi en faire.
5. Recontrôlez après chaque modification DNS et après l'ajout ou le retrait de tout outil d'envoi, puis une fois par mois quoi qu'il arrive.

Si un domaine compte pour votre chiffre d'affaires, cette dernière étape est celle que l'on cesse de faire, et c'est celle que la surveillance remplace.

Ce que la surveillance ne voit pas#

Soyez clair sur les limites pour ne pas lui faire confiance à mauvais escient.

• Elle lit le DNS public. Elle n'envoie pas d'e-mail de test, n'observe pas vos messages sortants réels et ne mesure pas le placement en boîte de réception. Un enregistrement SPF peut être parfaitement valide et pourtant oublier un expéditeur que vous n'avez pas ajouté. Pour voir comment un vrai message s'authentifie et ce que voit un serveur destinataire, utilisez le test de délivrabilité e-mail. Il ne mesure pas non plus le placement en boîte de réception.
• DMARC est analysé ; MTA-STS et BIMI sont seulement vérifiés pour leur présence. Elle ne récupère pas de fichier de politique MTA-STS et ne valide pas de logo ou de certificat BIMI.
• Elle surveille des domaines, pas des IP d'envoi, et ne modifie jamais votre DNS. Vous corrigez les problèmes chez votre hébergeur DNS.
• Quotidien veut dire quotidien. Un changement est détecté en 24 heures, pas en temps réel.
• Elle ne vous dit pas qui envoie en tant que votre domaine. C'est le rôle des rapports agrégés DMARC, et Rapports DMARC est le produit distinct construit autour d'eux.

La tarification est forfaitaire par palier au tarif standard : 8,99 $ par mois pour un domaine, 89 $ jusqu'à 10 et 499 $ jusqu'à 60, sans crédits et sans obligation d'acheter autre chose.

Une dernière chose à garder en tête : les normes évoluent. DMARC a été défini dans la RFC 7489, que la RFC 9989 a rendue obsolète en mai 2026 ; consultez donc le texte en vigueur si vous dépendez d'un comportement limite.

Un DNS sain fait que vos e-mails inspirent confiance, mais il ne nettoie pas la liste qui se trouve derrière. L'offre gratuite de la page des tarifs inclut 100 crédits qui lancent la vérification complète sur une liste, car un domaine bien surveillé a encore besoin d'une liste saine pour mériter la boîte de réception.