Lancer une vérification DMARC récupère l'enregistrement TXT _dmarc de votre domaine et détaille ce qu'il indique aux destinataires de faire. Voici comment lire ce résultat et agir sur les parties les plus importantes.
Comment lire les résultats de votre vérification DMARC
Le vérificateur rapporte quatre choses : l'existence d'un enregistrement v=DMARC1 valide, la politique d'application (p=), le mode d'alignement pour SPF et DKIM, et où les rapports sont envoyés (rua/ruf). Un résultat sain comporte un seul enregistrement, une politique plus forte que none, et au moins une adresse de rapport agrégé pour que vous ayez de la visibilité sur qui envoie au nom de votre domaine.
Les trois politiques DMARC : none, quarantine, reject
p=none- surveillance uniquement. Le courrier en échec est tout de même remis ; vous collectez seulement des rapports. C'est le point de départ, pas la destination.p=quarantine- le courrier en échec est envoyé vers les spams/indésirables. La première véritable étape d'application.p=reject- le courrier en échec est purement bloqué. C'est l'objectif, et ce qui arrête l'usurpation de domaine.
Le bon déploiement est none → quarantine → reject, en montant d'un cran uniquement lorsque vos rapports montrent que chaque expéditeur légitime réussit. Rester indéfiniment sur p=none est l'erreur DMARC la plus courante - elle n'offre aucune protection.
Alignement SPF et DKIM : pourquoi DMARC échoue même quand SPF réussit
DMARC ne vérifie pas seulement que SPF ou DKIM a réussi - il vérifie qu'ils s'alignent avec le domaine de l'adresse From visible. Un message peut réussir SPF pour le domaine propre du service d'envoi tout en échouant à DMARC parce que ce domaine ne correspond pas à votre en-tête From. Les balises aspf et adkim contrôlent la rigueur de cette correspondance : r (souple) autorise les sous-domaines, s (strict) exige une correspondance exacte ; notre guide pour comprendre l'alignement SPF explique la différence en profondeur. Lorsqu'un enregistrement SPF valide échoue tout de même à DMARC, la mauvaise correspondance en est presque toujours la cause - et un enregistrement SPF valide et aligné dépend d'abord de la justesse de votre SPF.
Erreurs de configuration DMARC courantes
- Pas d'enregistrement, ou mauvais hôte. L'enregistrement doit résider à
_dmarc.votredomaine.com, pas à l'apex. - Deux enregistrements DMARC. Un seul est autorisé ; un second les invalide tous les deux.
- Bloqué sur
p=none. Surveiller indéfiniment n'apporte aucune application. - Aucune adresse
rua. Sans rapports agrégés, vous appliquez à l'aveugle.
Rapports agrégés vs forensiques
Les rapports agrégés (rua) sont des synthèses XML quotidiennes de chaque source envoyant au nom de votre domaine et indiquant si elle a réussi - c'est là que vous trouvez les expéditeurs non autorisés et confirmez que les vôtres sont alignés. Les rapports forensiques (ruf) capturent les messages en échec individuels pour une enquête approfondie. Pour transformer le XML brut en quelque chose de lisible, notre produit frère DMARC Report l'analyse et le visualise pour vous.
DMARC, SPF et DKIM fonctionnent ensemble
DMARC est la couche de politique au-dessus de deux contrôles : SPF (le serveur d'envoi) et DKIM (une signature prouvant que le message n'a pas été altéré). Parce que l'application DMARC exige un résultat SPF réussi et aligné, maintenir votre enregistrement SPF valide et sous la limite de 10 recherches est fondamental - AutoSPF s'en charge automatiquement. Découvrez le tableau complet dans notre guide DMARC.