Octobre est le Cybersecurity Awareness Month aux États-Unis et le Mois européen de la cybersécurité dans l’UE. La campagne 2026 de l’agence américaine CISA, « Securing the Next 250 », place en tête de ses quatre gestes essentiels le fait d’éviter et de signaler les arnaques par hameçonnage. Dans l’UE, une enquête Eurobaromètre publiée par la Commission européenne le 30 septembre 2026 a montré que trois salariés sur quatre avaient été confrontés à des e-mails, messages ou liens suspects au travail au cours des six mois précédant l’enquête.
Le site web, la messagerie et les connexions des clients d’une entreprise dépendent de ses noms de domaine, et cinq paramètres déterminent si ces noms peuvent être détournés, perdus ou usurpés.
Qui contrôle vos domaines ?
Celui qui détient le compte chez le registrar et la fiche du titulaire. Vérifiez donc les deux : le verrou de chaque nom, et les données de contact qui s’y rattachent.
Votre domaine est-il verrouillé contre les transferts ?
Il devrait l’être. Pour le .com et de nombreuses extensions nationales, les données publiques du domaine l’indiquent : le verrou du registrar apparaît sous la forme du code de statut clientTransferProhibited qui, comme l’explique l’ICANN, demande au registre de rejeter les demandes de transfert du domaine vers un autre registrar. Les codes clientUpdateProhibited et clientDeleteProhibited font de même pour les modifications et la suppression.
Certains registres ne publient aucun statut de verrouillage, par exemple nic.at pour le .at et la DENIC pour le .de. Pour ceux-là, demandez à votre registrar comment un transfert est autorisé.
Le verrouillage au niveau du registre (registry lock) va plus loin. Les codes qui commencent par server, comme serverTransferProhibited, sont posés par le registre, et certains registres les proposent sous la forme d’un service de verrouillage qui n’est levé qu’à la demande du registrar auprès du registre. Demandez à votre registrar lesquels de vos noms peuvent en bénéficier.
Pour vérifier, saisissez le domaine dans notre recherche whois, qui affiche les codes de statut de 20 noms au plus à la fois, lorsque le registre les publie. Vérifiez ensuite qui peut lever le verrou : l’ICANN conseille aux titulaires d’activer l’authentification multifacteur sur leur compte chez le registrar lorsqu’elle est disponible.
Les contacts titulaire et administratif sont-ils exacts ?
Ils devraient désigner l’entreprise propriétaire de la marque, avec des adresses et des numéros qu’elle contrôle. Les registres de l’UE ont commencé à vérifier ces données en application des lois nationales qui transposent la directive NIS2. EURid a publié une politique de vérification pour le .eu en octobre 2024, et la loi autrichienne NISG 2026 est entrée en vigueur le 1er octobre 2026 : les titulaires de domaines en .at doivent désormais fournir un numéro de téléphone en plus d’une adresse e-mail, et coopérer lorsqu’on leur demande de vérifier leurs données.
Le registre autrichien prévient que des justificatifs manquants ou fournis en retard peuvent le conduire à supprimer le domaine. Selon sa FAQ sur NIS2, un domaine dont les données ne sont pas vérifiées dans les 21 jours est placé en serverHold, ce qui interrompt son site web et sa messagerie, puis révoqué si les données ne sont pas corrigées dans les 30 jours suivants.
Depuis le 1er octobre, nic.at publie aussi dans le whois le numéro de téléphone et l’adresse e-mail des titulaires qui sont des entreprises, lesquelles pouvaient auparavant les masquer. Le registre recommande donc une adresse et un numéro centraux plutôt que les coordonnées propres d’un salarié.
Les avis d’expiration et les demandes de vérification sont envoyés à ces contacts. Un domaine détenu par un ancien salarié, une agence ou une filiale est difficile à renouveler, à transférer ou à défendre, et une adresse de contact sur un domaine qui expire peut être reprise par quiconque enregistre ce domaine. Pour vérifier, demandez à votre registrar la fiche complète de chaque domaine, car le whois public masque souvent les données du titulaire, et comparez le titulaire avec la dénomination sociale de l’entreprise.
Qui reçoit les avis d’expiration de vos domaines ?
L’adresse e-mail du titulaire. Pour les extensions génériques, la politique de récupération des enregistrements expirés de l’ICANN (Expired Registration Recovery Policy) impose aux registrars d’envoyer au moins deux rappels, environ un mois et environ une semaine avant l’expiration, et un autre dans les cinq jours qui suivent l’expiration si le nom n’a été ni renouvelé ni supprimé. Tous sont envoyés à l’adresse e-mail du titulaire figurant dans les données de contact.
Après l’expiration, un registrar peut proposer un délai de grâce de renouvellement automatique de 1 à 45 jours. Une fois un domaine générique supprimé, le registre doit offrir une période de rédemption de 30 jours (Redemption Grace Period), pendant laquelle le titulaire peut le restaurer par l’intermédiaire du registrar, éventuellement moyennant des frais. Le DNS est coupé avant la suppression et pendant la période de rédemption, si bien que le site web et la messagerie s’arrêtent, y compris les boîtes aux lettres hébergées sur le domaine lui-même. Les registres des extensions nationales fixent leurs propres règles.
Pour vous en assurer, activez le renouvellement automatique pour chaque nom utilisé, conservez un moyen de paiement valide, faites envoyer les avis à une boîte partagée sur un autre domaine, et dressez la liste des dates d’expiration des douze prochains mois.
Vos domaines peuvent-ils être usurpés ?
Oui, dans le DNS et dans les e-mails, sauf si la zone est signée avec DNSSEC et si chaque domaine publie SPF et DMARC.
DNSSEC est-il activé, et les clés concordent-elles toujours ?
Il devrait l’être partout où le registre le prend en charge, avec au registre un enregistrement DS qui correspond toujours à une clé de votre zone. Sans DNSSEC, explique l’ICANN, un résolveur ne peut pas vérifier qu’une réponse DNS est authentique, et un attaquant qui empoisonne son cache peut envoyer les utilisateurs vers une copie de votre site.
Notre vérification de zone DNS lit l’enregistrement DS au registre et les clés de votre zone, et indique s’ils concordent, sans vérifier les signatures. Avec une clé manquante ou différente, les résolveurs qui valident DNSSEC ne peuvent plus résoudre le domaine : lancez donc la vérification après chaque changement de fournisseur DNS. Tous les registres ne prennent pas en charge DNSSEC : notre page Gestion DNS explique comment nous le traitons.
La racine du DNS a eu sa propre échéance ce mois-ci. L’ICANN prévoyait que KSK-2024, la nouvelle clé de signature de clés de la zone racine, prenne le relais pour la signature le 11 octobre 2026. Un résolveur qui ne lui fait pas confiance (étiquette de clé 38696) traite les réponses signées avec la nouvelle clé comme falsifiées, si bien que chaque résolution échoue, comme l’explique la FAQ de l’ICANN. Si votre entreprise exploite ses propres résolveurs validants, vérifiez qu’ils la détiennent, comme le demande la page de l’ICANN sur le changement de clé.
Tous vos domaines authentifient-ils leurs e-mails, y compris ceux qui n’en envoient pas ?
Ils le devraient, car un domaine qui n’envoie aucun e-mail peut être usurpé aussi facilement qu’un domaine qui en envoie. SPF liste les serveurs autorisés à envoyer ses e-mails, DKIM signe chaque message, et DMARC indique aux serveurs de réception que faire des e-mails qui échouent aux vérifications.
Le National Cyber Security Centre (NCSC) britannique prévient qu’un enregistrement défensif ne protège pas un domaine à lui seul, et conseille de protéger d’abord les domaines qui n’envoient aucun e-mail, car une fois protégés, ils ne demandent aucune maintenance. Il liste quatre enregistrements, à créer dans cet ordre :
- SPF sans aucun expéditeur autorisé : v=spf1 -all ;
- DMARC sur _dmarc avec une politique de rejet : v=DMARC1; p=reject, avec une adresse de rapport pour repérer les abus ;
- un enregistrement MX nul, 0 ., lorsque le domaine a un enregistrement d’adresse mais aucun serveur de messagerie ;
- en option, un enregistrement DKIM générique (wildcard) avec une clé vide, qui révoque les clés éventuellement en cache.
Pour les domaines qui envoient des e-mails, le plan de mise en œuvre du NCSC commence DMARC avec la politique none, qui se contente de collecter des rapports, passe à quarantine une fois que chaque expéditeur légitime réussit les vérifications, puis à reject. La vérification de zone affiche les enregistrements SPF et DMARC de n’importe quel domaine. Les clés DKIM se trouvent sous un sélecteur défini par votre plateforme de messagerie : vérifiez-les donc sur celle-ci.
Que faire maintenant ?
Effectuez les cinq vérifications sur chacun de vos domaines, puis fixez pour chacune le moment où la refaire.
| Paramètre | Comment vérifier | Quand vérifier à nouveau |
|---|---|---|
| Verrou de transfert et accès au compte | Codes de statut whois lorsque le registre les publie ; utilisateurs du compte chez le registrar et authentification multifacteur | Quand une personne ayant accès au compte s’en va |
| Données de contact | Fiche complète obtenue du registrar, comparée aux informations légales de l’entreprise | Après une réorganisation, et à toute demande du registre |
| Renouvellement et expiration | Renouvellement automatique, moyen de paiement, adresse des avis, dates d’expiration | Un mois avant chaque date d’expiration |
| DNSSEC | Vérification de zone : l’enregistrement DS correspond à une clé de la zone | Après chaque changement de fournisseur DNS |
| SPF, DKIM, DMARC | Vérification de zone ; plateforme de messagerie pour DKIM ; rapports DMARC | Quand un service qui envoie des e-mails en votre nom est ajouté ou retiré |
Domgate enregistre et gère des domaines nationaux pour les titulaires de marques et leurs conseils. Domgate publie les enregistrements SPF, DKIM et DMARC et fait passer la politique DMARC à reject étape par étape. Son audit de stratégie globale de noms de domaine recense chaque nom avec son titulaire, ses contacts et sa date d’expiration, puis fixe des règles pour les renouvellements et la sécurité, y compris un verrouillage au niveau du registre lorsque l’extension le propose.
