DMARC pour les domaines .fr et .eu : guide pratique

Votre entreprise, votre association ou votre projet utilise une adresse comme [email protected]. Cette adresse apparaît sur votre site, vos factures et vos cartes de visite. Un fraudeur peut pourtant l’inscrire dans le champ visible « De » d’un e-mail sans accéder à votre boîte de réception.

DMARC permet au propriétaire du domaine d’indiquer aux serveurs destinataires comment traiter ces messages et de recevoir des rapports sur les usages du domaine. Le point essentiel est simple : un domaine .fr ou .eu n’utilise pas une version particulière de DMARC. Le format de l’enregistrement est le même que pour un .com ou un .org.

La difficulté consiste surtout à trouver la zone DNS qui fait autorité, puis à choisir une politique adaptée à l’usage réel du domaine.

Qui gère quoi pour votre domaine ?

Quatre acteurs sont souvent confondus :

• Le registre administre l’extension. L’Afnic gère le .fr et EURid gère le .eu. Le registre ne gère généralement pas votre configuration DMARC.
• Le bureau d’enregistrement, aussi appelé registrar, est l’entreprise auprès de laquelle vous avez enregistré ou renouvelé le domaine.
• L’hébergeur DNS exploite les serveurs de noms qui font autorité et contient la zone où vous ajoutez les enregistrements TXT.
• Le fournisseur de messagerie envoie ou reçoit vos e-mails. Il peut s’agir du même prestataire que le registrar ou d’un service distinct.

Ces rôles peuvent être réunis chez un seul fournisseur, mais ce n’est pas une règle. Vous pouvez avoir acheté entreprise.fr chez un registrar, délégué le DNS à un hébergeur web et confié les boîtes e-mail à Microsoft 365 ou Google Workspace.

Ajoutez l’enregistrement DMARC chez l’hébergeur des serveurs DNS qui font autorité. Modifier une zone restée chez le registrar ne produit aucun effet si les serveurs de noms actifs se trouvent ailleurs.

Dans l’interface de votre registrar, cherchez « serveurs DNS » ou « nameservers ». En ligne de commande, cette requête affiche les serveurs déclarés :

dig NS entreprise.fr

Le nom du serveur donne souvent un indice sur l’hébergeur DNS. En cas de doute, demandez au prestataire qui maintient votre site ou votre messagerie où la zone DNS est administrée.

La documentation française d’OVHcloud montre par exemple comment ajouter _dmarc dans une zone OVHcloud. Ces étapes ne valent que si OVHcloud héberge effectivement vos DNS. Posséder un .fr ou un .eu, ou avoir enregistré le domaine chez OVHcloud, ne suffit pas à le garantir.

Parcours 1 : le domaine envoie des e-mails

Ce parcours concerne un domaine utilisé par des personnes ou des logiciels : boîtes professionnelles, formulaire du site, facturation, newsletter, outil de réservation, CRM ou service d’assistance.

1. Inventoriez tous les outils d’envoi

Notez chaque service qui utilise une adresse visible en @entreprise.fr ou un sous-domaine comme @info.entreprise.fr. Ne vous limitez pas à la messagerie principale. Un site WordPress, une caisse, un logiciel comptable ou une ancienne plateforme marketing peut encore envoyer des messages.

Cette distinction évite une erreur fréquente : le domaine du site web n’est pas forcément le seul domaine d’envoi. Vérifiez l’adresse affichée dans le champ « De » des e-mails réels et les sous-domaines configurés par chaque fournisseur.

2. Vérifiez SPF et DKIM

DMARC s’appuie sur SPF et DKIM, avec une condition d’alignement entre le domaine authentifié et le domaine visible dans l’adresse « De ».

• SPF doit autoriser les serveurs qui envoient réellement pour le domaine concerné.
• DKIM doit signer les messages avec un domaine aligné et une clé publiée dans le DNS.

Chaque fournisseur de messagerie doit donner ses propres valeurs SPF et DKIM. Ne copiez pas l’enregistrement d’un autre prestataire. Vous pouvez utiliser le vérificateur de domaine gratuit pour voir les enregistrements déjà publiés, puis confirmer les valeurs attendues dans la documentation de chaque service d’envoi.

