Mon entreprise doit-elle réussir chaque vérification ici sous NIS2 ?

NIS2 (directive (UE) 2022/2555, art. 21(2) [11]) ne nomme pas spécifiquement SPF, DMARC ou DNSSEC. Elle exige des mesures de cybersécurité fondées sur le risque, et la plupart des ensembles de mesures CyFun du CCB attendent le chiffrement en transit (couvert par HTTPS, HSTS, MTA-STS et CAA) et un canal de divulgation des vulnérabilités (à quoi sert security.txt).

Est-ce un audit de sécurité complet ?

Non. Il vérifie un ensemble spécifique d’enregistrements DNS et HTTPS publics et d’en-têtes, une petite partie d’une évaluation de conformité CyFun ou NIS2, pas l’ensemble. Réussir chaque vérification ici ne signifie pas que le domaine, ou l’organisation derrière, est conforme.

Pourquoi DKIM indique-t-il un échec alors que le courrier a une signature qui fonctionne ?

La vérification DKIM ne regarde que sous cinq noms de sélecteurs courants (google, selector1, selector2, default, k1). Un fournisseur utilisant un sélecteur différent affichera un échec ici même si DKIM est correctement configuré. C’est indiqué directement dans le résultat.

Cela conserve-t-il les domaines vérifiés ?

Non. Le résultat est mis en cache brièvement pour éviter de relancer les mêmes recherches, et chaque appel est journalisé contre l’adresse IP de l’appelant uniquement pour la limitation de débit. Aucun domaine, adresse e-mail ou résultat n’est conservé au-delà.

Puis-je vérifier le domaine de quelqu’un d’autre, comme un prospect ?

Oui. Chaque vérification ici ne lit que des réponses DNS et HTTP publiques, la même information que tout navigateur ou serveur de messagerie voit déjà, il n’y a donc rien à autoriser.

Que se passe-t-il si le CCB modifie le catalogue CyFun ou si NIS2 est amendée ?

Les identifiants de mesures CyFun ici sont vérifiés directement contre le catalogue du CCB (packages/api/src/frameworks/cyfun/controls.yaml) et les lettres de l’art. 21(2) de NIS2 contre la directive (UE) 2022/2555 [11], les deux revérifiés à chaque changement de l’une des sources, jamais retapés une fois pour toutes.

← Outils gratuits

OUTIL GRATUIT

Ce domaine est-il protégé contre l’usurpation d’e-mail ?

Cet outil gratuit vérifie en une dizaine de secondes les enregistrements SPF, DMARC, DKIM, DNSSEC, CAA, MTA-STS, TLS-RPT, MX et HTTPS/HSTS d’un domaine, sans inscription. Il indique si le domaine peut être usurpé par e-mail, si ses réponses DNS peuvent être falsifiées, et s’il impose des connexions chiffrées, chaque résultat associé à une mesure CyFun et une obligation NIS2.

Par Tom Janssens · Fondateur, Easy Cyber Protection · Dernière revue 3 novembre 2026 · Comment nous écrivons

Que vérifie cette analyse de sécurité de domaine ?

SPF: Indique quels serveurs de messagerie peuvent envoyer des e-mails au nom de ce domaine.; Un SPF manquant ou erroné signifie que n’importe qui peut envoyer des e-mails qui semblent provenir de ce domaine. La RFC 7208 [1] limite aussi SPF à 10 recherches DNS ; au-delà, les destinataires échouent la vérification quoi qu’il arrive.
DMARC: Indique aux serveurs destinataires quoi faire des e-mails qui échouent à l’authentification.; Sans politique DMARC (RFC 7489 [2]), les e-mails usurpés atteignent quand même la boîte de réception, même si SPF ou DKIM existent.
DKIM: Une signature cryptographique (RFC 6376 [3]) sur le courrier sortant, vérifiée sous cinq noms de sélecteurs courants.; Cela n’exclut que les sélecteurs les plus courants, pas toute configuration DKIM. Un sélecteur différent est une fausse alerte, pas un vrai problème.
DNSSEC: Signe cryptographiquement les réponses DNS du domaine (RFC 4035 [4]).; Sans cela, un attaquant réseau peut présenter de fausses réponses DNS aux visiteurs d’un domaine.
CAA: Restreint quelles autorités de certification peuvent émettre un certificat TLS pour ce domaine (RFC 8659 [5]).; Sans cela, n’importe quelle autorité de certification publique peut émettre un certificat pour le domaine.
MTA-STS: Indique aux autres serveurs de messagerie d’exiger une connexion chiffrée et authentifiée pour livrer le courrier ici (RFC 8461 [6]).; Sans cela, le courrier entrant peut être silencieusement rétrogradé en texte clair.
TLS-RPT: Demande un rapport chaque fois qu’un autre serveur échoue à négocier TLS vers ce domaine (RFC 8460 [7]).; Sans cela, une configuration de chiffrement du courrier défectueuse peut passer inaperçue indéfiniment.
MX: Les serveurs de messagerie qui gèrent le courrier de ce domaine.; L’absence de MX signifie que le domaine ne peut recevoir aucun courrier. C’est normal pour un domaine qui n’envoie que via un autre domaine.
HTTPS (apex et www): Si le site répond de façon sécurisée sur le domaine nu et sur son adresse www.; Un domaine qui ne répond pas en HTTPS ne peut pas être atteint de façon sécurisée par les visiteurs.
Redirection HTTP → HTTPS et HSTS: Si http:// simple est redirigé vers https://, et si le site envoie un en-tête Strict-Transport-Security suffisamment long (RFC 6797 [8]).; Sans les deux, un visiteur peut rester sur, ou être renvoyé vers, une connexion non chiffrée.
security.txt: Un fichier standard (RFC 9116 [9]) indiquant aux chercheurs en sécurité comment signaler une vulnérabilité.; Sans cela, quelqu’un qui découvre une faille n’a aucun canal officiel pour la signaler de façon responsable.

