Configurer DMARC : tags, rapports, erreurs

Que faut-il en place avant de configurer DMARC ?

DMARC n'authentifie rien à lui seul. Il lit les résultats de SPF et de DKIM et pose une question supplémentaire : le domaine qui a passé le contrôle correspond-il au domaine affiché dans l'en-tête From ? La spécification DMARC appelle cette correspondance « alignement ». Un message passe DMARC si SPF passe et est aligné, ou si DKIM passe et est aligné. Les deux ne sont pas nécessaires.

C'est pour cela que l'ordre compte. Avant de publier un enregistrement DMARC, vérifiez deux choses pour chaque service qui envoie au nom de votre domaine. D'abord, un enregistrement SPF qui inclut ce service, le tout dans un seul enregistrement v=spf1 combiné. Ensuite, une signature DKIM dont le domaine d= est votre domaine ou l'un de ses sous-domaines. Si vous reprenez toute la chaîne, notre article sur la façon dont DKIM, DMARC et SPF fonctionnent ensemble pour le cold emailing détaille l'ordre de configuration et les enregistrements nécessaires à une configuration typique Workspace plus Brevo.

Là où ça coince : un service d'envoi peut passer SPF pour son propre domaine de bounce sans que ce domaine corresponde au vôtre. SPF passe, mais n'est pas aligné. Dans ce cas, DMARC repose entièrement sur une signature DKIM faite avec votre domaine. Si le service signe avec son propre domaine, DMARC échoue alors même que les deux contrôles affichent « pass ».

Configurer un enregistrement DMARC, étape par étape

1. 1 Inventoriez vos expéditeurs. Listez chaque système qui envoie des e-mails avec votre domaine dans le From : votre fournisseur de messagerie, votre compte d'envoi de prospection, votre CRM, la facturation, le support. Ceux que vous oubliez réapparaîtront plus tard sous forme d'échecs.
2. 2 Vérifiez SPF et DKIM pour chaque expéditeur. Envoyez un message de test vers une boîte que vous contrôlez. Ouvrez les en-têtes d'origine et repérez la ligne Authentication-Results. Vous cherchez spf=pass ou dkim=pass, avec un domaine qui correspond à votre domaine From.
3. 3 Créez l'enregistrement TXT. Chez votre hébergeur DNS, ajoutez un enregistrement TXT sur l'hôte _dmarc (qui se résout en _dmarc.votredomaine.fr) avec la valeur v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr. C'est aussi l'enregistrement de départ que montre l'aperçu IA de Google pour cette recherche.
4. 4 Vérifiez qu'il se résout. Lancez dig TXT _dmarc.votredomaine.fr +short ou utilisez un outil de lookup DMARC en ligne. Vous devez voir exactement une chaîne commençant par v=DMARC1.
5. 5 Collectez les rapports. Les serveurs de réception qui prennent en charge DMARC envoient des rapports agrégés au format XML à l'adresse rua. Lisez-les jusqu'à ce que chaque source légitime affiche des passages alignés.
6. 6 Durcissez la politique. Remplacez p=none par p=quarantine, surveillez les rapports, puis passez à p=reject dès que plus rien de légitime n'échoue.

L'étape 3 est celle où se produisent la plupart des erreurs DNS. Beaucoup d'interfaces DNS ajoutent automatiquement votre domaine dans le champ hôte. Si vous saisissez le nom complet _dmarc.votredomaine.fr, vous risquez d'obtenir _dmarc.votredomaine.fr.votredomaine.fr, et les serveurs de réception ne le trouvent jamais.

Que doit contenir mon enregistrement DMARC ?

Pour un domaine qui n'a jamais eu de DMARC, commencez en mode surveillance : v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr. Cela indique aux serveurs de réception de délivrer normalement et de vous envoyer des rapports. Les tags ci-dessous proviennent de la spécification DMARC. Tous sont facultatifs, sauf v et p.

Tag	Ce qu'il contrôle	Valeur de départ courante
v	Version. Doit être le premier tag, exactement DMARC1.	v=DMARC1
p	Politique pour les messages qui échouent à DMARC sur le domaine organisationnel : none, quarantine ou reject.	p=none
sp	Politique pour les sous-domaines. Si vous l'omettez, les sous-domaines héritent de p.	À omettre au début
rua	Destination des rapports agrégés (synthèses XML), sous forme d'URI mailto:.	rua=mailto:dmarc@votredomaine.fr
ruf	Destination des rapports d'échec (forensic). Beaucoup de grands fournisseurs ne les envoient pas.	Facultatif
adkim	Mode d'alignement DKIM : r (relaxed, les sous-domaines correspondent) ou s (strict, correspondance exacte).	Laisser la valeur par défaut relaxed
aspf	Mode d'alignement SPF : r ou s, même signification qu'adkim.	Laisser la valeur par défaut relaxed
pct	Part des messages en échec à laquelle s'applique la politique, utilisée pour un durcissement progressif.	À omettre en p=none

