No DMARC record found : la ligne qui manque à votre domaine

En bref

• Le message signifie qu’il n’y a aucun enregistrement TXT sous _dmarc.yourdomain.com. Votre serveur de messagerie n’est pas en panne.
• Ajoutez un enregistrement TXT avec l’hôte _dmarc et la valeur v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Avec p=none, la distribution reste exactement comme avant.
• Gmail, Yahoo et Outlook.com n’exigent l’enregistrement que des gros expéditeurs. Ajoutez-le quand même : Google compte un domaine entier et ne lève jamais le statut de gros expéditeur, et les rapports ne commencent qu’une fois l’enregistrement en place.
• Si un vérificateur ne trouve toujours rien, cherchez un mauvais hébergeur DNS, un nom d’hôte doublé ou deux enregistrements DMARC. Deux enregistrements s’annulent.
• La norme a changé en mai 2026 avec la RFC 9989 : pct a disparu, t et np sont nouveaux. En octobre 2026, l’aide de Google décrit encore pct.

« No DMARC record found » (aucun enregistrement DMARC trouvé) signifie qu’un vérificateur a demandé au DNS un enregistrement TXT sous _dmarc.yourdomain.com et n’a rien reçu. Rien n’est en panne sur votre serveur de messagerie. La correction tient en un enregistrement TXT avec l’hôte _dmarc et la valeur v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Avec p=none, vos emails sont distribués exactement comme avant. Vous indiquez seulement aux serveurs destinataires que vous participez, et vous commencez à recevoir des rapports.

DMARC est le troisième des trois enregistrements de l’email, à côté de SPF et de DKIM. SPF énumère les serveurs qui peuvent envoyer pour votre domaine. DKIM signe chaque message. DMARC dit à un serveur destinataire quoi faire quand aucun des deux ne se porte garant du domaine de votre adresse d’expéditeur (From), et où envoyer un résumé quotidien. Depuis mai 2026, il est défini dans la RFC 9989, qui a remplacé l’ancienne RFC 7489. Beaucoup de guides décrivent encore l’ancienne version, et la page d’aide de Google aussi en octobre 2026.

L’enregistrement à ajouter

Connectez-vous là où le DNS de votre domaine est géré. C’est l’entreprise vers laquelle pointent vos serveurs de noms, qui n’est pas toujours celle à qui vous avez acheté le domaine. Ajoutez un nouvel enregistrement avec ces valeurs :

Écrit comme une ligne d’un fichier de zone, l’enregistrement terminé ressemble à ceci :

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Remplacez example.com par votre propre domaine. Les trois parties font ceci :

• v=DMARC1 marque la ligne comme un enregistrement DMARC. Il doit venir en premier, avec DMARC1 en majuscules. Sinon, les serveurs destinataires ignorent tout l’enregistrement.
• p=none est la politique : traitez mes emails comme vous le feriez de toute façon. Rien n’est bloqué ni déplacé en spam à cause de cet enregistrement.
• rua=mailto:… est l’adresse des rapports quotidiens. Créez cette adresse, ou un alias qui vous les transfère, avant de publier l’enregistrement.

Google indique les trois mêmes champs dans Set up DMARC. Il demande aussi que SPF et DKIM fonctionnent depuis 48 heures avant d’ajouter DMARC. Si votre vérificateur signale aussi ces deux-là, corrigez-les d’abord.

Comment vérifier que cela a fonctionné

Interrogez vous-même le DNS. Sur macOS ou Linux, ouvrez un terminal et utilisez dig. Sur Windows, utilisez nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Si l’enregistrement est en ligne, la ligne revient entre guillemets. Voici ce qu’a répondu le domaine de Google lui-même le 5 octobre 2026 :

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Une réponse vide signifie que l’enregistrement n’est pas encore là, ou pas là où les serveurs destinataires le cherchent. Une fois que votre propre requête affiche la ligne, relancez le vérificateur qui vous a donné le message. MXToolbox, par exemple, formule le problème ainsi : « No DMARC Record found », et explique que « votre domaine n’a pas d’enregistrement DMARC publié ».

