DMARC : la consigne que vous donnez aux destinataires

DMARC relie SPF et DKIM à l’expéditeur visible et indique aux destinataires quoi faire des faux. Comment passer de l’observation à une protection réelle.

SPF et DKIM constatent. DMARC décide. C’est le seul des trois enregistrements qui dise aux serveurs destinataires ce qu’ils doivent faire d’un message dont l’expéditeur affiche votre domaine sans réussir les contrôles : le laisser passer, le mettre en quarantaine, ou le refuser. Et c’est le seul qui vous renvoie un compte rendu.

DMARC ajoute aussi la pièce qui manquait. SPF contrôle l’adresse d’enveloppe et DKIM le domaine de signature – ni l’un ni l’autre ne regarde le champ « De » que voit le destinataire. DMARC exige l’alignement : le domaine validé par SPF ou par DKIM doit correspondre au domaine affiché. Un seul des deux contrôles suffit, mais il doit s’aligner. C’est ce qui transforme deux vérifications techniques en une protection de votre nom.

À quoi ressemble l’enregistrement

L’enregistrement DMARC est un TXT publié sur _dmarc devant votre domaine.

_dmarc.exemple.fr.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr; sp=reject; adkim=r; aspf=r"

Le chemin, et pourquoi il a trois étapes

DMARC est le seul des trois enregistrements qui puisse faire disparaître votre propre courrier si vous allez trop vite. Passer directement à p=reject sans savoir qui envoie en votre nom, c’est risquer de couper la boutique, le logiciel de facturation ou l’outil de support – et personne ne vous préviendra, puisque le message est refusé chez le destinataire.

D’où la marche en trois temps :

L’étape 1 n’est utile qu’avec une adresse rua. Sans rapports, observer ne produit aucune information, et vous en êtes au même point six semaines plus tard.

Comment le mettre en place

L’enregistrement se publie toujours au même endroit, quel que soit l’hébergeur : une entrée TXT sur le sous-domaine _dmarc. Attention à un piège d’interface : certains panneaux ajoutent automatiquement le domaine après ce que vous saisissez. Selon le cas, il faut écrire _dmarc ou _dmarc.exemple.fr. Après publication, relancez la vérification : elle vous dira si l’enregistrement est au bon endroit.

Les deux dernières lignes ne sont pas une omission : Microsoft et Google hébergent vos boîtes, pas votre zone DNS – sauf si vous leur avez confié aussi le domaine.

Le chemin chez OVHcloud, pas à pas

1. Espace client OVHcloud → Web Cloud → Noms de domaine → votre domaine.
2. Onglet Zone DNS, puis Ajouter une entrée.
3. Type TXT. Dans le champ sous-domaine, saisissez _dmarc.
4. Valeur : v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr – en remplaçant l’adresse par une boîte que vous relevez réellement.
5. Validez, puis attendez quelques minutes et relancez la vérification.
6. Notez la date dans votre agenda : dans quatre semaines, relisez les rapports et passez à p=quarantine.

Les constats en détail

Aucun enregistrement DMARC

Nous n’avons trouvé aucun TXT commençant par v=DMARC1 sur _dmarc, ni sur le domaine parent.

C’est le manque le plus lourd des trois. Sans DMARC, un serveur destinataire qui reçoit un message affichant votre adresse et échouant à SPF et DKIM n’a aucune consigne : il décide seul, et il laisse le plus souvent passer. Aucune usurpation ne vous est signalée, aucune n’a de conséquence. Depuis 2024, Google et Yahoo exigent par ailleurs un enregistrement DMARC de toute personne qui leur envoie du courrier en volume.

Ce qu’il faut faire. Publiez aujourd’hui v=DMARC1; p=none; rua=mailto:…. Cet enregistrement ne change rien à la remise de votre courrier – il ne fait qu’ouvrir le robinet des rapports. Vous durcirez ensuite, avec les rapports sous les yeux.

Plusieurs enregistrements DMARC

Plus d’un TXT commençant par v=DMARC1 existe sur _dmarc.

Un seul est permis. Face à deux, les destinataires n’en choisissent pas un : ils ignorent DMARC entièrement. Une consigne p=reject soigneusement construite devient sans effet parce qu’une vieille ligne d’essai est restée à côté.

Ce qu’il faut faire. Décidez lequel est le bon, supprimez les autres. Si plusieurs adresses doivent recevoir les rapports, elles se listent dans un seul rua=, séparées par une virgule.

DMARC sans consigne valide

Le champ p= est absent ou contient une valeur que le standard ne connaît pas.

Les trois seules valeurs admises sont none, quarantine et reject. Une faute de frappe, un p=quarantaine francisé ou un p= laissé vide rendent l’enregistrement inopérant : il est publié, il a l’air d’exister, et les destinataires n’en tirent aucune consigne.

Ce qu’il faut faire. Corrigez la valeur. Si vous ne savez pas laquelle choisir, mettez none et une adresse rua : vous serez alors en position d’observer avant de décider.

DMARC en simple observation (p=none)

La consigne publiée est p=none.

Les messages qui usurpent votre domaine sont signalés dans les rapports, mais ni écartés ni refusés. C’est le bon point de départ, et c’est un mauvais état durable. Nous voyons régulièrement des domaines sur p=none depuis des années : l’enregistrement donne un sentiment de protection sans en apporter aucune.

