Ceci est une ancienne révision du document !
Table des matières
DMARC
Préambule
DMARC est un processus permettant de donner des instructions aux MTAs destinataires des emails sur la façon de traiter les emails que ne satisferaient pas aux tests SPF et DKIM. Cela permet d'éviter le spoofing et le phishing qui serait fait avec notre domaine. Google, Yahoo!, Hotmail, etc… envoient alors un rapport quotidien par email ou vers un script si une URI est renseignée.
Pour faire simple, DMARC indique au domaine d'email destinataire ce qu'il faut faire d'un email suspect venant de notre domaine.
Donner un DMARC strict indique au MTA destinataire que l'on prend soin de la qualité de ses emails et que l'on veut montrer patte blanche ; les emails venant d'un usurpateur seraient bloqués.
Installation
Il s'agit d'un enregistrement DNS, de type TXT nommé “_dmarc.mondomaine.com“.
En valeur, on écrit des instructions sous forme texte en paires “variable=valeur”, séparée par un ”;”
Exemple :
v=DMARC1; pct=100; p=none; sp=reject; rua=mailto:postmaster@mondomaine.com; ruf=mailto:postmaster@mondomaine.com; fo:1; aspf=r; adkim=r
Cet enregistrement est parfait pour commencer (on peut modifier l'enregistrement après une période test de façon à affiner le réglage DMARC) car peu restrictif, seuls les emails provenant des sous-domaines sont rejetés.
Variables
| Variable | Description | Valeurs possibles |
|---|---|---|
| v= | Version (obligatoire) | • DMARC1 |
| pct= | % de test à réaliser (facultatif) | • 20 |
• 100 |
||
| p= | Politique de traitement (obligatoire) | • none (pour les tests de départ) |
• quarantine (période de stabilisation SPF et DKIM) |
||
• reject (valeur finale) |
||
| sp= | Politique pour les sous-domaines (facultatif) | • none |
• quarantine |
||
• reject |
||
| rua= | URI de création des rapports globaux (facultatif) | • URL vers un script |
• mailto:postmaster@mondomain.com |
||
| ruf= | URI de création de rapport d'enquête (facultatif) | • URL vers un script |
• mailto:postmaster@mondomain.com |
||
| fo= | Mode de génération du rapport pour ruf | • 0 (par défaut), rapport généré si ni SPF, ni DKIM ne passe le test |
• 1, rapport généré si SPF ou DKIM ne passe pas le test (le mieux pour tester) |
||
• s, rapport généré si SPF ne passe pas le test |
||
• d, rapport généré si DKIM ne passe pas le test |
||
| aspf= | Mode de test pour le SPF (facultatif) | • r pour relaxed |
• s pour strict |
||
| adkim= | Mode de test pour le DKIM (facultatif) | • r pour relaxed |
• s pour strict |
Rapports
Si les variables rua et/ou ruf sont renseignées, on recevra le rapport quotidien des MTAs (Google, Yahoo!, Outlook) des destinataires de nos emails (on ne reçoit le rapport que si on a envoyé un email vers ce MTA). Un rapport sur rua pour le rapport agrégé (même si tout va bien), un rapport sur ruf si il y a des erreurs.
Ce rapport au format XML permet de savoir si les emails sont délivrés correctement. On retrouve un résumé de la politique de traitement de SPF et DKIM, et si les emails ont passés les tests (ou si certains ont été rejetés ou marqués comme spam).
Ces rapports sont essentiels, au moins durant la période de mise en place d'une politique solide (très stricte) et qui fonctionne bien.
Infos complémentaires
Il est recommandé de mettre en place dans l'ordre SPF, puis DKIM et enfin DMARC une fois qu'on s'est assuré que les deux premiers sont opérationnels. De même, on commence par une valeur aspf=r (relaxed) et adkim=r (relaxed) ; et une politique p=none, puis p=quarantine et enfin p=reject une fois le processus bien compris.