La création de ces enregistrements DNS spécifiques permet de protéger les domaines qui n'envoient pas de courrier électronique contre les attaques par usurpation de domaine.
Cet article s'articule autour des points suivants :
Copier le lien de l'article
Les domaines qui n'envoient pas d'e-mails peuvent toujours être utilisés dans le cadre d'attaques d'usurpation d'e-mails ou de phishing , mais il existe des types spécifiques d'enregistrements DNS text (TXT) qui peuvent être utilisés pour étouffer les attaquants. Chacun de ces enregistrements définit des règles sur la façon dont les serveurs de messagerie doivent traiter les courriels non autorisés, ce qui rend plus difficile l'exploitation de ces domaines par les attaquants.
Un enregistrement DNS TXT permet aux administrateurs de domaine de saisir du texte dans le système de noms de domaine (DNS) . Les enregistrements DNS TXT sont utilisés pour des processus tels que l'authentification des e-mails, car ils peuvent stocker des informations importantes que les serveurs peuvent utiliser pour confirmer si oui ou non un domaine a autorisé un expéditeur d'e-mails à envoyer des messages en son nom.
Parmi les exemples de domaines qui n'envoient pas d'e-mails, citons les domaines achetés pour protéger un nom de marque ou pour une activité future. Les domaines défunts ou anciens n'ont pas non plus de raison d'envoyer des e-mails et pourraient bénéficier de ce type d'enregistrement.
Il existe trois principaux types d'enregistrements TXT DNS utilisés pour l'authentification des e-mails. Chacun d'entre eux diffère légèrement dans son fonctionnement :
Comme ces enregistrements DNS fonctionnent tous de manière légèrement différente, chacun de leurs composants est unique.
SPF
Les enregistrements SPF peuvent être formatés pour protéger les domaines contre les tentatives d'hameçonnage en rejetant tout courrier électronique envoyé par le domaine. Pour ce faire, un enregistrement SPF doit utiliser le format suivant.
v=spf1 -all*Note : les enregistrements SPF sont définis directement sur le domaine lui-même, ce qui signifie qu'ils ne nécessitent pas de sous-domaine spécial.
Voici ce que signifient les différents éléments de ce dossier :
v=spf1 permet au serveur de savoir que l'enregistrement contient une politique SPF. Tous les enregistrements SPF doivent commencer par ce composant. -all indique au serveur ce qu'il doit faire avec les courriels non conformes ou avec tout expéditeur qui ne figure pas explicitement dans l'enregistrement SPF. Avec ce type d'enregistrement SPF, aucune adresse IP ou domaine n'est autorisé, donc -all indique que tous les e-mails non conformes seront rejetés. Pour ce type d'enregistrement, tous les e-mails sont considérés comme non conformes car il n'y a pas d'adresses IP ou de domaines acceptés. DKIM
Les enregistrements DKIM protègent les domaines en garantissant que les courriels ont effectivement été autorisés par l'expéditeur à l'aide d'une clé publique et d'une clé privée. Les enregistrements DKIM stockent la clé publique que le serveur de messagerie utilise ensuite pour authentifier que la signature de l'e-mail a été autorisée par l'expéditeur. Pour les domaines qui n'envoient pas d'e-mails, l'enregistrement DKIM doit être configuré sans clé publique associée. Voici un exemple :
| Nom | Type | Contenu |
|---|---|---|
*._domainkey.example.com |
TXT |
v=DKIM1 ; p= |
*._domainkey.example.com est le nom spécialisé de l'enregistrement DKIM (où "example.com" doit être remplacé par votre domaine). Dans cet exemple, l'astérisque (appelé joker) est utilisé comme sélecteur, qui est une valeur spécialisée que le fournisseur de services de messagerie génère et utilise pour le domaine. Le sélecteur fait partie de l'en-tête DKIM et le serveur de messagerie l'utilise pour effectuer la recherche DKIM dans le DNS. Le caractère générique couvre toutes les valeurs possibles pour le sélecteur. TXT indique le type d'enregistrement DNS.v=DKIM1 définit le numéro de version et informe le serveur que cet enregistrement fait référence à une politique DKIM. p permet d'authentifier les e-mails en liant une signature à sa clé publique. Dans cet enregistrement DKIM, la valeur p doit être vide car il n'y a pas de signature/clé publique à laquelle se rattacher. DMARC
Les politiques DMARC peuvent également contribuer à protéger les domaines qui n'envoient pas d'e-mails en rejetant tous les e-mails qui échouent aux contrôles SPF et DKIM. Dans ce cas, tous les e-mails envoyés par un domaine qui n'est pas configuré pour envoyer des e-mails échouent aux vérifications SPF et DKIM. Vous trouverez ci-dessous un exemple de formatage d'une politique de cette manière :
| Nom | Type | Contenu |
|---|---|---|
_dmarc.example.com |
TXT |
v=DMARC1;p=rejet;sp=rejet;adkim=s;aspf=s |
_dmarc.example.com, qui est requis pour les politiques DMARC.TXT indique le type d'enregistrement DNS.v=DMARC1 indique au serveur que cet enregistrement DNS contient une politique DMARC. p=reject indique que les serveurs de messagerie doivent rejeter les courriels qui échouent aux vérifications DKIM et SPF. adkim=s représente quelque chose appelé le mode d'alignement. Dans ce cas, le mode d'alignement est défini sur "s" pour strict. Le mode d'alignement strict signifie que le serveur du domaine de l'e-mail qui contient l'enregistrement DMARC doit correspondre exactement au domaine figurant dans l'en-tête From de l'e-mail. Si ce n'est pas le cas, la vérification DKIM échoue. aspf=s a la même fonction que adkim=s, mais pour l'alignement SPF. L'assistant DNS de Cloudflare Email Security permet de configurer facilement les enregistrements TXT DNS corrects et d'empêcher les spammeurs d'utiliser un domaine. Pour en savoir plus sur l'assistant, cliquez ici.