3. Publiez DMARC avec des rapports

DMARC est un enregistrement TXT placé sous le nom _dmarc. Pour entreprise.fr, le nom complet est _dmarc.entreprise.fr.

Un point de départ lisible est :

v=DMARC1; p=none; rua=mailto:[email protected];

Dans la plupart des interfaces DNS, saisissez :

Champ	Valeur
Type	TXT
Nom ou sous-domaine	_dmarc
Valeur	v=DMARC1; p=none; rua=mailto:[email protected];

Les trois éléments utiles ici sont :

• _dmarc est le nom réservé où les destinataires recherchent la politique.
• p=none demande la collecte d’informations sans demander la mise en quarantaine ou le rejet des échecs DMARC.
• rua indique l’adresse destinée aux rapports agrégés. Ces rapports XML résument les sources d’envoi et les résultats SPF, DKIM et DMARC.

Utilisez une adresse technique dédiée ou l’adresse fournie par un service de traitement des rapports. Évitez une boîte personnelle : les fichiers XML sont produits par de nombreux destinataires, ne sont pas conçus pour une lecture humaine et finissent par encombrer la boîte.

4. Observez avant de renforcer la politique

Lisez les rapports pour identifier chaque source légitime et corriger les défauts d’alignement. Une source inconnue n’est pas automatiquement un attaquant : il peut s’agir d’un outil oublié, d’un transfert ou d’un sous-domaine.

La RFC 9989, section 7.4 recommande une grande prudence avec p=reject pour les domaines utilisés par des personnes. Les listes de diffusion et certains transferts peuvent modifier le message et provoquer des échecs sur du courrier légitime. Pour un domaine de messagerie généraliste, la RFC déconseille donc p=reject et demande d’observer au moins un mois avec p=none, puis une durée comparable avec p=quarantine, avant d’envisager une politique plus stricte.

Le bon état final dépend du domaine. p=quarantine peut être le choix durable d’une petite entreprise dont les utilisateurs participent à des listes de diffusion. p=reject convient mieux à un domaine sans utilisateurs ou à un flux très contrôlé, correctement signé avec DKIM. Ne transformez pas la progression none → quarantine → reject en calendrier automatique.

Parcours 2 : le domaine n’envoie jamais d’e-mails

Un domaine redirigé vers un autre site, réservé pour protéger une marque, en attente de projet ou conservé après une campagne peut ne jamais envoyer d’e-mail. Il reste usurpable dans une adresse visible.

Dans ce cas, il n’y a aucun expéditeur légitime à découvrir. Vous pouvez publier des politiques défensives explicites :

@       TXT  "v=spf1 -all"
_dmarc  TXT  "v=DMARC1; p=reject; sp=reject;"

v=spf1 -all indique qu’aucun serveur n’est autorisé à envoyer pour ce nom. La politique DMARC demande le rejet des messages qui usurpent le domaine ou ses sous-domaines et échouent à DMARC.

Ne créez pas de configuration DKIM factice. DKIM sert à vérifier une signature apposée sur un message sortant. Un domaine qui n’envoie rien n’a ni message à signer ni sélecteur DKIM à publier.

Avant d’appliquer cette configuration, vérifiez tout de même les envois indirects : réinitialisation de mot de passe d’un ancien site, notifications d’un formulaire, factures ou redirections d’adresse. Si l’un de ces usages existe, revenez au premier parcours.

L’étude de l’Afnic publiée le 30 septembre 2025 insiste elle aussi sur la protection des domaines parqués. Elle mesure DMARC sur l’ensemble des domaines .fr, avec ou sans enregistrement MX à l’apex, contrairement à sa méthodologie antérieure limitée aux domaines dotés d’un MX. Dans cet ensemble, l’adoption de DMARC atteint 19,5 % en 2025. Ce chiffre décrit le .fr uniquement. Il ne permet pas d’estimer l’adoption sur les domaines .eu.

