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 qui échoueraient aux tests SPF et DKIM. Cela permet d'éviter le spoofing et le phishing qui serait fait avec notre domaine. Google, Yahoo!, Hotmail, etc… peut envoyer 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.
On assure donc une meilleure délivrabilité de ses emails et on limite leur passage dans le spam.
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 ”;”.
- Type : TXT
- Hôte : @
- Valeur :
v=DMARC1; pct=100; p=none; sp=reject; rua=mailto:postmaster@mondomaine.com; ruf=mailto:postmaster@mondomaine.com; fo:1; aspf=r; adkim=r
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 |
En pratique
v=DMARC1; pct=10; 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 car peu restrictif, seuls 10% des emails sont testés, ceux provenant des sous-domaines et ne passant pas les tests sont rejetés.
On consulte les rapports quotidiennement et on augmente le % de tests, puis on passe sur p=quarantine.
Une fois tous les problèmes réglés, on peut transformer cet enregistrement en :
v=DMARC1; pct=100; p=reject; sp=reject; rua=mailto:postmaster@mondomaine.com; ruf=mailto:postmaster@mondomaine.com; fo:1; aspf=s; adkim=s
Beaucoup plus strict et montrant aux MTAs qu'on se soucie d'une sécurité maximale, toute en conservant des rapports ; à condition de les étudier régulièrement sinon aucun intérêt de demander à les recevoir.
Rapports
Si les variables rua et/ou ruf sont renseignées, on recevra le rapport quotidien de certains MTAs comme Google, Yahoo!, Outlook… (tous ne le font pas). On ne reçoit le rapport que si on a envoyé un email vers ce MTA. Un rapport sur rua (agregated) pour le rapport agrégé, même si tout va bien, un rapport sur ruf (forensic) 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).
En cas de problèmes, comme un spammeur qui voudrait se faire passer pour expe@mondomaine.com, on aurait des informations dans le rapport forensic (ruf) telles que :
<row> <source_ip>203.0.113.45</source_ip> <count>1</count> <policy_evaluated> <disposition>reject</disposition> <dkim>fail</dkim> <spf>fail</spf> </policy_evaluated> </row>
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.