DMARC en quatre semaines : passer à p=reject sans bloquer vos propres e-mails

Ce qu'est DMARC et où en sont les hôtels

DMARC (Domain-based Message Authentication, Reporting and Conformance) est une ligne de texte dans le DNS de votre domaine, l'annuaire public d'internet pour les noms de domaine. Elle indique aux serveurs destinataires ce qu'ils doivent faire d'un message qui utilise votre domaine dans l'adresse d'expéditeur (le champ From) mais ne peut pas prouver qu'il vient de vous. Dans notre indice e-mail des hôtels, qui porte sur 732 domaines d'hôtels flamands mesurés le 28 septembre 2026, 52,7 % n'avaient aucun enregistrement DMARC valide et 34,3 % étaient en p=none, un réglage qui demande aux serveurs destinataires de ne rien faire. Au total, 87,0 % ne donnaient donc aucune instruction pour bloquer un e-mail falsifié. Seuls 7,2 % étaient en p=quarantine et 5,7 % en p=reject, et 157 des 251 domaines en p=none n'avaient pas non plus demandé de rapports. Le Centre pour la Cybersécurité Belgique et DNS Belgium citent SPF, DKIM et DMARC dans leurs lignes directrices communes contre la fraude par e-mail (DNS Belgium). Notre contrôle de la sécurité e-mail montre où en est votre domaine et explique comment fonctionne l'usurpation d'adresse e-mail.

Semaine 1 : listez chaque expéditeur et faites le ménage dans SPF

SPF (Sender Policy Framework) est un enregistrement DNS qui liste les services autorisés à envoyer des e-mails pour votre domaine. DKIM (DomainKeys Identified Mail) appose une signature numérique sur chaque message, vérifiée à l'aide d'une clé publique publiée dans votre DNS. Un message passe DMARC quand SPF ou DKIM réussit pour un domaine qui correspond à celui de l'adresse d'expéditeur que voit votre client. Cette correspondance s'appelle l'alignement (RFC 9989, section 4.4).

Notez tout ce qui envoie des e-mails avec votre domaine dans l'adresse d'expéditeur :

• les boîtes mail dans Microsoft 365 ou Google Workspace
• votre moteur de réservation
• votre logiciel de gestion hôtelière ou de réception
• votre logiciel de facturation ou de comptabilité
• votre outil d'envoi de lettres d'information
• le formulaire de contact du site, un scanner qui envoie des documents par e-mail, les alertes d'alarme ou de caméras
• une agence ou un comptable qui envoie des e-mails en votre nom

Demandez à chaque fournisseur de quels enregistrements DNS il a besoin pour SPF et DKIM.

Un enregistrement SPF est un enregistrement TXT qui commence par v=spf1, et chaque service externe y est généralement ajouté par une entrée include:, par exemple include:spf.protection.outlook.com pour Microsoft 365. Votre domaine ne peut avoir qu'un seul enregistrement SPF ; s'il en a deux, SPF échoue avec une erreur permanente (RFC 7208, section 4.5). SPF autorise aussi au maximum 10 recherches DNS (RFC 7208, section 4.6.4). Chaque include en coûte au moins une, et les include imbriqués à l'intérieur comptent aussi. Un enregistrement qui dépasse cette limite échoue avec une erreur permanente (Microsoft). Retirez les services que vous n'utilisez plus. Microsoft recommande de faire partir le courrier de masse, comme une lettre d'information, d'un sous-domaine tel que news.votrehotel.be, qui a son propre enregistrement SPF et ses propres 10 recherches.

Semaine 2 : DKIM pour chaque expéditeur, puis DMARC en p=none