Les erreurs les plus courantes

Modifier la mauvaise zone DNS

Une modification n’est visible sur Internet que si elle est faite dans la zone servie par les serveurs DNS faisant autorité. Vérifiez cette délégation avant toute autre recherche de panne.

Créer deux enregistrements DMARC

Un domaine ne doit publier qu’un seul enregistrement DMARC au même nom. Deux réponses TXT commençant par v=DMARC1 provoquent une erreur permanente et la politique n’est pas appliquée. Modifiez l’enregistrement existant au lieu d’en ajouter un second.

Confondre domaine web et domaine d’envoi

Le site peut être sur entreprise.fr, la newsletter sur info.entreprise.fr et les factures envoyées par un service tiers. DMARC évalue le domaine visible dans l’adresse « De ». Inventoriez les messages, pas seulement les contrats d’hébergement.

Envoyer les XML vers une boîte personnelle

L’adresse rua reçoit des pièces jointes XML compressées, souvent une fois par jour et depuis plusieurs opérateurs. Utilisez une boîte technique séparée ou un service qui transforme ces données en listes de sources et en alertes compréhensibles.

Passer trop vite à une politique stricte

Une politique stricte ne corrige ni SPF ni DKIM. Elle augmente les conséquences d’une configuration incomplète. Analysez d’abord les rapports, corrigez chaque expéditeur légitime, puis évaluez p=quarantine. Pour les domaines de messagerie généralistes, ne supposez pas que p=reject est toujours l’objectif.

Vérifier et suivre la configuration

Après la modification, vérifiez la réponse TXT de _dmarc.votre-domaine depuis un résolveur public. Le vérificateur DMARC gratuit de DMARCTrust permet de contrôler l’enregistrement sans créer de compte.

Si vous activez rua, vous pouvez conserver les rapports dans une boîte technique et les traiter vous-même. Un service de suivi comme DMARCTrust est une option pour les rendre lisibles, regrouper les sources d’envoi et suivre les échecs dans le temps. Cette analyse ne remplace pas la correction des réglages SPF et DKIM chez chaque expéditeur.

FAQ

DMARC fonctionne-t-il différemment sur un .fr et un .eu ?

Non. Les mêmes enregistrements TXT et les mêmes règles DMARC s’appliquent. L’Afnic et EURid administrent des extensions différentes, mais la politique de votre domaine est publiée dans sa zone DNS faisant autorité.

Mon domaine est chez OVHcloud. Dois-je forcément modifier la zone OVHcloud ?

Non. OVHcloud peut être votre registrar sans héberger vos DNS. Regardez les serveurs de noms actifs. S’ils appartiennent à OVHcloud, suivez sa documentation. S’ils appartiennent à Cloudflare, Gandi, Infomaniak ou à un autre prestataire, faites la modification dans cette autre interface.

Que faire d’un domaine redirigé ou inutilisé ?

Une redirection web ne prouve pas que le domaine est inutilisé pour les e-mails. Vérifiez d’abord les formulaires, les boîtes et les services historiques. Si le domaine n’envoie réellement jamais, publiez une politique SPF -all et une politique DMARC défensive. Aucun DKIM n’est nécessaire.

Quand les premiers rapports DMARC apparaissent-ils ?

Les rapports ne commencent qu’après la publication de rua, la réception par un opérateur participant d’un message utilisant votre domaine, puis son cycle de génération de rapports. La RFC 9989 recommande aux opérateurs d’envoyer les rapports agrégés au moins quotidiennement. Laissez donc généralement 24 à 48 heures après du trafic réel avant de conclure à un problème. Tous les destinataires ne produisent pas de rapports, et un domaine qui n’envoie aucun message peut ne rien recevoir.

Faut-il publier immédiatement p=reject ?

Oui pour un domaine dont vous avez vérifié qu’il n’envoie jamais. Non par défaut pour un domaine utilisé par des personnes ou des applications. Commencez par les rapports, corrigez les sources légitimes et choisissez ensuite la politique adaptée aux risques de ce domaine.