DMARC
DMARC, sigle de l'anglais Domain-based message authentication, reporting and conformance, est une spécification technique créée par un groupe d'organisations qui souhaite aider à réduire l'usage abusif des courriels, tels que le spam, l'hameçonnage, en proposant une solution de déploiement et de surveillance des problèmes liés à leur authentification[1].
Cette technologie a été normalisée par l'Internet Engineering Task Force (IETF) dans la RFC 7489.
Principe
DMARC standardise la façon dont les destinataires (au sens des MTA destinataires) réalisent l'authentification des courriels en utilisant les mécanismes de Sender Policy Framework et de DomainKeys Identified Mail. Cela signifie que l'expéditeur (au sens d'un MTA expéditeur) recevra les résultats de l'authentification de ses messages par tout destinataire qui implémente DMARC (AOL, Gmail, Outlook, Yahoo!, etc.).
Une politique DMARC autorise l'expéditeur à indiquer que ses courriels sont protégés par SPF et/ou DKIM et indique au destinataire ce qu'il doit faire si ces méthodes d'authentification échouent (ex. : rejeter tous les courriels sans DKIM et prévenir une adresse électronique). DMARC supprime les conjectures que le destinataire doit faire à propos de la façon de gérer ces messages en échec, limitant ou supprimant l'exposition de l'utilisateur aux messages potentiellement frauduleux ou dangereux. DMARC fournit également un moyen pour les destinataires de rendre compte à l'émetteur du message qu'il a réussi ou échoué l'évaluation DMARC.
DMARC est conçu pour s'intégrer dans le processus d'authentification des courriels entrants d'une organisation. La façon dont il fonctionne permet d'aider les destinataires à déterminer si le message est conforme à ce qu'il connait de l'expéditeur. Si ce n'est pas le cas, DMARC inclut des explications sur la façon de traiter les messages non conformes. DMARC ne détermine pas directement si un message est frauduleux ou non. DMARC nécessite que le message ait satisfait aux validations SPF et/ou DKIM et que les noms de domaines correspondent. Avec DMARC, un message peut donc échouer s'il passe les validations SPF et DKIM, mais que les domaines ne correspondent pas[2].
Les politiques DMARC sont publiées dans le DNS public du domaine comme enregistrement TXT et annoncent ce que le destinataire d'un courriel doit faire si ce dernier ne satisfait pas les mécaniques d'authentification SPF et/ou DKIM.
Spécifications
Correspondance des noms de domaine
DMARC va vérifier la cohérence (en mode strict et/ou relax) des trois noms de domaines suivants :
- Le nom de domaine pour DMARC est celui du champ From: du courriel (après @).
- Le nom de domaine pour DKIM est celui déclaré dans la signature (champ d=).
- Le nom de domaine pour SPF est celui de la commande MAIL FROM du SMTP.
Domaines organisationnels
Le protocole DMARC repose sur la constitution d'une liste des suffixes publics (exemple https://publicsuffix.org/), afin d'identifier le domaine organisationnel (Organizational Domain).
Par exemple si le FQDN est a.b.c.exemple.co.uk, le suffixe public est co.uk, donc le domaine organisationnel est exemple.co.uk.
Recherche d'un enregistrement DMARC
La recherche d'un enregistrement DMARC est d'abord effectuée sur le FQDN, puis sur le domaine organisationnel (si le FQDN n'est pas déjà un domaine organisationnel).
Par exemple, si l'expéditeur (champ From: du courriel) est exemple@a.news.example.org :
- On cherche un enregistrement TXT pour _dmarc.a.news.example.org (la valeur du paramètre p sera utilisée).
- À défaut, on cherche un enregistrement TXT pour _dmarc.example.org (la valeur du paramètre sp sera utilisée).
- Les niveaux intermédiaires sont toujours ignorés (ici : _dmarc.news.example.org)
Paramètres
| Paramètre | Description[3],[4] |
|---|---|
| v | [Obligatoire :] Version du protocole, qui doit avoir pour valeur DMARC1 et être le premier paramètre. (Autrement dit, l'enregistrement TXT doit commencer par « v=DMARC1; ».) |
| pct | Pourcentage de messages à filtrer (nombre entier entre 0 et 100), 100 par défaut. |
| adkim | Mode de cohérence des noms de domaine pour DKIM :
|
| aspf | Mode de cohérence des noms de domaine pour SPF (s ou r). |
| p | [Obligatoire :] Procédure en cas d'échec avec le domaine principal :
|
| sp | Procédure en cas d'échec avec un sous-domaine (none, quarantine ou reject). Si le paramètre sp est absent, la valeur de p est utilisée comme substitut. Ce paramètre sera inutilisé sur un sous-domaine, donc il doit toujours être sur un domaine organisationnel. |
| ruf | Destinataires des rapports d'échecs détaillés. |
| fo | Conditions pour l'envoi d'un rapport détaillé :
|
| rua | Destinataires des rapports agrégés. Une taille limite peut être indiquée (en k, m, g ou t) sous la forme. |
Exemple :
_dmarc.example.org 3600 IN TXT "v=DMARC1;pct=42;adkim=s;aspf=s;p=quarantine;sp=none;ruf=mailto:forensik@example.org;fo=1;rua=mailto:postmaster@example.org!50m"
Contributeurs fondateurs
Les contributeurs fondateurs de DMARC étaient notamment[5] :
- Destinataires[6] : AOL, Comcast, GMail, Hotmail[7],[8], Netease, Yahoo! Mail
- Émetteurs : (en) American Greetings, Bank of America, Facebook, Fidelity Investments, JPMorgan Chase & Company, LinkedIn, PayPal
- Commanditaires : DMARC.org, DMARC.fr
Références
- Butcher, Mike. DMARC Promises A World Of Less Phishing. Tech Crunch. Jan 30, 2012
- Kucherawy, Murray. The Current DMARC draft specification. DMARC.org. Mar 30, 2012
- (en) « HOWTO - Define a DMARC Record », sur zytrax.com (consulté le ).
- (en) RFC 7489, section 6.3. : General Record Format
- Voir (en) https://dmarc.org/about/history/, ainsi que (en) RFC 7489, page 73 : Acknowledgements
- (en) « Participate – dmarc.org », sur dmarc.org (consulté le ).
- « Page d’accueil - Microsoft 365 Blog », sur Microsoft 365 Blog (consulté le ).
- Vincent Hermann, « Microsoft communique abondamment sur Outlook.com en ce moment pour annoncer des améliorations. Après... », sur pcinpact.com, Next INpact, (consulté le ).
