N’utilisez-vous pas votre domaine pour envoyer des courriels ? Protégez-le contre l’usurpation

Même si vous n’utilisez pas votre domaine pour envoyer des e-mails, quelqu’un peut essayer de l’utiliser pour se faire passer pour vous. Pour l’éviter, vous devez indiquer que personne n’est autorisé à envoyer des e-mails depuis ce domaine.

Cela peut se produire avec des domaines que vous avez achetés pour protéger votre marque, des domaines que vous utilisez uniquement pour afficher un site web ou des domaines qui redirigent vers une autre adresse. Même si vous n’avez jamais créé de compte e-mail comme contact@votredomaine.com, quelqu’un pourrait essayer d’utiliser cette adresse pour envoyer des e-mails frauduleux en se faisant passer pour vous.

La solution consiste à publier des règles claires dans les enregistrements DNS du domaine, qui indiquent quels services sont autorisés à l’utiliser.

Comment peuvent-ils envoyer des e-mails s’ils n’ont pas accès à votre domaine ?

L’adresse qui apparaît comme expéditeur d’un e-mail peut être falsifiée. C’est similaire à écrire une fausse adresse sur l’expéditeur d’une lettre : le fait qu’une adresse apparaisse ne prouve pas que le message en provient réellement.

Cette pratique est connue sous le nom de spoofing d’e-mail ou usurpation de l’expéditeur. Un attaquant pourrait envoyer des messages qui semblent provenir d’adresses telles que :

• facturation@votredomaine.com
• support@votredomaine.com
• administration@votredomaine.com

Il n’a pas besoin d’entrer dans votre panneau ni de connaître vos mots de passe pour essayer. L’objectif est généralement de tirer parti de la confiance générée par le nom de domaine pour demander des paiements, voler des identifiants ou distribuer des fichiers malveillants.

Lorsque quelqu’un reçoit un de ces e-mails, son service de messagerie vérifie les enregistrements DNS du domaine pour vérifier si le message a été envoyé depuis un serveur autorisé. Si le domaine n’a pas de règles claires, il sera plus difficile de détecter que l’expéditeur est faux et de décider si le message doit être accepté, envoyé dans les spams ou rejeté.

Votre domaine peut être exposé même s’il n’a pas de comptes e-mail

Ne pas utiliser d’e-mail avec un domaine peut créer une fausse impression de sécurité. Précisément parce que personne ne vérifie sa configuration, il est courant que ces domaines n’aient pas de protection spécifique contre ce type d’usurpation.

Ce scénario est fréquent dans :

• Domaines achetés pour protéger une marque.
• Variations du domaine principal.
• Domaines qui redirigent vers un autre site web.
• Domaines utilisés uniquement pour une page de destination.
• Domaines anciens qui n’envoient plus d’e-mails.
• Sous-domaines destinés à des applications ou services internes.

Par exemple, une entreprise pourrait travailler avec mamarque.com, mais avoir également enregistré mamarque.fr pour protéger son nom. Bien que le second domaine ne fasse que rediriger vers le site principal, il est conseillé d’empêcher quelqu’un d’essayer d’envoyer des e-mails depuis administration@mamarque.fr.

Les trois enregistrements que vous devez connaître

SPF, DKIM et DMARC forment le système d’authentification qui permet de vérifier si un e-mail est autorisé. Cependant, ils ne sont pas tous utilisés de la même manière lorsqu’un domaine n’envoie pas de messages.

Vous pouvez vérifier si votre domaine a configuré ces mesures de protection avec des outils comme DMARC Domain Checker. Il vous suffit de saisir le nom de votre domaine pour consulter ses enregistrements SPF, DKIM et DMARC et détecter s’il en manque un.

SPF : indique que personne n’est autorisé à envoyer des e-mails depuis le domaine

SPF est un enregistrement DNS qui définit quels serveurs sont autorisés à envoyer des messages au nom d’un domaine.

Lorsque le domaine ne doit envoyer aucun e-mail, vous pouvez publier une politique indiquant qu’il n’existe aucun serveur autorisé :

v=spf1 -all

La partie -all indique qu’aucun serveur n’a la permission d’envoyer des e-mails depuis ce domaine. Si quelqu’un essaie de le faire, le message ne passera pas la vérification SPF et le service qui le reçoit pourra l’identifier comme non autorisé.

Ce n’est pas la même chose que de laisser le domaine sans un enregistrement SPF. Si cet enregistrement n’existe pas, les services de messagerie ne savent pas clairement qui peut envoyer des messages depuis le domaine. En revanche, avec v=spf1 -all, vous indiquez expressément ce qui suit :

Ce domaine n’est pas utilisé pour envoyer des e-mails. Par conséquent, tout message envoyé depuis lui doit être considéré comme non autorisé.

