Qu’est-ce que DMARC ?
DMARC (Domain-based Message Authentication, Reporting & Conformance) est un protocole d’authentification des e-mails qui vérifie si un domaine authentifié par SPF ou DKIM est aligné sur le domaine indiqué dans l’adresse From d’un message. Le propriétaire d’un domaine peut publier une préférence de traitement à appliquer aux messages qui échouent à la validation DMARC et demander des rapports agrégés ou des rapports d’échec propres à chaque message.
Pourquoi DMARC est essentiel
SPF et DKIM authentifient les identifiants d’envoi. À eux seuls, ils ne vérifient pas si un identifiant authentifié est aligné sur le domaine indiqué dans l’adresse From et n’indiquent pas la préférence de traitement du propriétaire du domaine pour les messages qui échouent.
DMARC résout ce problème en :
- Indiquant une préférence de traitement : none, quarantine ou reject pour les messages qui échouent à DMARC
- Vérifiant l’alignement : au moins un identifiant SPF ou DKIM authentifié doit être aligné sur le domaine From
- Demandant des rapports : les rapports agrégés et les rapports d’échec propres à chaque message donnent un aperçu des résultats d’authentification observés
Comment fonctionne DMARC
1. L’expéditeur publie la politique DMARC dans le DNS (enregistrement TXT à _dmarc.domain.com)
2. L’e-mail est envoyé avec From: [email protected]
3. Le destinataire vérifie SPF et DKIM
4. Le destinataire vérifie l’alignement : le domaine authentifié correspond-il à l’en-tête From ?
5. Décision de traitement : le destinataire prend en compte la politique demandée et d’autres signaux
6. Des rapports peuvent être envoyés : les destinataires participants peuvent envoyer les rapports agrégés ou les rapports d’échec propres à chaque message demandés
Alignement DMARC
DMARC exige un alignement : le domaine de l’en-tête From doit être aligné sur au moins un identifiant authentifié selon le mode relâché ou strict de l’enregistrement :
- Alignement SPF : le domaine MAIL FROM validé par SPF, ou le domaine HELO lorsque MAIL FROM est nul
- Alignement DKIM : le domaine indiqué par d= dans une signature DKIM valide
Sans alignement, SPF ou DKIM peuvent réussir alors que DMARC échoue. DMARC s’attaque directement à certaines formes d’usurpation qui utilisent exactement le domaine From. Il ne détecte pas les domaines visuellement similaires ni l’utilisation abusive du nom d’affichage de l’expéditeur.
Format de l’enregistrement DMARC
Les enregistrements DMARC sont des enregistrements TXT à _dmarc.yourdomain.com :
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Balises DMARC
| Balise | Obligatoire | Description | Exemple |
|---|---|---|---|
| v | Oui | Version | v=DMARC1 |
| p | Recommandée (facultative) | Préférence de traitement demandée pour les e-mails qui échouent à la validation DMARC | p=none/quarantine/reject |
| rua | Non | URI du rapport agrégé | rua=mailto:[email protected] |
| ruf | Non | URI du rapport d’échec propre à chaque message | ruf=mailto:[email protected] |
| t | Non | Mode de test de la politique | t=y ou t=n |
| sp | Non | Politique demandée pour les sous-domaines existants | sp=reject |
| np | Non | Politique demandée pour les sous-domaines inexistants | np=reject |
| adkim | Non | Mode d’alignement DKIM | adkim=s (strict) ou adkim=r (relaxed) |
| aspf | Non | Mode d’alignement SPF | aspf=s ou aspf=r |
La balise pct est obsolète. La norme DMARC actuelle ne l’utilise plus pour appliquer une politique à un pourcentage de messages en échec. La balise p est recommandée mais facultative ; un enregistrement par ailleurs valide qui ne la contient pas est traité comme p=none.
Politiques DMARC
p=none : N’exprime aucune préférence de traitement pour les messages qui échouent. Les propriétaires de domaine l’utilisent souvent lors de l’examen des rapports.v=DMARC1; p=none; rua=mailto:[email protected]v=DMARC1; p=quarantine; rua=mailto:[email protected]v=DMARC1; p=reject; rua=mailto:[email protected]Méthode de mise en œuvre de DMARC
Phase 1 : Surveillance (p=none)
Commencez par la surveillance pour comprendre votre écosystème d’e-mails :
v=DMARC1; p=none; rua=mailto:[email protected]Analysez les rapports pour identifier :
- Services d’envoi légitimes sans SPF/DKIM
- Expéditeurs non autorisés (usurpation)
- Problèmes d’alignement
Phase 2 : Mise en quarantaine (p=quarantine)
Une fois les sources légitimes authentifiées :
v=DMARC1; p=quarantine; rua=mailto:[email protected]Examinez les rapports et confirmez que les e-mails légitimes sont authentifiés avant de choisir une politique plus stricte. La norme DMARC actuelle ne définit pas de déploiement progressif par pourcentage.
Phase 3 : Rejet (p=reject)
Demandez le rejet des messages qui échouent à DMARC :
v=DMARC1; p=reject; rua=mailto:[email protected]Rapports DMARC
Rapports agrégés (rua)
Il est recommandé que les destinataires envoient des rapports XML agrégés chaque jour ou plus fréquemment. Les rapports résument les flux de messages observés ; leur disponibilité et leur couverture dépendent donc des destinataires qui les envoient :
- Volume d’e-mails
- Taux de réussite/échec pour SPF, DKIM, DMARC
- Adresses IP d’envoi
- Organisations destinataires
Rapports d’échec (ruf)
Les rapports propres à chaque message peuvent inclure les en-têtes ou le contenu du message. Tous les destinataires ne les envoient pas, souvent pour des raisons de confidentialité :
- Détails de l’échec d’authentification
Traitement des rapports
Les rapports DMARC agrégés sont au format XML et peuvent être difficiles à lire. Utilisez des services tels que :
- DMARC Analyzer
- Dmarcian
- Valimail
- Postmark DMARC
Vérifier DMARC
L’API d’authentification des e-mails de DomScan, qui nécessite une authentification, coûte 3 crédits par domaine et renvoie l’enregistrement DMARC ainsi que les balises analysées.
dig _dmarc.example.com TXTcurl -H "X-API-Key: $DOMSCAN_API_KEY" "https://domscan.net/v1/email-auth?domain=example.com"
# Check dmarc.record and dmarc.tags in the JSON response
Problèmes DMARC courants
Aucun rapport reçu : Vérifiez que l’adresse rua peut recevoir des e-mails volumineux ; certains fournisseurs les filtrent. Échec de validation d’e-mails légitimes : Vérifiez la configuration SPF/DKIM de tous les services d’envoi ; vérifiez l’alignement. Échec des services tiers : De nombreux services exigent une configuration DKIM personnalisée pour l’alignement DMARC.DMARC ajoute l’alignement, une préférence de traitement demandée et des rapports à SPF et DKIM. Examinez vos sources d’envoi et vos rapports avant de demander un traitement plus strict.