Rémi Kokabi27 novembre 202512 min de lectureMis à jour: 12 oct. 2026
DMARC et cold email : la règle des 5 000 emails qui décide si Gmail et Outlook vous font confiance (guide de configuration 2026)
Le phishing et le spoofing étaient la cybercriminalité la plus signalée dans le rapport 2024 du FBI sur la criminalité en ligne, avec 193 407 plaintes enregistrées par l'Internet Crime Complaint Center du FBI. Voilà l'environnement dans lequel vos cold emails atterrissent : une inbox hostile où les serveurs de réception tirent d'abord et posent les questions après.
Le problème est simple. Si votre domaine peut être usurpé, les fournisseurs de messagerie ne savent pas s'ils peuvent faire confiance à vos emails. Et quand ils ne vous font pas confiance, votre prospection légitime finit en spam (ou se fait rejeter directement).
Dans ce guide, je vous montre exactement comment DMARC fonctionne, ce que chaque tag d'un enregistrement DMARC fait, comment le configurer et le valider étape par étape, et comment garder vos cold emails dans l'inbox.
Sommaire
Qu'est-ce que DMARC ?
DMARC signifie Domain-based Message Authentication, Reporting, and Conformance. Un enregistrement DMARC est un enregistrement DNS de type TXT publié à _dmarc.votredomaine.com qui permet aux serveurs de réception de vérifier qu'un email provient bien de votre domaine, en s'appuyant sur SPF et DKIM. Il leur indique aussi où envoyer les rapports sur ce qu'ils observent.
Voyez-le comme le dernier point de contrôle. SPF indique à un serveur quelles adresses IP peuvent envoyer en votre nom. DKIM ajoute une signature cryptographique qui prouve que le message n'a pas été modifié en transit. DMARC relie les deux et dit au serveur de réception quoi faire quand un email échoue à ces vérifications.
Le protocole a été défini pour la première fois par l'IETF dans le RFC 7489 (2015) et mis à jour en 2026 par le RFC 9989. Mais la logique de base reste la même : authentifier chaque message, rapporter ce qui se passe, et donner aux propriétaires de domaines le contrôle sur le traitement des échecs.
Sans DMARC, un acteur malveillant peut envoyer des emails en se faisant passer pour vous, et les serveurs de réception n'ont aucune instruction pour les traiter. Avec DMARC, vous dites aux fournisseurs de messagerie exactement comment gérer ces usurpations.
Pourquoi DMARC compte pour le cold email
Soyons directs : DMARC est désormais un prérequis pour envoyer de la prospection à grande échelle.
Depuis février 2024, Google exige une politique DMARC pour les expéditeurs de 5 000 messages ou plus par jour vers des comptes Gmail personnels. Cela concerne Gmail personnel, pas les domaines Google Workspace, mais les comptes Gmail personnels représentent une part significative de toute liste de cold email. Yahoo exige des gros expéditeurs qu'ils publient une politique DMARC d'au moins p=none. À partir du 5 mai 2025, Microsoft envoie dans le dossier spam les emails des expéditeurs de 5 000 messages ou plus par jour vers Outlook.com qui échouent SPF, DKIM ou DMARC. Le rejet pur et simple est prévu dans une phase ultérieure. Cela concerne Outlook.com grand public, pas Exchange Online.
Le seuil de 5 000 messages semble élevé. Ça ne l'est pas. Si vous lancez des campagnes multicanales sur plusieurs domaines et boîtes d'envoi, vous pouvez atteindre ce chiffre plus vite que prévu. Et même en dessous du seuil, l'absence de DMARC signale aux fournisseurs de messagerie que vous ne prenez pas l'authentification au sérieux. Ça plombe votre réputation d'expéditeur sur la durée.
Oui, vous pouvez faire de l'outbound sans DMARC. Mais vous jouez votre délivrabilité à chaque envoi.
Les enjeux vont au-delà du placement en inbox. La compromission d'emails professionnels a généré 2,77 milliards de dollars de pertes déclarées aux États-Unis en 2024, selon le même rapport du FBI. Quand des attaquants usurpent votre domaine pour hameçonner vos prospects ou partenaires, c'est votre marque qui prend le coup.
DMARC protège la réputation de votre domaine. Il indique aux fournisseurs de messagerie que vous avez verrouillé votre authentification email. Et il vous donne de la visibilité sur qui envoie des emails en votre nom, légitimement ou non.
Comment fonctionne DMARC
Quand un message arrive sur un serveur de réception, le serveur vérifie deux choses : est-ce que l'IP d'envoi correspond à l'enregistrement SPF de ce domaine ? Est-ce que la signature DKIM est valide ?
DMARC ajoute une troisième couche. Un message passe DMARC quand SPF ou DKIM passe et que le domaine validé correspond au domaine affiché dans l'en-tête From. Cette correspondance s'appelle l'alignement, et c'est la pièce que SPF et DKIM ne peuvent pas imposer seuls. Si l'authentification échoue ou n'est pas alignée, la politique DMARC décide de la suite.
Voici à quoi ressemble un enregistrement DMARC basique :
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Décortiquons ces tags :
v est la version. Toujours DMARC1, et il doit apparaître en premier dans l'enregistrement.
p est la politique. Elle dit aux serveurs de réception quoi faire des messages qui échouent à l'authentification. Trois options : none (monitoring uniquement, livraison quand même), quarantine (envoi en spam), ou reject (blocage complet).
rua est l'adresse de reporting. Les serveurs de réception envoient des rapports agrégés ici pour que vous puissiez voir qui envoie des emails depuis votre domaine. C'est techniquement optionnel, mais sans ça vous n'avez aucune visibilité.
Seuls v et p sont obligatoires. Voici à quoi ressemble un enregistrement complet :
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensics@example.com; adkim=r; aspf=r; fo=1
Vous pouvez ajouter d'autres tags pour affiner le comportement :
Tag | Ce qu'il fait |
|---|---|
ruf | Adresse pour les rapports forensiques (d'échec) avec les détails sur les messages individuels qui ont échoué. Google et Microsoft n'en envoient quasiment pas. |
fo | Quand générer les rapports forensiques : 0 (SPF et DKIM échouent tous les deux, par défaut), 1 (l'un ou l'autre échoue), d (DKIM échoue), s (SPF échoue). Pertinent uniquement si ruf est défini. |
aspf | Mode d'alignement pour SPF : r (relaxed, par défaut, autorise une correspondance de sous-domaine) ou s (strict, correspondance exacte) |
adkim | Mode d'alignement pour DKIM : r (relaxed, par défaut) ou s (strict) |
sp | Politique pour les sous-domaines (hérite de p si non défini) |
np | Nouveau dans le RFC 9989 : politique pour les sous-domaines qui n'existent pas dans le DNS |
pct | Pourcentage de messages en échec auxquels appliquer la politique. Supprimé par le RFC 9989 : les enregistrements existants fonctionnent encore, mais ne l'incluez plus dans les nouveaux. |
Note sur le RFC 9989 : le standard DMARC mis à jour, publié en 2026, supprime les tags pct, rf et ri. Les enregistrements qui les utilisent déjà continuent de fonctionner, mais les nouveaux enregistrements doivent s'en passer. Il ajoute np pour les sous-domaines inexistants, et un tag t qui demande aux serveurs d'appliquer la politique inférieure pendant vos tests, ce qui couvre l'essentiel de ce que pct faisait.
La plupart des expéditeurs commencent avec v, p et rua. Ajoutez les autres au fur et à mesure que votre monitoring se précise.
Comparaison des politiques DMARC : none vs. quarantine vs. reject
Le tag p= est la seule décision qui change réellement ce qui arrive à vos emails.
Politique | Ce qui arrive aux emails en échec | Quand l'utiliser |
|---|---|---|
| Livré normalement, rapports envoyés | Monitoring, le temps de recenser tous les expéditeurs légitimes |
| Envoyé dans le spam ou le courrier indésirable | Transition, une fois que vous êtes sûr que la majorité des emails légitimes passent |
| Bloqué au niveau SMTP, jamais délivré | Enforcement total, une fois que chaque expéditeur est authentifié et aligné |
Gardez en tête que même en reject, le serveur de réception a le dernier mot. Une politique DMARC est une recommandation, pas une garantie.
Comment configurer un enregistrement DMARC
DMARC dépend de SPF et DKIM. Si vous ne les avez pas encore configurés, commencez par là. Vous devrez configurer un enregistrement SPF pour votre domaine et configurer votre enregistrement DKIM avant que DMARC puisse faire son travail. Sans eux, DMARC n'a rien à appliquer.
Une fois SPF et DKIM en place, voici comment ajouter DMARC.
Vérifier les enregistrements existants
Avant de créer un nouvel enregistrement, vérifiez si votre domaine a déjà un DMARC configuré. Vous pouvez passer votre domaine dans le vérificateur gratuit de configuration de délivrabilité de lemlist pour voir vos enregistrements SPF, DKIM et DMARC au même endroit. Si un enregistrement existe déjà, mettez-le à jour plutôt que d'en créer un doublon : deux enregistrements DMARC sur le même domaine s'annulent mutuellement.
Préparer votre enregistrement
Commencez avec une politique de monitoring uniquement pour observer ce qui se passe avant d'appliquer quoi que ce soit :
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1
En clair, cet enregistrement dit : n'appliquez rien pour l'instant, envoyez juste des rapports quotidiens, et signalez tout message où SPF ou DKIM échoue. Remplacez l'adresse email par une que vous contrôlez. Utilisez une boîte dédiée ou un alias, parce que ces rapports s'accumulent vite.
Ajouter l'enregistrement à votre DNS
Étape 1 : Ouvrez le panneau de gestion DNS de votre fournisseur de domaine. C'est là où vous gérez le DNS du domaine depuis lequel vous envoyez (GoDaddy, Cloudflare, Namecheap, ou tout autre hébergeur de domaine).
Étape 2 : Ajoutez un nouvel enregistrement DNS avec ces paramètres :
Type : TXT
Host : _dmarc
Valeur : v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1
TTL : Utilisez la valeur par défaut (souvent 3600 ou auto)
Enregistrez.
Étape 3 : Validez l'enregistrement (voir la section suivante). Les changements DNS peuvent prendre jusqu'à 48 heures pour se propager, même si c'est souvent l'affaire de quelques heures.
Planifier votre déploiement
Ne passez pas directement à reject. C'est la façon la plus courante de se planter avec DMARC, souvent parce qu'un outil oublié (un CRM, une plateforme marketing, un service d'email transactionnel) ne peut soudainement plus délivrer. Le chemin sûr :
Commencez à p=none et laissez les rapports s'accumuler pendant une à deux semaines, assez longtemps pour faire remonter chaque service qui envoie en votre nom
Analysez les rapports et autorisez chaque expéditeur légitime dans SPF et DKIM
Passez à p=quarantine pour envoyer les messages en échec en spam. Pour tester sur une portion du trafic d'abord, utilisez t=y (RFC 9989) ou un pct bas sur les anciens setups, et surveillez les rapports à chaque étape
Quand tous les expéditeurs légitimes passent de façon constante, passez à p=reject pour bloquer complètement les échecs
Ce déploiement progressif vous permet de détecter les problèmes de configuration avant qu'ils ne fassent rebondir de vrais emails de prospection.
Comment vérifier et valider votre enregistrement DMARC
Une recherche rapide confirme si un enregistrement DMARC existe et s'il est correctement formaté :
nslookup -type=txt _dmarc.example.com
ou
dig txt _dmarc.example.com
Vous pouvez aussi envoyer un email de test et vérifier les en-têtes pour y trouver dmarc=pass. Dans tous les cas, confirmez ces quatre points :
Un seul enregistrement existe. Plusieurs enregistrements DMARC sur le même nom de recherche sont tous rejetés.
La syntaxe est propre, commence par v=DMARC1 et utilise des valeurs valides tout du long.
La boîte rua est joignable. Si elle se trouve sur un domaine différent de celui qui est monitoré, ce domaine a aussi besoin d'un enregistrement d'autorisation.
Le mode d'alignement correspond à votre setup. L'alignement strict casse les emails envoyés par des plateformes qui signent avec leur propre sous-domaine.
DMARC pour la prospection à grande échelle
Configurer un enregistrement DMARC, c'est la base. Mais si vous envoyez des milliers de cold emails depuis plusieurs boîtes et domaines, un enregistrement DNS ne suffit pas. Vous avez besoin d'une visibilité continue sur ce qui se passe réellement.
Quand vous connectez un domaine existant ou achetez un nouveau domaine d'envoi dans lemlist, la plateforme peut configurer l'authentification automatiquement. SPF, DKIM et DMARC, correctement configurés dès le départ. Ça élimine l'un des points de défaillance les plus courants : les erreurs de configuration DNS manuelles qui plombent silencieusement votre délivrabilité.
Avant l'envoi de toute campagne, les vérifications de délivrabilité pré-envoi détectent le contenu à risque, les erreurs de configuration techniques et les signaux de placement en inbox. Vous êtes au courant des problèmes d'authentification avant qu'ils n'affectent un vrai envoi.
Et les tests de placement en inbox vont encore plus loin. lemlist envoie à de vraies adresses de test chez Google et Microsoft pour vous montrer si vous atterrissez dans l'inbox principale, les promotions ou le spam. Vous recevez aussi des alertes quand les taux de bounce ou les tendances de plaintes spam commencent à grimper. Ce type d'alerte précoce fait la différence entre un problème réparable et un domaine grillé.
Il ne s'agit pas de remplacer la configuration DMARC. C'est une couche supplémentaire avec le monitoring que la prospection à grande échelle exige vraiment.
Comment lire vos rapports DMARC
Une fois votre enregistrement DMARC actif avec une adresse rua, les rapports agrégés commencent à arriver. Ce sont des fichiers XML envoyés par les serveurs de réception, généralement quotidiennement, qui résument ce qui est arrivé aux emails envoyés depuis votre domaine.
Rapports agrégés (rua)
Ils donnent une vue d'ensemble sur tous les messages :
Adresses IP des expéditeurs ayant envoyé des emails en se faisant passer pour votre domaine
Résultats SPF, DKIM et DMARC pour chaque IP
Nombre de messages par source d'envoi
Dispositions : ce qui est arrivé à l'email (délivré, mis en quarantaine, rejeté)
Les rapports agrégés vous permettent de répondre à des questions comme : qui envoie des emails depuis mon domaine ? Mes sources légitimes passent-elles l'authentification ? Quelqu'un usurpe-t-il mon identité ?
Rapports forensiques (ruf)
Ils contiennent les détails de chaque message ayant échoué au DMARC. Plus granulaires, mais aussi plus sensibles :
En-têtes complets du message
Résultats d'authentification
Informations sur l'expéditeur d'enveloppe
Horodatages de génération du message et du rapport
La plupart des grands fournisseurs, dont Google et Microsoft, n'envoient pas de rapports forensiques pour des raisons de confidentialité. Considérez-les comme un bonus, pas une garantie, et ne comptez jamais uniquement sur les ruf pour avoir de la visibilité.
Le problème du XML brut
Le hic : les rapports DMARC arrivent en XML brut. Techniquement lisibles, mais concrètement pénibles. Une seule journée d'envoi peut générer des dizaines de rapports avec des milliers de lignes.
Vous pouvez les parser à la main si ça vous amuse. La plupart des équipes utilisent un outil de monitoring DMARC (dmarcian, Postmark, EasyDMARC) qui agrège et visualise les données. Pas strictement nécessaire, mais ça fait gagner un temps réel quand le volume augmente.
Erreurs DMARC courantes qui plombent votre délivrabilité
Un enregistrement techniquement correct peut quand même poser problème si le reste de la config ne suit pas. Les erreurs les plus fréquentes :
Plusieurs enregistrements DMARC sur un même domaine. Les serveurs de réception traitent ça comme une erreur et ignorent complètement la politique.
Passer directement à p=reject sans monitoring préalable. Les expéditeurs légitimes jamais autorisés sont bloqués en même temps que le trafic malveillant.
Ne pas configurer de rua. Appliquer une politique sans reporting, c'est zéro visibilité sur ce qui passe ou échoue.
Alignement strict avant d'avoir confirmé que chaque expéditeur correspond. Ça casse les emails envoyés depuis des sous-domaines ou des plateformes qui signent avec leur propre domaine.
Laisser les domaines parqués sans protection. Les domaines qui n'envoient jamais d'emails sont exactement ceux que les attaquants usurpent. Publiez v=DMARC1; p=reject sur chaque domaine que vous possédez, même les inactifs.
Oublier de mettre à jour SPF et DKIM en ajoutant de nouveaux outils. Chaque nouveau service d'envoi doit être autorisé avant de passer le DMARC.
Pour conclure
Le DMARC n'est plus optionnel pour le cold email en 2026. Google et Microsoft imposent désormais des exigences d'authentification, Yahoo demande la même chose, et envoyer sans DMARC met votre délivrabilité en danger.
La mise en place est simple : confirmez que SPF et DKIM sont en place, ajoutez un enregistrement DMARC en commençant par p=none, validez-le, surveillez vos rapports, puis durcissez la politique progressivement. Le plus difficile, c'est de garder la visibilité quand vous passez à l'échelle avec plusieurs domaines d'envoi et boîtes mail.
Si vous voulez lancer votre prospection avec une authentification gérée dès le jour 1, démarrez l'essai gratuit de 14 jours.
Convert strategy into pipeline
Launch your first outbound campaign with verified leads, AI sequences, and multichannel outreach from one platform.