DKIM : vous n’avez pas besoin d’une signature si vous n’envoyez pas

DKIM ajoute une signature numérique aux e-mails que vous envoyez. Le service qui reçoit le message peut vérifier cette signature à l’aide d’une clé publiée dans les enregistrements DNS du domaine. Ainsi, il peut vérifier que l’e-mail provient d’un service autorisé et que son contenu n’a pas été modifié pendant l’envoi.

Si le domaine n’est pas utilisé pour envoyer des e-mails, il n’y a aucun message à signer et, par conséquent, vous n’avez pas besoin de configurer DKIM.

Que se passe-t-il si vous voulez envoyer des e-mails ?

Dans ce cas, vous devez activer DKIM. Vous n’avez pas besoin de créer la signature par vous-même : le service que vous utilisez pour envoyer des e-mails, comme votre fournisseur de messagerie, une plateforme de newsletters ou une application, vous fournira l’enregistrement DKIM que vous devez ajouter aux DNS. Si vous utilisez le service de messagerie de cdmon, vous pouvez consulter ce qu’est le DKIM individuel et pourquoi il est important de le configurer.

Chaque service peut utiliser sa propre clé. C’est pourquoi, si vous envoyez des e-mails depuis plusieurs plateformes, vous devez suivre les instructions de chacune et ajouter les enregistrements DKIM qu’elles vous fournissent.

DMARC : indique quoi faire avec les e-mails qui se font passer pour votre domaine

DMARC ne rejette pas les e-mails par lui-même. C’est une règle qui indique aux services de messagerie, comme Gmail ou Outlook, ce qu’ils doivent faire lorsqu’ils reçoivent un message qui semble envoyé depuis votre domaine, mais qui ne passe pas les vérifications de sécurité.

Par exemple, vous pouvez indiquer que ces e-mails soient rejetés pour qu’ils n’atteignent pas leurs destinataires.

Dans un domaine que vous n’utilisez pas pour envoyer des e-mails, vous pouvez ajouter cette règle :

v=DMARC1; p=reject;

Cette règle est enregistrée dans un enregistrement TXT, un type d’enregistrement DNS qui permet d’ajouter des informations écrites au domaine. Dans ce cas, elle sert à indiquer à des services comme Gmail ou Outlook ce qu’ils doivent faire avec les e-mails qui tentent de se faire passer pour votre domaine.

Vous devez ajouter cet enregistrement depuis le panneau du fournisseur qui gère les DNS de votre domaine.

Créez un nouvel enregistrement de type TXT et entrez ces données :

• Nom ou hôte : _dmarc
• Type d’enregistrement : TXT
• Valeur ou contenu : v=DMARC1; p=reject;

Il n’est pas nécessaire d’écrire _dmarc.votredomaine.com en entier si le panneau ajoute automatiquement le nom de votre domaine. Avant de le sauvegarder, vérifiez comment le résultat s’affiche : il doit apparaître comme _dmarc.votredomaine.com.

Si vous souhaitez également protéger les sous-domaines, utilisez cette valeur :

v=DMARC1; p=reject; sp=reject;

La partie sp=reject applique la même protection aux adresses utilisant des sous-domaines, comme support@boutique.votredomaine.com.

Ne confondez pas envoyer des e-mails avec les recevoir

Les enregistrements SPF et DMARC aident à éviter que quelqu’un envoie des e-mails en se faisant passer pour votre domaine. Les enregistrements MX remplissent une autre fonction : ils indiquent à quels serveurs doivent être livrés les e-mails que vous recevez.

C’est pourquoi vous devez distinguer entre deux situations.

Le domaine n’envoie pas, mais reçoit des e-mails

Si vous n’utilisez pas le domaine pour envoyer des e-mails, mais que vous souhaitez continuer à les recevoir ou les rediriger vers une autre adresse, vous pouvez bloquer les envois via SPF et DMARC comme nous l’avons vu dans la section précédente. Ces enregistrements aident à éviter que d’autres personnes envoient des messages en se faisant passer pour votre domaine.

Pour continuer à recevoir des e-mails, laissez les enregistrements MX tels qu’ils apparaissent dans les DNS du domaine. Vous n’avez pas besoin d’en créer d’autres ni d’ajouter leur contenu à SPF ou DMARC.

Ne supprimez ni ne remplacez les enregistrements MX, car vous cesseriez de recevoir des messages.

Le domaine n’envoie ni ne reçoit des e-mails

Si vous n’utilisez pas le domaine pour envoyer ni recevoir des e-mails, vous pouvez configurer un enregistrement appelé Null MX. Cet enregistrement indique clairement que le domaine ne dispose d’aucun service de messagerie et, par conséquent, n’accepte pas de messages.

Pour le configurer, accédez au panneau depuis lequel vous gérez les DNS du domaine et créez un enregistrement de type MX avec ces données :

