DMARC : protégez votre domaine sans bloquer les mails métier

Vous voulez empêcher qu’on envoie de faux courriels avec votre domaine, mais le passage au rejet peut aussi bloquer vos propres factures. Voici comment déployer DMARC en vérifiant les expéditeurs métier avant de durcir la règle.

Je demande d’abord qui envoie au nom de l’entreprise. La réponse doit dépasser la messagerie des salariés. Le logiciel de facturation, le formulaire du site et l’outil de campagne commerciale méritent chacun une ligne. Sans cet inventaire, vous changez une règle dont vous ignorez les effets.

Faites nommer chaque expéditeur par le métier

Envoyez cette question à la comptabilité, au marketing, aux RH et au support : quels logiciels expédient des messages avec une adresse de notre domaine ? Demandez un message reçu à l’extérieur et le contact qui administre chaque service.

Construisez une fiche par flux : application, adresse visible, domaine utilisé, responsable métier, prestataire technique, fréquence d’envoi et conséquence d’un rejet. Ajoutez un exemple d’opération à tester. Une facture de test sans données client suffit pour démarrer.

N’oubliez pas les envois occasionnels. Une campagne annuelle peut être absente de toute votre période d’observation. Faites confirmer son existence par son propriétaire plutôt que d’attendre son prochain lancement.

Le coût à prévoir se trouve aussi ici : retrouver un accès oublié, faire intervenir l’intégrateur du logiciel de gestion, obtenir une réponse de l’agence. Demandez un devis qui sépare l’analyse des flux, les corrections et le suivi après changement. Une prestation limitée à l’ajout d’un enregistrement DNS laisse ce travail à votre équipe.

Exigez un résultat aligné, pas seulement un voyant vert

DMARC compare le domaine visible dans le champ From, affiché comme De, avec un domaine authentifié par SPF ou DKIM. La documentation Microsoft sur DMARC explique cette exigence d’alignement. Un contrôle SPF réussi pour le domaine du prestataire ne valide pas automatiquement votre propre domaine.

SPF vérifie l’autorisation du serveur pour le domaine de l’enveloppe d’envoi. DKIM vérifie une signature associée à un domaine. Pour réussir DMARC, il suffit que l’un de ces mécanismes réussisse avec l’alignement requis. Je demanderais néanmoins au fournisseur de configurer correctement les deux.

Faites envoyer un message depuis chaque application vers une boîte de test externe. Dans les en-têtes complets, examinez les résultats ajoutés par le serveur destinataire : SPF, DKIM, DMARC et domaines concernés. Conservez cette preuve avec la date et le flux testé.

Si le fournisseur répond que ses messages sont authentifiés, posez la question précise : avec quel domaine signez-vous les messages qui affichent notre adresse ? Demandez ensuite une démonstration sur votre configuration. Une capture de sa plateforme de démonstration ne répond pas à la question.

Commencez par observer, avec quelqu’un pour lire les rapports

Pour un domaine sans politique DMARC, le guide de configuration Google recommande de commencer avec p=none, puis de renforcer la politique. Cette valeur ne demande pas de traitement particulier des échecs DMARC ; les filtres habituels du destinataire restent actifs.

Voici un exemple à adapter, pour le nom DNS _dmarc.example.com :

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Remplacez le domaine et créez réellement la boîte destinataire. Si une politique existe déjà, examinez-la avant toute modification. Ne remplacez pas une protection active par cet exemple pour repartir de zéro.

Le paramètre rua désigne l’adresse des rapports agrégés. Attribuez leur lecture à une personne et prévoyez son relais. Une boîte qui accumule des pièces jointes sans analyse ne prépare aucune décision.

Les rapports donnent une vue partielle des envois observés par les destinataires participants. Complétez-les par vos essais et l’inventaire métier. Ne transformez pas chaque source inconnue en expéditeur autorisé : faites d’abord confirmer son usage.

Corrigez les prestataires avant de demander le rejet

Pour chaque flux légitime en échec, ouvrez une demande au fournisseur avec un message de test et ses résultats d’authentification. Faites préciser la correction attendue : signature DKIM avec votre domaine, domaine d’enveloppe adapté ou autre chemin d’envoi validé.

Refusez comme solution durable une demande adressée à tous vos clients pour qu’ils autorisent vos messages. Vous reporteriez chez eux la correction d’un problème que vous devez traiter avec votre fournisseur.

La spécification DMARC publiée par le RFC Editor décrit les politiques demandées au destinataire : none, quarantine et reject. Elle conserve au destinataire sa décision locale. Ces valeurs ne garantissent donc ni un classement identique partout ni la remise en boîte principale.

Préparez le passage à la quarantaine puis au rejet avec des critères écrits : flux indispensables testés, anomalies expliquées, responsable disponible et surveillance des retours d’erreur. Vérifiez aussi les sous-domaines et leurs politiques propres avant de modifier le domaine parent.

Un bon taux global ne compense pas une facture qui ne part plus.

Faites valider le test par le métier concerné, comme une recette avant mise en production. Une campagne commerciale réussie ne valide pas les relances comptables.

Préparez la correction avant le changement DNS

Conservez l’enregistrement précédent et identifiez la personne autorisée à le modifier. Vérifiez les accès chez l’hébergeur DNS ; notre article sur la maîtrise des noms de domaine détaille cette dépendance au prestataire.

Fixez une condition d’arrêt concrète : un flux indispensable échoue à cause de la nouvelle politique. Prévoyez alors la correction du flux ou un retour temporaire au réglage précédent, avec une échéance de reprise. Tenez compte des caches DNS : le changement ne devient pas visible partout instantanément.

Le retour arrière ne renvoie pas les messages déjà rejetés. Demandez au responsable applicatif de repérer les échecs et de décider quels envois reprendre, sans doublonner ceux qui ont abouti.

Enfin, ne vendez pas DMARC à la direction comme la fin des faux courriels. La spécification distingue cette protection de l’usurpation du nom affiché et des domaines ressemblants. Gardez les contrôles métier sur les demandes sensibles, même quand l’authentification réussit.

Lancez ces vérifications cette semaine

• Demandez aux métiers la liste de leurs applications expéditrices et un responsable par flux.
• Relevez la politique DMARC existante et vérifiez qui peut modifier le DNS.
• Faites tester les flux prioritaires vers des destinataires externes.
• Attribuez la lecture des rapports et chaque correction fournisseur.
• Programmez le durcissement seulement après validation des envois indispensables.
• Préparez le suivi des rejets et la reprise des messages en échec.

Ajoutez ensuite une exigence à toute nouvelle application qui envoie des courriels : aucun lancement avec votre domaine sans test d’authentification réussi et responsable identifié. C’est au moment de l’installation que cette exigence coûte le moins de discussions.