Interrogez et validez l’enregistrement TXT DMARC publié à _dmarc.<domain>, puis lisez votre politique, votre alignement et vos balises de reporting en clair. L’outil est gratuit, instantané, s’exécute entièrement dans votre navigateur, sans inscription et sans conserver de données.
Créez un compte Unspam gratuit pour enregistrer vos résultats et relancer ces vérifications à tout moment, afin de repérer une configuration défaillante avant qu’elle ne vous coûte cher. Sans carte bancaire.
DMARC (Domain-based Message Authentication, Reporting and Conformance) est un enregistrement TXT publié dans le DNS à _dmarc.votredomaine.com. Il indique aux serveurs de réception quoi faire lorsqu’un message se présentant comme venant de votre domaine échoue à l’alignement SPF et DKIM, et où envoyer les rapports sur ces contrôles. DMARC s’appuie sur SPF et DKIM : un message valide DMARC dès que l’un des deux réussit et que le domaine authentifié s’aligne avec celui de l’en-tête From visible. Sans DMARC, un attaquant peut usurper votre domaine exact dans l’adresse From, et vous n’avez aucune visibilité sur qui envoie des messages en votre nom. Gmail, Yahoo, Outlook.com et Apple exigent des gros expéditeurs la publication d’un enregistrement DMARC : un enregistrement valide relève désormais de la délivrabilité de base, et plus seulement de la sécurité.
La balise de version. Elle doit valoir exactement v=DMARC1 et venir en premier, sans quoi les serveurs de réception ignorent tout l’enregistrement. C’est elle qui désigne l’enregistrement TXT comme une politique DMARC plutôt qu’une chaîne sans rapport.
La politique appliquée à votre domaine principal. p=none se contente d’observer et de collecter des rapports, p=quarantine envoie les messages en échec vers le dossier spam, et p=reject les bloque purement et simplement. Google et Yahoo exigent au moins p=none des gros expéditeurs, mais reject offre la meilleure protection contre l’usurpation.
sp= définit une politique distincte pour les sous-domaines (à défaut, elle hérite de p=), et pct= n’applique la politique qu’à un pourcentage des messages, pour un déploiement progressif. Notez que pct a été retiré de la dernière spécification DMARC (RFC 9989, publiée en 2026), qui la remplace par une balise t plus simple pour le mode test : les recommandations récentes privilégient donc un passage direct à l’application complète.
rua= est la boîte (par exemple mailto:dmarc@votredomaine.com) qui reçoit les rapports agrégés quotidiens recensant toutes les sources émettant au nom de votre domaine. ruf= reçoit les rapports d’échec message par message. Les rapports agrégés sont ce qui vous permet de passer sans risque de p=none à l’application.
Ces balises fixent la rigueur de l’alignement pour SPF et DKIM. La valeur par défaut r (souple) autorise les sous-domaines de votre domaine d’organisation à s’aligner, tandis que s (strict) impose une correspondance exacte. Le mode souple est le bon réglage par défaut pour la plupart des expéditeurs qui recourent à des sous-domaines ou à des services tiers.
La requête ne renvoie rien à _dmarc.votredomaine.com et aucun domaine parent ne couvre ce nom : les serveurs de réception n’appliquent donc aucune politique et votre domaine peut être usurpé librement. Publiez à cet emplacement un enregistrement TXT commençant par v=DMARC1; p=none; rua=mailto:vous@votredomaine.com pour commencer à observer sans risque pour vos envois.
p=none se contente d’observer et ne bloque jamais les messages usurpés, et pourtant beaucoup de domaines y restent des années. Servez-vous des rapports agrégés envoyés à votre adresse rua= pour confirmer que vos expéditeurs légitimes passent, puis passez à p=quarantine et enfin à p=reject pour une véritable protection.
Sans boîte de reporting rua=, vous ne voyez pas qui envoie au nom de votre domaine, ce qui rend l’application risquée. Ajoutez un rua=mailto: pointant vers une boîte ou un service de traitement des rapports DMARC que vous consultez réellement, avant de durcir la politique.
Publier deux enregistrements TXT à _dmarc, ou placer v= ailleurs qu’en première position, rend l’enregistrement invalide et les serveurs de réception l’ignorent. Conservez un enregistrement unique, commencez-le par v=DMARC1 et séparez chaque balise par un point-virgule.
SPF ou DKIM peuvent réussir alors que le domaine authentifié ne correspond pas à votre domaine From : DMARC échoue malgré tout. Vérifiez que SPF utilise bien votre propre domaine de Return-Path, ou que DKIM signe avec un d= correspondant à votre domaine From, et contrôlez aspf/adkim si vous vous appuyez sur des sous-domaines.
Sans sp=, chaque sous-domaine hérite de votre politique principale. Publier sp=none pour débloquer un expéditeur hérité laisse tous les sous-domaines inutilisés ouverts à l’usurpation, et c’est précisément par là qu’un attaquant commence.
Toutes les dates et tous les chiffres qu’Unspam publie sur les exigences applicables aux expéditeurs sont regroupés ici et vérifiés dans la documentation de chaque fournisseur. Dernière lecture : 16 août 2026.
| Fournisseur | Quoi | Valeur | S’applique à |
|---|---|---|---|
| Règles pour expéditeurs en masse en vigueur depuis source | février 2024 obligatoire | e-mails vers des adresses Gmail personnelles | |
| Durcissement de l’application depuis source | novembre 2025 observé Google parle d’un processus graduel et progressif, pas d’un interrupteur basculé à une date donnée. | e-mails vers des adresses Gmail personnelles | |
| Considéré comme expéditeur en masse à partir de source | 5 000 obligatoire C’est le chiffre de Google. Yahoo refuse d’en publier un. | e-mails vers des adresses Gmail personnelles | |
| Plafond du taux de plaintes pour spam source | 0,3 % obligatoire Google décrit l’effet comme progressif et non comme un seuil couperet : au-dessus du chiffre recommandé le placement en boîte de réception souffre déjà, et au plafond il souffre davantage. | tous les expéditeurs vers Gmail, pas seulement en masse | |
| Taux de plaintes pour spam à viser source | 0,1 % recommandé Postmaster Tools ne divise pas les plaintes par tout ce que vous avez envoyé. Il les rapporte aux messages signés DKIM parvenus dans la boîte de réception d’un destinataire actif, un expéditeur déjà filtré peut donc voir un taux artificiellement bas. | tous les expéditeurs vers Gmail, pas seulement en masse | |
| Yahoo | Règles pour expéditeurs en masse en vigueur depuis source | février 2024 obligatoire | e-mails vers Yahoo, AOL et les autres boîtes de Yahoo |
| Considéré comme expéditeur en masse à partir de source | non publié Yahoo déclare qu’il ne précisera pas de seuil de volume, aucun chiffre ne peut donc lui être attribué. | e-mails vers Yahoo, AOL et les autres boîtes de Yahoo | |
| Plafond du taux de plaintes pour spam source | 0,3 % obligatoire | e-mails vers Yahoo, AOL et les autres boîtes de Yahoo | |
| Outlook.com | Règles pour expéditeurs en masse en vigueur depuis source | mai 2025 obligatoire | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 |
| Considéré comme expéditeur en masse à partir de source | 5 000 obligatoire La règle s’applique à tout domaine ayant déjà franchi le seuil, elle continue donc de s’appliquer les jours plus calmes. | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 | |
| Ce qu’il advient des e-mails en échec source | 550 5.7.515 observé Le courrier non conforme est refusé pendant la conversation SMTP au lieu d’être classé dans le dossier indésirables. La page de politiques pour postmasters de Microsoft décrit encore le dossier indésirables comme première étape, un expéditeur peut donc voir l’un ou l’autre, mais c’est le rejet qu’il faut anticiper. | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 | |
| SPF et DKIM doivent tous deux réussir, pas seulement DMARC source | obligatoire Plus strict que DMARC seul. DMARC est validé dès que SPF ou DKIM est aligné, et Outlook.com demande en plus que les deux contrôles réussissent. | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 | |
| Apple | Règles pour expéditeurs en masse en vigueur depuis source | février 2025 obligatoire | e-mails vers iCloud Mail, me.com et mac.com |
| En-têtes ARC sur les e-mails transférés source | obligatoire Apple est le seul des quatre à le demander, ce qui est la vraie raison de s’intéresser à ARC. | e-mails vers iCloud Mail, me.com et mac.com |
Unspam lit tout cela à partir de votre seul nom de domaine.
Aucune requête DNS n’y accède. Il faut un vrai message ou un vrai historique d’envoi, et c’est précisément à cela que sert un test de placement en boîte de réception.
