Les 5 principales erreurs de déploiement de DMARC

Alors que le nombre d'attaques de phishing n'a jamais été aussi élevé, on prend de plus en plus conscience de la manière dont DMARC peut contribuer à protéger les domaines et à rendre le courrier électronique plus fiable. Ce n'est un secret pour personne que la mise en œuvre de DMARC peut être un processus complexe et intimidant. Les équipes de projet DMARC se retrouvent souvent en terrain inconnu et commettent des erreurs lors du déploiement du protocole basé sur le DNS. Nos équipes de support et de déploiement ont rassemblé quelques erreurs courantes dont il faut être conscient pour que votre projet DMARC soit plus facile et plus réussi.

Les 5 principales erreurs de DMARC

1. Enregistrement DMARC introuvable
La publication d'un enregistrement DMARC avec une politique définie sur p=none pour observer l'activité du domaine et ne pas perturber le courrier électronique est la première étape du déploiement. Si vous ne publiez pas d'enregistrement DMARC, non seulement vous ne savez pas comment votre domaine est utilisé en dehors de votre propre infrastructure surveillée, mais vous ne profitez pas de la protection de domaine offerte par DMARC. Pour publier un enregistrement DMARC, vous pouvez commencer ici.

2. Application de la politique sur un domaine actif sans surveillance
Le fait d'avoir un enregistrement DMARC avec application de la politique mais sans rapport pour surveiller le domaine (par exemple v=DMARC1 ; p=reject) ne vous donne pas la visibilité dont vous avez besoin pour maintenir la protection de votre domaine. Le contrôle est essentiel pour comprendre qui et quoi envoie des courriels en votre nom.

3. Spécifier des balises implicites
Par exemple, pct=100 revient à ne pas mettre ce couple balise/valeur. Il en va de même pour rf=afrf, aspf=r, adkim=r. L'ajout de ces balises et valeurs rend l'enregistrement plus compliqué et prend plus de place car l'enregistrement TXT devient plus long.

4. Envoi de rapports à un domaine différent
L'envoi de rapports à une destination qui inclut un domaine différent dans les balises RUA et RUF sans créer un enregistrement de vérification de domaine externe peut entraîner un risque de sécurité. Google, en particulier, ne vérifie pas cette exigence, de sorte que vous recevez toujours des rapports. Mais d'autres rapporteurs DMARC respectent l'exigence de la spécification qui consiste à ne pas envoyer de rapports à des destinations dont le domaine dans les balises RUA et RUF est différent, à moins que le domaine dans ces balises ne publie explicitement l'enregistrement de vérification de domaine externe dans le DNS. Cet enregistrement indique au monde entier que l'on peut leur envoyer des rapports DMARC sur d'autres domaines. Il s'agit d'une limitation de sécurité nécessaire pour prévenir les attaques DDoS, et il est probable que Google vérifiera cette exigence à l'avenir.

5. Syntaxe DMARC invalide
Voici quelques points à garder à l'esprit lors de la création d'enregistrements DNS :

• N'oubliez pas de placer un point-virgule entre les couples balise/valeur.
• Utiliser p=none et non p=monitor. p=monitor était une politique DMARC antérieure à la publication qui a été supplantée par p=nonela politique de surveillance.
• Spécifiez le mailto : devant l'adresse du rapport de soumission.
• Assurez-vous que l'enregistrement DNS TXT contient le nom d'hôte de _dmarc.
• Placez la balise p= après v=DMARC1 - elle est nécessaire à cet endroit.
• Supprimez les guillemets autour d'un enregistrement TXT dans le DNS, bien que certains fournisseurs de DNS acceptent les guillemets.

dmarcian s'efforce de rendre le courrier électronique plus sûr en développant la connaissance et la conscience de DMARC. Si vous n'avez pas encore commencé votre projet DMARC, vous pouvez vous inscrire pour un essai gratuit et sans engagement ici.

Vous voulez poursuivre la conversation ? Rendez-vous sur le forum dmarcien.