Outils pour utilisateurs

Outils du site


dmarc

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
dmarc [2025/08/24 20:59] sebdmarc [2025/10/16 20:01] (Version actuelle) – [En pratique] seb
Ligne 4: Ligne 4:
 ===== Préambule ===== ===== 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.+**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. 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.+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 ===== ===== Installation =====
Ligne 14: Ligne 16:
 Il s'agit d'un enregistrement DNS, de type TXT nommé **"//_dmarc.mondomaine.com//"**. 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 ";" +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;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.+
  
 +  * 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 ===== ===== Variables =====
Ligne 39: Ligne 38:
 |ruf=|URI de création de rapport d'enquête (facultatif)|• URL vers un script| |ruf=|URI de création de rapport d'enquête (facultatif)|• URL vers un script|
 |:::|:::|• ''mailto:postmaster@mondomain.com''| |:::|:::|• ''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| |aspf=|Mode de test pour le SPF (facultatif)|• ''r'' pour relaxed|
 |:::|:::|• ''s'' pour strict| |:::|:::|• ''s'' pour strict|
Ligne 44: Ligne 47:
 |:::|:::|• ''s'' pour strict| |:::|:::|• ''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'', on passe aussi sur ''spf=s'' et ''dkim=s'' si ils ne posent pas de problèmes.
 +
 +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.
 +
 +Attention, cela pose problème lors de forwarding d'email puisque l'émetteur change ; on peut mettre ''spf=r'' et ''dkim=r'' (pour Relaxed), les MTAs peuvent donc choisir quoi faire (généralement dirigé en spam).
 +===== 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 :
 +
 +<code xml>
 +<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>
 +</code>
 +
 +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 ===== ===== 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=relaxed'' et ''adkim=relaxed'' ; et une politique ''p=none'', puis ''p=quarantine'' et enfin ''p=reject'' une fois le processus bien compris.+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. 
 + 
 +===== Ressources =====
  
 +  * Conseils Gmail : [[https://support.google.com/a/answer/2466580]]
 +  * Test du DMARC : [[https://dmarcian.com/]]
 +  * Lire les rapports DMARC : [[https://us.dmarcian.com/xml-to-human-converter/]]
dmarc.1756061967.txt.gz · Dernière modification : de seb