Ce qu’il faut faire. Ouvrez les rapports que vous recevez depuis quelques semaines et repérez tous les serveurs légitimes qui ne s’alignent pas. Faites-les signer en DKIM avec votre domaine, ou ajoutez-les à SPF. Quand plus rien de légitime n’échoue, passez à p=quarantine, puis à p=reject après quelques semaines de calme. Si votre domaine n’envoie pas de courrier du tout, allez directement à p=reject : il n’y a rien à casser.

DMARC ne s’applique qu’en partie

Le champ pct= porte une valeur inférieure à 100.

La consigne ne s’applique alors qu’à cette part des messages ; le reste passe sans contrôle. C’est un outil de déploiement progressif, utile pendant quelques jours et oublié ensuite. Un p=reject; pct=10 protège un message sur dix, ce qui ne protège rien : il suffit à l’usurpateur de renvoyer.

Ce qu’il faut faire. Si le déploiement est terminé, supprimez pct – son absence équivaut à 100. Si vous montez encore en charge, fixez-vous une date de fin dès maintenant.

DMARC sans adresse de rapports

L’enregistrement ne contient pas de champ rua=.

Vous ne recevez donc aucun rapport agrégé. C’est plus gênant qu’il n’y paraît : sans rapports, vous ne voyez ni les usurpations, ni surtout vos propres canaux d’envoi qui échouent encore aux contrôles. Vous n’avez alors aucun moyen de durcir la consigne sans risquer de couper quelque chose, et l’enregistrement reste bloqué sur p=none indéfiniment.

Ce qu’il faut faire. Ajoutez rua=mailto:dmarc@exemple.fr. Utilisez une boîte réellement relevée, et de préférence dédiée : le volume est de quelques messages par jour, mais ils sont illisibles à l’œil nu.

Sous-domaines exemptés (sp=none)

Le champ sp=none exempte tous les sous-domaines de la consigne principale.

Les usurpations se déplacent alors simplement d’un cran. facture.exemple.fr ou securite-exemple.fr en sous-domaine sont des schémas éprouvés, d’autant plus crédibles qu’ils portent votre vrai nom de domaine. Le réglage vient souvent d’un besoin légitime – un sous-domaine d’envoi qui n’était pas encore aligné – conservé longtemps après.

Ce qu’il faut faire. Si le sous-domaine qui posait problème est désormais aligné, retirez sp : p s’appliquera alors partout. Si un sous-domaine doit vraiment rester à l’écart, donnez-lui son propre enregistrement _dmarc plutôt que d’ouvrir tous les autres.

Adresse de rapports non autorisée

Le champ rua désigne une adresse sur un autre domaine que celui vérifié, et ce domaine n’a pas publié l’autorisation correspondante.

Le standard prévoit cette autorisation pour éviter qu’on ne dirige des rapports vers un tiers non consentant. Sans elle, les opérateurs qui émettent les rapports les écartent. L’effet est trompeur : votre enregistrement paraît impeccable, et pourtant rien n’arrive jamais dans la boîte. Le cas se produit dès que vous passez par un service d’analyse DMARC externe.

Ce qu’il faut faire. Sur le domaine qui reçoit les rapports, publiez un TXT au nom exemple.fr._report._dmarc.domaine-des-rapports.fr avec la valeur v=DMARC1;. Si le destinataire est un prestataire, il vous fournit cette entrée – demandez-la.

DMARC hérité du domaine principal

Ce sous-domaine n’a pas d’enregistrement propre ; c’est celui du domaine principal qui s’applique.

Ce n’est pas un défaut. Le standard prévoit exactement ce fonctionnement, et il est même souhaitable : une consigne publiée une fois sur le domaine principal couvre tous les sous-domaines, y compris ceux que vous n’avez pas créés.

Ce qu’il faut faire. Rien, dans la plupart des cas. Un enregistrement propre n’a d’intérêt que si ce sous-domaine a ses propres canaux d’envoi et mérite ses propres rapports – une plateforme de newsletter sur infolettre.exemple.fr, par exemple.

Questions fréquentes

p=reject risque-t-il de bloquer mon courrier ?

Oui, s’il est publié trop tôt. Un canal d’envoi non aligné cesse d’arriver, et vous ne le voyez pas : le refus a lieu chez le destinataire. C’est pour cette raison que l’ordre observer, mettre de côté, refuser n’est pas une précaution de confort mais la seule manière sûre de procéder.

Combien de temps rester sur p=none ?

Assez longtemps pour que les rapports couvrent un cycle complet de vos envois – facturation mensuelle, campagne trimestrielle, relances de fin d’année comprises. Deux à six semaines pour un domaine ordinaire. Au-delà de trois mois, vous n’observez plus, vous stationnez.

Que faire des messages transférés qui échouent ?

Rien, en général. Un transfert casse SPF mais laisse DKIM intact : tant que vos messages sont signés, DMARC reste satisfait. C’est l’argument le plus concret en faveur de DKIM.

Mon domaine n’envoie aucun courrier. DMARC sert-il à quelque chose ?

Beaucoup, et c’est le cas le plus simple de tous. Un domaine sans expéditeur légitime peut recevoir p=reject immédiatement, sans phase d’observation. La page sur la réception détaille la configuration complète d’un domaine qui n’envoie ni ne reçoit.