• Nom ou sous-domaine : @
• Destination : .
• Priorité : 0

Si le domaine a déjà d’autres enregistrements MX, vous devrez les supprimer, car ils indiquent qu’il existe des serveurs autorisés à recevoir ses e-mails. Faites-le uniquement si vous avez vérifié que vous n’utilisez aucun compte de messagerie, alias ou redirection lié au domaine.

Le Null MX est plus approprié que de laisser le domaine sans enregistrements MX. Si vous les supprimez simplement, certains serveurs pourraient essayer de livrer les messages à l’adresse IP du site web. En revanche, le Null MX les informe directement que le domaine ne reçoit pas d’e-mails et évite ces tentatives inutiles.

Configuration recommandée selon l’utilisation du domaine

Utilisation de l’e-mail	SPF	DKIM	DMARC	MX
Ne pas envoyer · Oui recevoir	v=spf1 -all*	Non nécessaire	p=reject*	Conserver les MX
Ne pas envoyer · Ne pas recevoir	v=spf1 -all	Non nécessaire	p=reject; sp=reject	Null MX
Envoyer via un service	Autoriser les serveurs réels	Configurer la clé du service	Vérifier avant d’appliquer reject	Selon le service de réception

* Vous ne devez utiliser ces politiques que si vous avez vérifié que le domaine n’envoie pas de messages depuis des formulaires, newsletters, applications ou autres plateformes.

Avant d’appliquer une politique de rejet, vérifiez tous vos envois

Un domaine peut envoyer des e-mails même si vous n’utilisez pas une boîte de réception pour le faire. Par exemple :

• Formulaires de contact de WordPress.
• Confirmations d’achat de WooCommerce.
• Factures automatiques.
• Avis de réservations.
• Récupérations de mot de passe.
• Newsletters et campagnes commerciales.
• Notifications d’une application.
• Services de support client.

Si vous configurez v=spf1 -all ou DMARC avec p=reject alors que votre site web ou un service continue d’envoyer des e-mails depuis le domaine, ces messages pourraient être bloqués même s’ils sont légitimes.

Avant de modifier les enregistrements, faites un inventaire de tous les services associés au domaine. Si vous en découvrez un, vous devrez l’autoriser via SPF, activer son DKIM et vérifier que les deux sont correctement alignés avec DMARC.

Comment protéger un domaine qui n’envoie pas d’e-mails sur cdmon

Si les DNS du domaine sont gérés sur cdmon, vous pouvez vérifier l’authentification depuis le panneau de contrôle.

Avant de modifier quoi que ce soit :

1. Confirmez qu’aucun compte, site web ou plateforme externe n’envoie d’e-mails depuis le domaine.
2. Vérifiez si le domaine reçoit des messages ou utilise des redirections.
3. Enregistrez une copie des enregistrements DNS actuels.
4. Vérifiez s’il existe déjà des enregistrements SPF ou DMARC. Vous ne devez pas créer deux enregistrements SPF ni deux politiques DMARC pour le même domaine.
5. Configurez la politique correspondant à l’utilisation réelle du domaine.
6. Attendez que les modifications DNS se propagent et vérifiez à nouveau les enregistrements.

Depuis ConnectiLogs, vous pouvez consulter l’état de SPF, DKIM et DMARC de vos domaines et détecter s’il manque une configuration.

Si vous n’êtes pas sûr qu’un formulaire, une application ou une plateforme externe envoie des messages, n’appliquez pas directement une politique de rejet. Vérifiez d’abord la configuration ou contactez l’équipe de support de cdmon.

Erreurs courantes à éviter

Penser que ne pas avoir d’enregistrements MX empêche d’envoyer des e-mails

Les enregistrements MX sont utilisés pour recevoir des messages. Les supprimer n’empêche pas quelqu’un d’essayer d’afficher votre domaine comme expéditeur.

Créer un deuxième enregistrement SPF

Un domaine ne doit avoir qu’un seul enregistrement SPF. S’il en existe déjà un, vous devez le modifier ou le remplacer selon le cas, ne pas en ajouter un autre séparément.

Appliquer p=reject sans vérifier les formulaires et plateformes

Même si vous n’utilisez pas de comptes e-mail, votre site web pourrait envoyer des confirmations, des avis ou des réponses automatiques. Une politique trop stricte peut bloquer ces messages légitimes.

Publier un Null MX alors que vous avez encore besoin de recevoir des messages

Le Null MX indique que le domaine n’accepte aucun e-mail. Il empêchera également le fonctionnement des comptes, alias et redirections.

Oublier les sous-domaines

Un attaquant peut également essayer d’utiliser des adresses associées à des sous-domaines. L’étiquette sp=reject permet d’indiquer une politique de rejet pour eux.