Ce que signifie chaque partie d’un enregistrement DMARC

Un enregistrement est une liste de paires tag=value (balise=valeur) séparées par des points-virgules. Seule v est obligatoire dans la norme, et elle doit venir en premier. Placez p en deuxième : l’aide de Google indique que « les balises v et p doivent figurer en premier », et l’ancienne norme attendait le même ordre. Voici les balises de la RFC 9989, section 4.7 :

Les anciens enregistrements se terminent souvent par pct=100. Cette balise devait appliquer une politique à une part des emails en échec. La RFC 9989 l’a supprimée, avec rf et ri, et en donne la raison :

L’expérience opérationnelle a montré que la balise « pct » n’était généralement pas appliquée avec exactitude, sauf lorsque la valeur indiquée était 0 ou 100 (la valeur par défaut), et que les inexactitudes pour les autres valeurs variaient fortement d’une implémentation à l’autre.

Les serveurs destinataires doivent ignorer les balises qu’ils ne connaissent pas : un ancien pct=100 ne fait donc aucun mal. Les enregistrements de yahoo.com et de microsoft.com le portaient encore le 5 octobre 2026, et la page d’aide de Google recommande toujours pct pour un déploiement progressif. Dans un nouvel enregistrement, omettez-la.

Avez-vous besoin de DMARC si vous n’envoyez que quelques emails par jour ?

D’après les règles publiées des grands fournisseurs de messagerie, un enregistrement DMARC est exigé dès que vous envoyez en masse. En dessous, c’est une recommandation.

Les sources sont les consignes de Google pour les expéditeurs, les Sender Best Practices de Yahoo et l’annonce de Microsoft pour les expéditeurs à fort volume, toutes en date d’octobre 2026. Si vous envoyez trente emails par jour depuis une seule boîte mail, aucune n’exige l’enregistrement. Il reste trois raisons de l’ajouter dès maintenant.

• Le seuil se compte par domaine, et il ne se remet pas à zéro. Google additionne tous les messages envoyés aux comptes Gmail personnels depuis le même domaine principal, sous-domaines compris. Sa FAQ pour les expéditeurs indique : « Les expéditeurs qui remplissent les critères ci-dessus au moins une fois sont définitivement considérés comme des gros expéditeurs. »
• Google et Yahoo le recommandent tous deux à tout le monde. Google écrit : « nous vous recommandons de toujours configurer SPF, DKIM et DMARC pour vos domaines ». Yahoo « invite vivement tous les expéditeurs à publier une politique DMARC pour chaque domaine qui envoie des emails ».
• Sans l’enregistrement, vous ne recevez aucun rapport. C’est grâce à eux que vous voyez quels serveurs envoient des emails avec votre domaine dans la ligne From, vos propres outils comme des inconnus.

Pour les gros expéditeurs, l’enregistrement manquant a des conséquences. La FAQ de Google pour les expéditeurs mentionne à ce sujet l’erreur temporaire 4.7.31 : « le domaine d’envoi n’a pas d’enregistrement DMARC, ou l’enregistrement DMARC ne précise pas de politique DMARC ». La même page dit que depuis novembre 2025, les emails qui ne respectent pas les exigences s’exposent à « des rejets temporaires et permanents ».

Enregistrement ajouté, et le vérificateur ne trouve toujours rien ?

La cause est alors le plus souvent l’une de celles-ci. Passez-les en revue avec la requête dig ci-dessus.