L'alignement strict (adkim=s ou aspf=s) piège souvent. Si votre outil de prospection signe DKIM avec un sous-domaine comme mail.votredomaine.fr alors que le From indique votredomaine.fr, le mode relaxed passe et le mode strict échoue. Ne passez en strict que si vous savez que chaque signataire utilise exactement le domaine From.

Ajouter DMARC chez Network Solutions ou tout autre hébergeur DNS

L'enregistrement est le même chez tous les hébergeurs DNS, que ce soit Network Solutions, GoDaddy, Cloudflare ou l'interface de votre registrar. Ajoutez un enregistrement de type TXT. Mettez _dmarc dans le champ hôte ou nom, et votre chaîne v=DMARC1 dans le champ valeur. Ce qui change, c'est la façon dont chaque interface traite le champ hôte : vérifiez si elle attend uniquement le libellé _dmarc ou le nom complet. Après l'enregistrement, interrogez _dmarc.votredomaine.fr depuis l'extérieur, pas dans l'aperçu de l'interface elle-même.

Il existe un second piège. Si les serveurs de noms de votre domaine pointent ailleurs que chez le registrar, par exemple vers Cloudflare ou un hébergeur, les enregistrements ajoutés dans l'interface du registrar ne sont jamais actifs. Vous devez modifier la zone DNS là où pointent les enregistrements NS. Notre guide DKIM chez GoDaddy pour les expéditeurs Brevo décrit le même décalage de serveurs de noms pour une clé DKIM.

DMARC pour Google Workspace

Sur un domaine Google Workspace, vous publiez DMARC au même endroit que tout autre enregistrement : chez votre hébergeur DNS, pas dans la console d'administration. L'article d'aide de Google sur la configuration de DMARC (knowledge.workspace.google.com) cite SPF et DKIM comme prérequis. DKIM ne signe dans Workspace qu'une fois la clé générée, l'enregistrement TXT google._domainkey publié et l'authentification activée dans la console d'administration. D'ici là, les messages Workspace peuvent passer SPF mais ne portent aucune signature DKIM alignée.

Si vous envoyez aussi via Brevo depuis le même domaine, Brevo a besoin de son propre enregistrement DKIM à côté de celui de Google. Les deux signatures peuvent s'aligner sur le même domaine From, et un seul enregistrement DMARC couvre les deux. Notre guide de déploiement DMARC pour Google Workspace traite de l'enregistrement et du passage depuis p=none, et les étapes de configuration DKIM G Suite couvrent l'activation de la clé, souvent oubliée.

Comment consulter les enregistrements et rapports DMARC

« Consulter DMARC » peut vouloir dire deux choses : vérifier l'enregistrement publié, ou lire les rapports que renvoient les serveurs de réception. Chaque besoin demande un type d'outil différent. Le tableau compare les options réalistes selon les deux mêmes questions : ce qu'elles montrent et où elles s'arrêtent.

