DMARC sans panne de messagerie : commencez par observer une semaine

Pour réduire le risque de bloquer des e-mails légitimes, configurez SPF et DKIM au moins 48 heures avant DMARC, puis gardez p=none pendant une semaine en examinant les rapports chaque jour : c’est le calendrier recommandé par Google Workspace. Ne demandez la mise en quarantaine qu’après avoir identifié et corrigé les envois autorisés qui échouent au contrôle.

Avec p=none, votre domaine ne demande aucune sanction liée à un échec DMARC. Les destinataires conservent leurs autres filtres antispam : cette politique ne garantit donc pas la livraison de chaque message. Elle vous permet d’observer les résultats d’authentification avant qu’une règle plus stricte ne risque de toucher un formulaire, une facture ou une newsletter légitime.

Avant le jour J : préparer SPF et DKIM pour chaque expéditeur

Recensez tous les services qui affichent votre domaine dans l’adresse « De », y compris ceux qui envoient pour votre compte. La documentation Microsoft sur DMARC demande de préparer SPF et DKIM pour les domaines et sous-domaines d’envoi ; elle précise qu’un message réussit DMARC lorsqu’au moins un de ces mécanismes réussit avec un domaine aligné sur celui de l’adresse « De ». Un résultat SPF positif pour le domaine propre d’un prestataire ne suffit pas si votre domaine figure dans « De ».

Pour une PME, l’inventaire doit couvrir les boîtes des salariés et les adresses partagées, mais aussi les expéditeurs indirects :

• le site web, ses formulaires, confirmations de commande et liens de réinitialisation ;
• les plateformes de newsletter, de marketing et de gestion commerciale ;
• les outils de facturation, de réservation et d’assistance ;
• les applications métier et imprimantes qui expédient des messages ;
• les transferts et listes de diffusion par lesquels passent des messages déjà envoyés.

Pour chaque service, relevez le domaine visible dans « De », celui utilisé par SPF pour l’adresse de retour, le domaine de signature DKIM et la personne responsable. Autorisez dans SPF les sources réellement utilisées et activez une signature DKIM alignée lorsque le service le permet. Vérifiez les sous-domaines séparément : ils ont leurs propres besoins SPF et DKIM, tandis qu’une politique DMARC du domaine parent peut s’appliquer à ceux qui n’en publient pas.

Du jour J à la fin de la semaine : publier p=none

Dans la zone DNS du domaine, créez un enregistrement TXT au nom _dmarc. Exemple conditionnel pour example.com : v=DMARC1; p=none; rua=mailto:[email protected]. Le champ « v » indique la version, « p » la politique demandée et « rua » l’adresse de réception des rapports agrégés. Remplacez l’adresse d’exemple par une boîte dédiée, accessible à la personne qui suivra le déploiement.

Contrôlez que le TXT est visible dans le DNS et qu’un seul enregistrement DMARC est publié à ce nom. Vérifiez ensuite l’arrivée des rapports et classez quotidiennement les sources connues, les sources inexpliquées et les échecs des envois autorisés. Les rapports agrégés regroupent des résultats par source ; ils ne remplacent pas l’examen d’un message réel lorsqu’il faut comprendre précisément son trajet.

La semaine d’observation est un point de départ, pas une preuve que tous les flux sont couverts. Si la facturation ne part qu’en fin de mois ou si une campagne n’a pas encore été envoyée, attendez un envoi représentatif avant de durcir la règle. L’absence d’un destinataire dans les rapports ne prouve pas davantage que tous les messages reçus chez lui passent DMARC : la remontée des rapports dépend des systèmes de réception.

Dans les rapports : distinguer usurpation et expéditeur oublié

Pour chaque groupe de résultats, rapprochez l’adresse IP source et le volume de messages de votre inventaire, puis examinez séparément la réussite de SPF, celle de DKIM et leur alignement. Une source inconnue qui échoue peut correspondre à une usurpation. Une source reconnue qui échoue signale au contraire un flux à corriger avant la quarantaine.

Exemple conditionnel : une plateforme de newsletter utilise votre domaine dans « De », mais valide SPF avec son domaine et signe DKIM avec ce même domaine. SPF et DKIM peuvent réussir chacun de leur côté sans que le message réussisse DMARC. Demandez au prestataire une signature DKIM alignée sur votre domaine ou un domaine de retour compatible, puis contrôlez les envois suivants plutôt que de déduire la correction du seul changement de configuration.

Les transferts et listes de diffusion exigent une lecture distincte. Un transfert peut changer le chemin utilisé par SPF ; une liste qui modifie le contenu peut invalider une signature DKIM. Avant de ranger leur adresse IP parmi vos expéditeurs directs, retracez le parcours du message et regardez si le domaine affiché dans « De » et les résultats d’authentification ont changé.

Semaines suivantes : introduire la quarantaine avec prudence

Lorsque les envois légitimes observés passent DMARC, vous pouvez publier v=DMARC1; p=quarantine; rua=mailto:[email protected] pour le domaine concerné. La quarantaine demande un traitement plus strict des messages qui échouent, souvent leur placement dans le courrier indésirable. Continuez à lire les rapports et les signalements de non-réception pendant que cette politique est en place.

Un déploiement par pourcentage apparaît encore dans des exemples de configuration. Un TXT conditionnel tel que v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected] demande que la quarantaine porte sur une partie des échecs DMARC, et non sur une partie de tous vos e-mails. Mais la RFC 9989 classe désormais « pct » comme historique : son application à des valeurs intermédiaires s’est révélée inégale selon les destinataires. Ne traitez donc pas pct=10 comme une garantie que seuls 10 % des échecs seront touchés.

Un calendrier de travail possible consiste à consacrer la semaine suivante à la quarantaine sur un sous-domaine d’envoi bien inventorié, puis à élargir la politique aux autres sous-domaines et au domaine parent au fil des semaines suivantes. Si vous utilisez encore des paliers pct auprès de destinataires compatibles, confrontez chacun aux rapports et aux messages effectivement reçus ; passez à une quarantaine sans pct seulement lorsque les flux légitimes concernés sont couverts. Un service qui envoie rarement peut justifier de prolonger cette étape.

Passer au rejet quand les flux autorisés sont couverts

Réservez p=reject au domaine dont les sources légitimes passent DMARC, y compris les envois périodiques et les sous-domaines concernés par sa politique. Exemple conditionnel pour example.com : v=DMARC1; p=reject; rua=mailto:[email protected]. Le rejet demande au système destinataire de refuser les messages qui échouent ; une erreur d’alignement encore présente peut donc avoir une conséquence plus sévère qu’en quarantaine.

Gardez la réception des rapports active après ce changement et attribuez un responsable à l’ajout de tout nouveau prestataire d’envoi. Si un service autorisé apparaît en échec, corrigez son domaine de retour ou sa signature DKIM et vérifiez un nouvel envoi avant d’étendre la politique à d’autres domaines. C’est l’inventaire des flux et leur alignement constaté, plutôt que l’écoulement d’un nombre fixe de semaines, qui permettent de décider du rejet général.

À lire aussi :

• Choisir une IA pour sa TPE : commencez par les données, pas par la marque
• Premier financement : commencez par chiffrer les besoins du jour zéro
• Commentaires YouTube : la recherche par sens trouve enfin les vraies questions