• Vous avez modifié le DNS au mauvais endroit. Si vos serveurs de noms sont chez une autre entreprise que votre bureau d’enregistrement, les enregistrements saisis chez ce dernier ne sont jamais interrogés. dig +short NS example.com montre qui répond pour votre domaine.
• L’hôte est erroné. L’enregistrement se trouve sur example.com lui-même, ou sur un nom doublé, comme décrit plus haut. Les serveurs destinataires ne demandent que _dmarc.example.com.
• Il y a deux enregistrements DMARC. La norme est stricte sur ce point : « Si plusieurs enregistrements de politique DMARC sont renvoyés pour une même cible, ils sont tous écartés. » Fusionnez-les en un seul. Deux adresses de rapport vont dans un seul rua, séparées par une virgule.
• La première balise n’est pas exactement v=DMARC1. Des minuscules, une faute de frappe comme DMARC 1, ou p= placé devant rendent l’enregistrement invalide.
• Le type d’enregistrement n’est pas TXT, ou la valeur a été collée avec des guillemets typographiques depuis un document. Saisissez la valeur en texte brut, sans guillemets, sauf si l’aide de votre hébergeur DNS les demande.
• Une ancienne réponse est encore en cache. Les résolveurs retiennent pendant un temps qu’« aucun enregistrement de ce type » n’existe. Interrogez directement l’un de vos propres serveurs de noms en ajoutant son nom à la requête, par exemple dig +short TXT _dmarc.example.com @ns1.example.net. Si l’enregistrement y apparaît, les vérificateurs suivront.

Où vont les rapports, et qu’en faire

Chaque serveur destinataire qui a reçu des emails avec votre domaine dans la ligne From envoie un rapport à l’adresse rua. D’après la page de Google About DMARC reports, ils sont « généralement envoyés une fois par jour par email ». Le rapport est un fichier XML, en général compressé, joint à un email. La RFC 9990 en décrit le format.

Google prévient que les grandes organisations « peuvent recevoir jusqu’à des centaines, voire des milliers de rapports par jour » et recommande un groupe ou une boîte mail dédiée. Le nombre dépend de la quantité que vous envoyez et du nombre de domaines destinataires : une ou deux boîtes mail en produisent donc bien moins. Un alias comme dmarc@ avec un filtre vers son propre dossier suffit.