Aucune mesure CyFun unique ne couvre SPF, DMARC ou DKIM, et aucune ne couvre DNSSEC [10]. Des enregistrements SPF, DMARC et DKIM publiés sont une preuve complémentaire pour PR.PS-05.1 (filtres web et e-mail installés et utilisés). Les vérifications de chiffrement en transit (HTTPS, HSTS, MTA-STS, TLS-RPT, CAA) correspondent à GV.PO-01.2, dont la politique doit couvrir la cryptographie et le chiffrement.

Le catalogue complet des mesures se trouve sur la page des mesures CyFun, et ce que la loi exige précisément sur la page des exigences NIS2.

À quoi ressemble un résultat typique ?

Un domaine qui envoie des newsletters via une plateforme marketing mais n’a jamais touché à son DNS au-delà de l’enregistrement MX d’origine échoue généralement directement sur SPF, DMARC et DKIM (rien n’a jamais été publié), réussit sur MX (le courrier arrive toujours), et réussit souvent sur HTTPS parce que la plateforme d’hébergement l’impose par défaut. Cette combinaison, un hébergement moderne sans enregistrements d’authentification e-mail, est le motif le plus courant que cet outil met en évidence.

Pour les MSP : chaque résultat ici peut être montré à l’écran à un prospect, en moins d’une minute, sans rien à installer de son côté : une façon d’ouvrir une conversation NIS2 ou CyFun, ou une vérification rapide avant une mission de messagerie ou de DNS gérés.

Besoin de faire cela sur toute la base clients d’un MSP ?

ECP exécute l’évaluation CyFun complète, sous le contrôle d’un organisme d’évaluation de la conformité, pour chaque client géré par un MSP, dont cette vérification de domaine n’est qu’une petite partie.

Voir comment ECP fonctionne pour les MSP →

Puis-je placer ceci sur mon propre site ?

Une version intégrable, sans habillage, de cet outil est disponible pour les MSP afin de la placer sur leur propre site, pour qu’un visiteur effectue la vérification sans quitter la page.

Copiez ceci dans votre page :

<iframe src="https://easycyberprotection.com/embed/domain-check?lang=fr" style="width:100%;max-width:640px;height:720px;border:0" loading="lazy" title="Contrôle de la sécurité e-mail et site web de votre domaine (SPF, DMARC, DKIM, DNSSEC, HTTPS)"></iframe>

Voici le rendu sur votre site (un aperçu en direct, essayez-le) :

votreentreprise.be/controle-securite

Votre entreprise

Questions fréquentes

Mon entreprise doit-elle réussir chaque vérification ici sous NIS2 ?: NIS2 (directive (UE) 2022/2555, art. 21(2) [11]) ne nomme pas spécifiquement SPF, DMARC ou DNSSEC. Elle exige des mesures de cybersécurité fondées sur le risque, et la plupart des ensembles de mesures CyFun du CCB attendent le chiffrement en transit (couvert par HTTPS, HSTS, MTA-STS et CAA) et un canal de divulgation des vulnérabilités (à quoi sert security.txt).
Est-ce un audit de sécurité complet ?: Non. Il vérifie un ensemble spécifique d’enregistrements DNS et HTTPS publics et d’en-têtes, une petite partie d’une évaluation de conformité CyFun ou NIS2, pas l’ensemble. Réussir chaque vérification ici ne signifie pas que le domaine, ou l’organisation derrière, est conforme.
Pourquoi DKIM indique-t-il un échec alors que le courrier a une signature qui fonctionne ?: La vérification DKIM ne regarde que sous cinq noms de sélecteurs courants (google, selector1, selector2, default, k1). Un fournisseur utilisant un sélecteur différent affichera un échec ici même si DKIM est correctement configuré. C’est indiqué directement dans le résultat.
Cela conserve-t-il les domaines vérifiés ?: Non. Le résultat est mis en cache brièvement pour éviter de relancer les mêmes recherches, et chaque appel est journalisé contre l’adresse IP de l’appelant uniquement pour la limitation de débit. Aucun domaine, adresse e-mail ou résultat n’est conservé au-delà.
Puis-je vérifier le domaine de quelqu’un d’autre, comme un prospect ?: Oui. Chaque vérification ici ne lit que des réponses DNS et HTTP publiques, la même information que tout navigateur ou serveur de messagerie voit déjà, il n’y a donc rien à autoriser.
Que se passe-t-il si le CCB modifie le catalogue CyFun ou si NIS2 est amendée ?: Les identifiants de mesures CyFun ici sont vérifiés directement contre le catalogue du CCB (packages/api/src/frameworks/cyfun/controls.yaml) et les lettres de l’art. 21(2) de NIS2 contre la directive (UE) 2022/2555 [11], les deux revérifiés à chaque changement de l’une des sources, jamais retapés une fois pour toutes.

Autres outils gratuits

Catalogue de mesures CyFun · Ce qu’exige l’art. 21(2) de NIS2 · Bases de la sécurité e-mail

Utilisez ceci avec vos clients

#CYBERLEARN

Formez l’équipe: Socle

Voir la formation →