Syntaxe du DMARC

Comment garantir la sécurité en respectant la syntaxe ? 

Le DMARC est un enregistrement DNS de type TXT, prenant la forme suivante :

v=DMARC1; [paramètres de politique]; [paramètre de rapports]; [autres paramètres];

Les antispams interrogent la présence de cet enregistrement pour le domaine indiqué dans l'adresse émettrice (From). Ils testent alors la validité SPF et DKIM et indique si dmarc=fail ou dmarc=pass. Des exemples et les explications associées se trouvent ci-dessous.

Vous pouvez aussi retrouver tous les détails dans la norme RFC7489.

Le séparateur est le point-virgule « ; » et est obligatoire entre chaque paramètre.

• v=DMARC1; – obligatoire – au debut – définit la version du protocole. Seule valeur possible actuellement.
• p=none; – obligatoire – en deuxième position – définit la politique de traitement sur les emails non-conformes lorsque dmarc=fail. « none » n’a pas d’impact et permet donc le monitoring. « quarantine » ou « reject » sont les valeurs pour mettre en spam ou directement supprimer les emails non-conformes. 
• sp=reject; – optionnel – définit la politique de traitement pour les sous-domaines n’ayant pas une entrée DMARC spécifique. Si ce paramètre est absent, la valeur prise par défaut est celle définie dans [p=].
• rua=mailto:rua@emailsecurity.merox.io; – optionnel – recommandé – définit l’email recevant les rapports DMARC. Ces rapports RUA sont des rapports au format XML agrégés envoyés une fois toutes les 24 heures (par défaut, voir [ri=])
• ruf=mailto:exemple@domaine.fr; – optionnel – définit l’email recevant les rapports forensic. Ces rapports RUF ne sont pas toujours générés par les antispams pour des soucis de données confidentielles et RGPD. Ce sont des entêtes d’email voire des emails entiers qui peuvent arriver.
  Généré en cas de double fail du SPF et DKIM (À traiter avec d’autres options « fo= ») 
• adkim=r; – optionnel – [=r] ou [=s], relaxed ou strict, sont les deux valeurs possibles pour le test d’alignement du DKIM, r étant par défaut si non spécifié. L’alignement peut être valide si l’on a un domaine et un sous-domaine du même domaine, dans ce cas, c’est du relaxed. Si l’on souhaite durcir l’alignement, strict exigera une correspondante parfaite.
• aspf=r; – optionnel – [=r] ou [=s], relaxed ou strict, sont les deux valeurs possibles pour le test d’alignement du SPF, [=r] étant par défaut si non spécifié. L’alignement peut être valide si l’on a un domaine et un sous-domaine du même domaine, dans ce cas, c’est du relaxed. Si l’on souhaite durcir l’alignement, strict exigera une correspondante parfaite. 

D’autres paramètres existent, il est recommandé de ne pas les utiliser et de laisser leur valeur par défaut pour gagner en lisibilité pour les antispams et les humains :

• ri=86400; – optionnel – spécifie le temps entre deux rapports agrégés envoyés. La valeur par défaut est 24 heures exprimée en secondes (86400). Cependant la plupart des antispams ne traitent pas ce paramètre.
• rf=afrf; – optionnel – spécifie le format des rapports forensic. Actuellement, "afrf" est la seule valeur valide, donc inutile de la spécifier.
• fo=0; – optionnel – spécifie les cas où des rapports forensic sont envoyés. La valeur par défaut est 0.
  • o : un RUF est généré si DKIM et SPF sont en échec
  • 1 : pour générer un rapport avec DKIM ou SPF en échec
  • d : pour générer un rapport en cas d’échec DKIM
  • s : si SPF est en échec
  • il est possible de cumuler les informations, par exemple: "fo=1:d"

Les RUA au format XML peuvent être interprétés par une plateforme comme Merox, voici des explications sur le contenu reçu.

les RUF ne sont à utiliser qu’en cas de maîtrise de l’écosystème de messagerie et avec une bonne gestion sécurité sur l’accès à ces informations. Voici davantage d'informations sur les RUF.

Des obligations et recommandations sont à respecter sous peine de voir son enregistrement DMARC ignoré (impact délivrabilité, réduction de visibilité, protection ignorée)

Obligations

• Dans "v=DMARC1; p=..." "DMARC" doit être en majuscule
• "mailto:" à mettre après "rua=" et avant l'adresse email de collecte
• Vous pouvez n’avoir qu’un seul enregistrement DMARC par domaine (ou sous-domaine)
• publier l'enregistrement avec le nom "_dmarc" et non à la racine d'un nom de domaine

Recommandations

• tous les caractères en minuscule hormis "DMARC"
• L’enregistrement ne doit pas dépasser 255 caractères (comme chaque enregistrement DNS) idéalement
• Les adresses emails pour la récupération des RUA ou RUF est limitée à 2. Les adresses doivent être séparées par une virgule [,]  

par exemple:
 _dmarc IN TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:exemple@emailsecurity.merox.io,exemple@gmail.com;"