Comment protéger un domaine ne faisant pas d'émission d'email ?
Vous possédez des domaines pour la protection d'identité, la réservation de nom pour une utilisation ultérieure, contre le typosquatting ou une redirection web.
Mais ces domaines ne sont pas utilisés pour émettre des emails : Protégez-les !
Exemple
fictif.fr héberge un site web et est utilisé pour la messagerie.
fictif.net, fictif.org, fic-tif.fr redirigent vers le site web fictif.fr mais ne sont pas utilisés pour de la messagerie.
Astuces
Protéger tous les domaines contre l'usurpation email avec DMARC !
La protection est la configuration SPF, DKIM et DMARC et MX pour expliciter aux antispams qu'aucun email n'est légitime et doit être détruit et non délivré en boite de réception :
- Créer un enregistrement SPF vide - obligatoire : aucune adresse IP n'est autorisée à émettre d'email SPF vide - obligatoire : aucune adresse IP n'est autorisée à émettre d'email
@[.domain.com] TXT "v=spf1 -all"
- Créer un enregistrement DMARC de protection - obligatoire : aucun email ne doit être accepté en boite de réception et doit être rejeté (détruit)
_dmarc[.domain.com] TXT "v=DMARC1; p=reject;"
Avec l'utilisation d'une plateforme de collecte de RUA comme Merox, il peut être interessant d'avoir la visibilité sur d'éventuel email shadowIT ou tentatives de phishing avec une adresse pour les rapports RUA :
_dmarc[.domain.com] TXT "v=DMARC1; p=reject; rua=mailto:[[email protected]];"
- Créer un enregistrement DKIM vide - recommandé : forcer un dkim=fail auprès des antispams
*._domainkey[.domain.com] TXT "v=DKIM1; p="
- Créer un enregistrement MX vide - recommandé : aucun email ne doit être adressé au domaine
[domain.com] MX 0 "."
Pour tous les sous-domaines (en s'assurant qu'aucun autre MX n'est déjà déclaré) :
*[.domain.com] MX 0 "."
Cette déclaration limite fortement la charge des relais de messagerie qui conservent en file d'attente, pendant plusieurs jours, des millions d'emails envoyés à l'aveugle par des attaquants. Ne pas définir de MX (Mail eXchange = serveur de réception email) n'est pas suffisant pour indiquer qu'aucune réception légitime n'est prévue et certains relais vont tenter d'adresser cela sur les serveurs définis sur les entrées A ou AAAA si elles existent.
source RFC7505 Null MX
Cet article a-t-il été utile ?
C'est super !
Merci pour votre commentaire
Désolé ! Nous n'avons pas pu vous être utile
Merci pour votre commentaire
Commentaires envoyés
Nous apprécions vos efforts et nous allons corriger l'article