Microsoft 365 ne signe pas avec DKIM les e-mails de votre propre domaine tant que vous ne l'avez pas configuré. Le portail Defender vous donne deux enregistrements CNAME (selector1._domainkey et selector2._domainkey) à créer chez votre hébergeur DNS, puis vous activez la signature (Microsoft). Un enregistrement CNAME fait pointer un nom vers un autre : le fournisseur garde ainsi la clé et peut la remplacer. Dans Google Workspace, vous générez une clé dans la console d'administration (de 2048 bits si votre hébergeur DNS l'accepte), vous publiez l'enregistrement TXT qu'elle affiche et vous cliquez sur « Lancer l'authentification ». Selon Google, DKIM peut mettre jusqu'à 48 heures à fonctionner (Google).

Faites de même pour chaque expéditeur externe. Beaucoup demandent des enregistrements CNAME sous _domainkey, ce qui leur permet de renouveler la clé sans vous le demander (M3AAWG, section 3.1.3). Si vous supprimez plus tard un CNAME, vous retirez l'autorisation de cet expéditeur. Un service qui signe uniquement avec son propre domaine et utilise sa propre adresse de retour ne sera jamais aligné. Demandez-lui s'il peut signer avec votre domaine, ou utiliser une adresse de retour sur votre domaine (ce qu'on appelle souvent un MAIL FROM personnalisé).

Google conseille d'attendre 48 heures après SPF et DKIM avant de publier DMARC (Google). Ajoutez ensuite un enregistrement TXT nommé _dmarc avec cette valeur :

v=DMARC1; p=none; rua=mailto:dmarc@votrehotel.be

En p=none, la distribution des e-mails ne change pas. La balise rua demande aux serveurs destinataires d'envoyer des rapports agrégés, des résumés quotidiens de qui a envoyé des e-mails en votre nom ; utilisez donc une boîte mail réservée à cet usage. Si cette boîte se trouve dans un autre domaine, cet autre domaine doit publier un enregistrement qui l'autorise (RFC 9990, section 4). Réglez le TTL (time to live, la durée pendant laquelle d'autres serveurs peuvent garder l'enregistrement en cache) sur une heure, pour que les modifications et un éventuel retour en arrière prennent effet rapidement.

Depuis février 2024, Gmail exige des expéditeurs qui envoient plus de 5 000 messages par jour vers des adresses Gmail personnelles qu'ils aient SPF, DKIM, un enregistrement DMARC (p=none suffit), un domaine d'expéditeur aligné sur SPF ou DKIM, et un lien de désabonnement en un clic (Google). Yahoo impose les mêmes règles aux expéditeurs de masse, mais sans donner de chiffre (Yahoo, FAQ). Depuis le 5 mai 2025, Microsoft exige SPF, DKIM et un DMARC aligné des expéditeurs qui envoient plus de 5 000 messages par jour vers des adresses Outlook.com, Hotmail et Live, et rejette les e-mails qui échouent avec l'erreur 550 5.7.515 (Microsoft). Une lettre d'information envoyée à toute votre liste de clients peut franchir ce seuil.

Semaines 2 et 3 : lisez les rapports et corrigez ce qui échoue

Les rapports arrivent sous la forme d'un fichier XML, généralement compressé, joint à un e-mail, en général une fois par jour de la part de chaque grand fournisseur de messagerie. Chaque ligne indique une adresse IP d'envoi, un nombre de messages, si SPF et DKIM ont réussi, et s'ils étaient alignés sur votre domaine (RFC 9990, section 3.1). Une fois décompressé, le fichier s'ouvre dans un navigateur, et l'outil gratuit et open source parsedmarc, qui s'utilise en ligne de commande, peut rassembler de nombreux rapports dans un seul tableau (un fichier CSV).

Parcourez les lignes un expéditeur à la fois (Microsoft) :

• Un service que vous connaissez réussit SPF ou DKIM mais échoue quand même à DMARC. Il signe ou envoie avec son propre domaine ; configurez-y DKIM avec votre domaine.
• Un service que vous connaissez échoue aux deux. Il manque dans SPF et n'a pas de DKIM ; ajoutez les deux.
• Une adresse IP d'envoi que vous ne reconnaissez pas échoue partout. C'est souvent quelqu'un qui usurpe votre domaine, et ce sont précisément les e-mails que quarantine et reject doivent arrêter.
• Les e-mails transférés échouent à SPF, parce que le serveur qui les transfère ne figure pas dans votre enregistrement. DKIM résiste généralement au transfert, une raison de plus pour que chaque expéditeur signe.

Vous êtes prêt pour la semaine 4 quand chaque service que vous utilisez affiche un DKIM ou un SPF aligné sur au moins une semaine de rapports. La norme prévient que cela peut prendre de nombreux mois quand certains e-mails ne partent que de temps en temps (RFC 9989, section 5.1.7). Si vos factures partent une fois par mois, attendez d'avoir vu cet envoi réussir, même si le plan s'allonge.

Semaine 4 : quarantaine, puis rejet

Passez l'enregistrement à p=quarantine. Les e-mails qui échouent arrivent alors en général dans le dossier spam. Surveillez les rapports pendant quelques jours et demandez à la réception si des clients signalent des confirmations manquantes. Quand tout est en ordre des deux côtés, passez à p=reject, qui demande aux serveurs destinataires de refuser les e-mails qui échouent. Le RFC 9989 est plus prudent pour les domaines dont les utilisateurs écrivent sur des listes de diffusion : il conseille au moins un mois en p=none, puis autant en p=quarantine, avant de passer à p=reject (section 7.4). Si votre personnel utilise des listes de diffusion, prenez cette voie plus lente. Vous pouvez aussi terminer dès maintenant votre enregistrement SPF par -all au lieu de ~all, comme Microsoft le recommande une fois DKIM et DMARC en place.

Le RFC 9989, publié en mai 2026, a remplacé le RFC 7489 et supprimé la balise pct, qui appliquait une politique à un pourcentage des e-mails. Il a ajouté une balise de test : avec t=y, les serveurs destinataires sont invités à appliquer un niveau de moins, de sorte que p=reject avec t=y est traité comme une quarantaine (section 4.7 et annexe A.6). Les serveurs destinataires qui suivent encore l'ancienne norme ignorent les balises qu'ils ne connaissent pas et appliquent la politique complète ; n'utilisez donc t=y qu'une fois les rapports propres.

Ce qui peut mal tourner, et comment revenir en arrière

• Un expéditeur oublié, par exemple un outil qui envoie des e-mails une fois par trimestre, arrive dans les spams ou revient en erreur. Ajoutez-le à SPF et à DKIM.
• Un e-mail que l'adresse d'un client fait suivre ailleurs, ou qui passe par une liste de diffusion, peut échouer à DMARC. Le RFC 9989 traite de ces cas et précise qu'un domaine en p=reject doit signer ses e-mails avec DKIM, car SPF seul ne tient pas quand un e-mail est transféré (section 7.4).
• Une faute de frappe peut amener les serveurs destinataires à signaler une erreur ou à ignorer une partie de l'enregistrement, et quand un domaine a deux enregistrements DMARC, ils les écartent tous les deux (Microsoft, RFC 9989, section 4.10).
• Un nouveau moteur de réservation ou un nouvel outil d'envoi de lettres d'information commence à envoyer avant que son SPF et son DKIM soient configurés.

Revenir en arrière tient en une seule modification DNS : repassez de p=reject à p=quarantine ou à p=none. Avec un TTL d'une heure, les serveurs destinataires prennent en compte le changement en une heure environ. Gardez l'adresse rua à chaque étape, pour que les rapports montrent ce qui s'est passé.

Ce que DMARC n'arrête pas

DMARC protège votre propre nom de domaine et ses sous-domaines. Un domaine similaire enregistré par quelqu'un d'autre, avec un mot en plus ou une lettre changée, peut réussir tous les contrôles pour son propre nom. Notre contrôle des noms de domaine similaires montre quelles variantes proches de votre domaine sont utilisées. DMARC ne voit pas non plus qu'une vraie boîte mail a été piratée, car les e-mails envoyés depuis un compte piraté viennent réellement de vos systèmes. La vérification en deux étapes sur chaque boîte mail rend cela beaucoup plus difficile, et notre article sur les fausses demandes de paiement via Booking.com explique ce que la réception peut faire.

Liste de contrôle

1. Listez chaque service qui envoie des e-mails avec votre domaine.
2. Un seul enregistrement SPF, moins de 10 recherches DNS, chaque expéditeur inclus.
3. DKIM activé dans Microsoft 365 ou Google Workspace et chez chaque expéditeur externe.
4. DMARC en p=none, rua vers une boîte mail dédiée, TTL d'une heure.
5. Rapports lus jusqu'à ce que chaque expéditeur connu soit aligné pendant une semaine entière.
6. p=quarantine pendant quelques jours, puis p=reject, et SPF terminé par -all.
7. Le contrôle de la sécurité e-mail relancé après chaque modification.