Option	Ce qu'elle montre	Où elle s'arrête
dig ou nslookup (ligne de commande)	La chaîne TXT brute sur _dmarc, directement depuis le DNS. Fait apparaître doublons et fautes de frappe.	Lit uniquement l'enregistrement. Pas de rapports, pas d'explication des tags.
Lookup DMARC de MXToolbox (web)	L'enregistrement publié avec ses tags analysés. MXToolbox fait partie des sources citées par l'aperçu IA de Google pour cette recherche.	Une vérification d'enregistrement. Les rapports agrégés arrivent toujours en XML dans votre boîte rua.
En-têtes de message dans Gmail ou Outlook (Afficher l'original / Afficher la source)	La ligne Authentication-Results d'un message : dmarc=pass ou fail, plus les domaines SPF et DKIM.	Un message à la fois. Ne montre pas les e-mails envoyés par des tiers qui usurpent votre domaine.
Services de rapports DMARC comme Sendmarc, dmarcly ou PowerDMARC	Les rapports agrégés regroupés par source d'envoi. La page de classement de Sendmarc, par exemple, décrit une création d'enregistrement guidée et un suivi.	Un service supplémentaire à gérer. Vous faites pointer rua vers une adresse qu'il vous fournit, ce qui signifie qu'un autre domaine reçoit vos rapports.

Si rua pointe vers une boîte sur un autre domaine, la spécification DMARC exige que ce domaine publie un enregistrement d'autorisation sur votredomaine.fr._report._dmarc.domainerapports.fr. Les services de rapports le mettent en place de leur côté. Si vous envoyez les rapports vers votre propre second domaine, c'est à vous de le publier. Sinon, les serveurs de réception peuvent écarter les rapports sans prévenir.

Corriger les échecs DMARC de vos e-mails

Partez de l'en-tête Authentication-Results d'un message en échec. Il indique quel contrôle a échoué et pour quel domaine. La plupart des échecs viennent de l'une de ces causes :

• Deux enregistrements DMARC sur _dmarc. La spécification DMARC demande aux serveurs de réception d'arrêter le traitement DMARC lorsqu'ils en trouvent plusieurs : votre domaine n'a alors de fait aucune politique. Fusionnez-les en un seul.
• Erreurs de syntaxe. v=DMARC1 n'est pas en premier, un point-virgule manque, ou le rua n'a pas de mailto:. Les serveurs de réception ignorent un enregistrement qu'ils ne peuvent pas analyser.
• DKIM signé avec le domaine du prestataire. La valeur d= de l'en-tête DKIM-Signature n'est pas votre domaine. Corrigez-le en ajoutant l'enregistrement DKIM du prestataire pour votre propre domaine.
• SPF passe mais n'est pas aligné. Le Return-Path appartient au service d'envoi. Assurez-vous que DKIM est aligné à la place, ou configurez un domaine de bounce personnalisé si le service le propose.
• Transferts et listes de diffusion. Le transfert casse SPF, et les listes qui réécrivent l'objet ou le pied de page cassent DKIM. Ces échecs apparaissent dans les rapports. Ce ne sont pas des erreurs de votre configuration.
• Politique durcie trop tôt. Un expéditeur oublié, comme les factures de votre outil comptable, part en quarantaine après le passage à p=quarantine. Revenez à p=none, ajoutez le SPF et le DKIM de cet expéditeur, puis durcissez à nouveau.

DMARC indique aux serveurs de réception comment traiter les messages en échec. Il ne décide pas où atterrissent les messages qui passent. Cela dépend de la façon dont le serveur de réception perçoit votre domaine et de votre manière d'envoyer. Notre guide sur la façon de vérifier, construire et réparer la réputation d'expéditeur prend le relais sur ce point.

La place d'EmailFlow OS par rapport à votre enregistrement DMARC

EmailFlow OS est un produit d'e-mails vidéo personnalisés par IA pour la prospection B2B à froid. Vous enregistrez une seule vidéo, vous la téléversez dans EmailFlow OS, vous connectez votre compte Brevo et votre domaine d'envoi, puis vous importez votre liste de prospects dans EmailFlow OS. EmailFlow OS crée ensuite une version personnalisée de cet enregistrement unique pour chaque destinataire, et non pour chaque entreprise. Chaque version part de votre propre boîte, via votre propre compte Brevo et sur votre propre domaine d'envoi. Il n'y a aucun expéditeur partagé de plateforme.

Côté DMARC, cela signifie que l'enregistrement qui s'applique est celui que vous publiez sur _dmarc de votre propre domaine. La signature DKIM que vous avez configurée dans Brevo pour ce domaine est celle qui doit s'aligner, et les rapports agrégés arrivent à votre adresse rua. Rien ne change dans les étapes DMARC ci-dessus. Vous faites la configuration une fois, pour le domaine que vous contrôlez déjà. Le fonctionnement de l'envoi est décrit sur la page prospection vidéo personnalisée avec EmailFlow OS.

Questions fréquentes

? Combien de temps faut-il pour qu'un enregistrement DMARC soit actif ?

Il fonctionne dès que les serveurs de réception peuvent le résoudre. La rapidité dépend du TTL de l'enregistrement et des éventuelles réponses négatives en cache chez les résolveurs. Les premiers rapports agrégés arrivent plus tard, car les serveurs de réception envoient des synthèses par intervalle de reporting plutôt qu'un rapport par message. Le tag facultatif ri permet de demander un intervalle, mais ce sont les serveurs de réception qui décident de la fréquence réelle d'envoi.

? p=none est-elle une politique DMARC valide ?

Oui. p=none est une politique valide selon la spécification DMARC. Elle demande aux serveurs de réception de n'appliquer aucune action fondée sur DMARC et d'envoyer des rapports. C'est le mode surveillance : vous voyez qui envoie au nom de votre domaine, mais les messages usurpés ne sont ni mis en quarantaine ni rejetés à cause de DMARC. Utilisez-le pour identifier tous vos expéditeurs légitimes avant de passer à p=quarantine ou p=reject.

? Faut-il un enregistrement DMARC distinct pour chaque service d'envoi ?

Non. Un domaine a exactement un enregistrement DMARC, sur _dmarc. Il couvre chaque service qui envoie avec ce domaine dans l'en-tête From. Chaque service a besoin de son propre include SPF et de sa propre clé DKIM. Un second enregistrement v=DMARC1 sur le même hôte n'ajoute aucune couverture : il amène les serveurs de réception à arrêter le traitement DMARC pour le domaine.

? Quelle est la différence entre rua et ruf dans DMARC ?

rua définit la destination des rapports agrégés : des synthèses XML par IP d'envoi, avec le nombre de messages et les résultats SPF, DKIM et DMARC. ruf définit la destination des rapports d'échec : des copies ou extraits de messages individuels en échec. Ce sont les rapports agrégés qui servent à déployer DMARC. Beaucoup de grands fournisseurs de messagerie n'envoient pas du tout de rapports d'échec.