← RFC Reference

DMARC — Authentification des Messages Basée sur le Domaine, Rapports et Conformité

Pourquoi cet RFC existe

SPF et DKIM sont puissants, mais chacun a une lacune critique. SPF valide le domaine de l'expéditeur d'enveloppe, que les utilisateurs ne voient jamais. DKIM valide n'importe quel domaine que le signataire a choisi, qui peut être le domaine d'un ESP plutôt que l'expéditeur visible. Aucun des deux, seul, n'empêche un attaquant d'usurper l'en-tête From: que les utilisateurs lisent réellement.

DMARC ferme cette lacune en introduisant deux concepts :

1. Alignement d'identifiant : Au moins un des SPF ou DKIM doit à la fois réussir et avoir son domaine authentifié aligné avec le domaine de l'en-tête From:.
2. Politique du propriétaire de domaine : Le propriétaire du domaine publie un enregistrement DNS déclarant ce que les récepteurs doivent faire quand l'alignement échoue : surveiller (p=none), mettre en quarantaine (p=quarantine), ou rejeter (p=reject).

DMARC définit également un mécanisme de rapports agrégés, permettant aux propriétaires de domaines de recevoir des rapports XML quotidiens montrant comment leur domaine est utilisé (et abusé) sur Internet.

Comment ça fonctionne

Le flux d'évaluation DMARC

1. Un message arrive avec From: user@example.com.
2. Le récepteur vérifie SPF contre le domaine de l'expéditeur d'enveloppe. Si SPF réussit et le domaine d'enveloppe correspond à example.com (ou un sous-domaine, selon le mode d'alignement), SPF est « aligné ».
3. Le récepteur vérifie DKIM. Si une signature valide a d=example.com (ou un sous-domaine), DKIM est « aligné ».
4. Si au moins un des SPF ou DKIM réussit et est aligné, DMARC réussit.
5. Si DMARC échoue, le récepteur interroge _dmarc.example.com pour la politique et l'applique.

Enregistrement DNS DMARC

Alignement en pratique

Détails techniques clés

Étiquettes de politique

Modes d'alignement

Alignement relaxé (par défaut, adkim=r / aspf=r) : Le domaine authentifié et le domaine From: partagent le même domaine d'organisation. Par exemple, mail.example.com s'aligne avec example.com.

Alignement strict (adkim=s / aspf=s) : Le domaine authentifié doit correspondre exactement au domaine From:. mail.example.com ne s'aligne pas avec example.com.

Rapports agrégés (rua)

Les récepteurs qui prennent en charge DMARC envoient des rapports agrégés quotidiens au format XML à l'adresse rua. Ces rapports contiennent :

• Les adresses IP d'envoi qui ont utilisé votre domaine
• Les résultats de réussite/défaillance SPF et DKIM pour chaque source
• La politique DMARC appliquée et la disposition (aucune, quarantaine, rejet)
• Les décomptes de messages par adresse IP source

Ces rapports sont inestimables pour découvrir les expéditeurs non autorisés, identifier les sources légitimes mal configurées, et renforcer la confiance avant de renforcer votre politique de none à reject.

Vérification de destination externe

Si votre adresse rua ou ruf se trouve dans un domaine différent (p. ex., rua=mailto:reports@analytics.com), le domaine récepteur doit publier un enregistrement DNS l'autorisant :

Sans cet enregistrement, les expéditeurs de rapports ne livreront pas les rapports à l'adresse externe, en tant que protection contre l'utilisation des rapports DMARC comme vecteur de déni de service.

Erreurs courantes

• Passer directement à p=reject : Déployer une politique de rejet sans d'abord surveiller avec p=none peut silencieusement bloquer les courriers légitimes de sources oubliées (plateformes marketing, systèmes CRM, applications SaaS envoyant en votre nom). Commencez toujours par p=none, analysez les rapports, corrigez les problèmes d'alignement, puis augmentez.
• Oublier la politique de sous-domaine : Sans sp=, les sous-domaines héritent de la politique du domaine. Si vous définissez p=reject mais avez un sous-domaine envoyant du courrier sans authentification appropriée, ces messages seront rejetés. Utilisez sp= pour contrôler la politique de sous-domaine indépendamment.
• Ne pas configurer rua : DMARC sans rapports agrégés, c'est voler à l'aveugle. Les rapports vous indiquent qui envoie du courrier en tant que votre domaine et si l'authentification fonctionne. Configurez toujours rua.
• Malentendu sur l'alignement : Une erreur courante est de penser que faire passer SPF et DKIM suffit. Ils doivent aussi s'aligner avec le domaine d'en-tête From:. Si votre ESP utilise bounce@esp.com comme expéditeur d'enveloppe et signe DKIM comme d=esp.com, aucun des deux ne s'aligne avec votre en-tête From:, et DMARC échoue.
• Utiliser pct=0 comme « surveillance uniquement » : Bien que pct=0 signifie techniquement « appliquer la politique à 0% des défaillances », certains récepteurs l'interprètent différemment. Utilisez p=none pour la surveillance, pas pct=0 avec une politique plus stricte.
• Cassure de liste de diffusion : Les listes de diffusion traditionnelles réécrivent l'expéditeur d'enveloppe mais préservent l'en-tête From:, brisant l'alignement SPF et parfois DKIM (si la liste modifie le message). C'est un problème connu ; ARC a été créé pour l'adresser.

Impact de livrabilité

• Obligatoire pour les expéditeurs en masse : Depuis février 2024, Gmail exige que les domaines envoyant 5 000+ messages par jour aient une politique DMARC (au minimum p=none). Yahoo a des exigences similaires. Cela rend DMARC non facultatif pour tout expéditeur sérieux.
• Protection de marque : Une politique p=reject empêche les attaquants d'usurper votre domaine dans les campagnes de phishing. Cela protège vos clients et la réputation de votre domaine.
• Amélioration du placement dans la boîte de réception : Les domaines ayant des politiques DMARC fortes (quarantaine ou rejet) démontrent une maturité d'authentification. De nombreux récepteurs en tiennent compte dans la notation de réputation.
• Éligibilité BIMI : Les indicateurs de marque pour l'identification des messages (BIMI) exigent une politique DMARC de p=quarantine ou p=reject. BIMI affiche le logo de votre marque à côté des messages dans les clients de messagerie compatibles.
• Visibilité dans votre écosystème de messagerie : Les rapports agrégés révèlent chaque IP envoyant du courrier en tant que votre domaine. Cette visibilité seule rend DMARC utile à déployer, même à p=none.

Related RFCs