L’adresse devrait être sur le même domaine que l’enregistrement. Si vous voulez recevoir les rapports ailleurs, l’autre domaine doit donner son accord en publiant un enregistrement à lui. Sans cela, les serveurs destinataires doivent ignorer l’adresse (RFC 9990, section 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

C’est pourquoi une adresse Gmail gratuite ne fonctionne pas comme adresse de rapport : gmail.com ne publiait aucun enregistrement de ce type lors de notre vérification du 5 octobre 2026.

Dans le fichier, chaque bloc record représente un serveur d’envoi : son adresse IP, le nombre de messages et, sous policy_evaluated, si DKIM et SPF passent pour votre domaine. Vous cherchez deux choses. Les serveurs que vous connaissez et qui affichent fail sont à corriger, et DMARC échoue alors que SPF et DKIM passent explique comment. Les serveurs que vous ne connaissez pas sont soit un outil que vous avez oublié, soit quelqu’un qui utilise votre nom.

Après p=none : quand durcir la politique

p=none est un mode de surveillance. Il répond au minimum que demandent les fournisseurs de messagerie, et il n’empêche personne de falsifier votre adresse. Seuls p=quarantine, qui demande aux serveurs destinataires de traiter les emails en échec comme suspects, et p=reject, qui leur demande de les refuser, le font.

Avant de durcir, chaque source légitime de vos emails doit passer. La RFC 9989 dit que ces écarts « DOIVENT être corrigés avant toute tentative » d’application, et que, selon la fréquence de vos envois, il « peut falloir de nombreux mois » de rapports pour en être sûr. La page de déploiement de Google juge une semaine de rapports « généralement suffisante ». Avec une boîte mail et un ou deux outils, vous êtes plus près du chiffre de Google, mais laissez passer quelques semaines pour que la facturation mensuelle et le formulaire de contact apparaissent aussi.

Pour l’étape elle-même, les deux sources divergent. Google suggère toujours p=quarantine; pct=5, puis d’augmenter le chiffre. La norme a abandonné pct et propose ceci à la place :

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y demande aux serveurs destinataires de traiter pour l’instant les échecs un niveau plus bas, c’est-à-dire comme none. Quand les rapports restent propres, retirez t=y. Sachez qu’un serveur destinataire qui ne connaît pas la balise l’ignore et applique quarantine pleinement, et que les pages de Google ne mentionnent pas t en octobre 2026. Si une politique plus stricte toucherait des emails que vous ne pouvez pas encore corriger, restez sur p=none.

Le rôle de WarmupBay

Quand vous connectez une boîte mail, WarmupBay vérifie SPF, DKIM et DMARC pour son domaine. Si l’enregistrement DMARC manque, il vous en affiche un tout prêt à copier. Vous pouvez lancer la chauffe malgré tout. Si les enregistrements manquent toujours au bout de 72 heures, la chauffe s’arrête.

WarmupBay ne peut pas ajouter l’enregistrement à votre place, puisque votre DNS vous appartient, et il ne collecte ni ne lit les rapports DMARC. Ce qu’il fait, c’est l’étape qui suit les enregistrements : votre boîte mail échange quelques emails par jour avec d’autres boîtes mail dans un réseau partagé, en commençant à trois et en augmentant d’un par jour, pour que l’activité d’envoi se construise progressivement. Il est gratuit pour 10 emails par jour. Voyez ce que couvrent le contrôle et la chauffe, ou connectez votre boîte mail une fois l’enregistrement en place.

Questions fréquentes

Un enregistrement DMARC sur example.com couvre-t-il aussi des sous-domaines comme news.example.com ?

Oui. Un serveur destinataire demande d’abord un enregistrement sous _dmarc.news.example.com. S’il n’y en a pas, il se rabat sur l’enregistrement du domaine organisationnel, example.com. La politique appliquée au sous-domaine est celle de sp si vous l’avez définie, sinon celle de p.

Puis-je publier v=DMARC1; p=none sans adresse rua ?

Oui. C’est un enregistrement valide, et il compte comme une politique publiée. Vous ne recevrez aucun rapport : vous ne verrez donc pas si vos propres emails passent ni qui d’autre utilise votre domaine. Yahoo qualifie une adresse rua fonctionnelle de fortement recommandée, et Google recommande d’en inclure toujours une.

Me faut-il un enregistrement DMARC pour un second domaine que j’utilise seulement pour la prospection ?

Oui. Les serveurs destinataires consultent le domaine de l’adresse d’expéditeur (From) de chaque message : un enregistrement sur votre domaine principal ne couvre donc pas un autre domaine. Utilisez la même ligne sur le second domaine. Si ses rapports doivent arriver à une adresse de votre domaine principal, celui-ci doit publier l’enregistrement d’autorisation décrit sous « Où vont les rapports ».

Que doit publier un domaine qui n’envoie jamais d’emails ?

La paire stricte. Le M3AAWG recommande l’enregistrement SPF v=spf1 -all et un enregistrement DMARC avec p=reject pour les domaines qui n’envoient jamais d’emails, afin que personne ne puisse les utiliser dans une adresse d’expéditeur. Pour DMARC, c’est la ligne v=DMARC1; p=reject sous _dmarc.

p=none est-il moins bon pour mes emails que p=quarantine ou p=reject ?

Les règles publiées de Gmail, Yahoo et Outlook.com pour les expéditeurs demandent au moins p=none et rien de plus strict. La politique décide de ce qu’il advient des emails qui échouent à DMARC, y compris les emails falsifiés à votre nom. Une fonction en demande plus : BIMI, le logo à côté de vos messages, exige quarantine ou reject d’après l’aide de Google.

Sources

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)