Configurer DMARC sans perturber les messages légitimes

Si vous cherchez comment configurer DMARC, voici l’essentiel : ne passez pas directement à p=reject. Commencez par une politique de surveillance, vérifiez que chaque expéditeur autorisé obtient un résultat SPF ou DKIM valide et aligné, puis renforcez les restrictions par étapes. Cette démarche peut réduire l’usurpation sans exposer inutilement les factures, les réinitialisations de mots de passe ou les messages d’un outil SaaS oublié.

Beaucoup de guides présentent une situation plus simple que la réalité. Un domaine envoie depuis Microsoft 365, la facturation passe par une application externe, le marketing utilise une autre plateforme et le photocopieur de l’entrepôt envoie encore des documents numérisés. Oublier un expéditeur peut transformer une mesure de sécurité en interruption de service. Pour la configuration générale du courrier, consultez la configuration des e-mails sur votre domaine et le guide du courrier professionnel.

Ce guide aborde DMARC du point de vue de l’exploitation : observer, réunir des éléments, corriger l’alignement, puis appliquer des restrictions. Il tient compte des risques concrets plutôt que de présenter le déploiement comme une formalité.

Ce que fait réellement DMARC

DMARC publie dans le DNS une politique indiquant aux serveurs destinataires le traitement demandé pour les messages utilisant votre domaine dans l’expéditeur visible mais ne réussissant pas l’authentification avec alignement. Il repose sur SPF et DKIM. DMARC réussit si au moins un de ces mécanismes réussit et s’aligne sur le domaine visible de From.

DMARC signifie Domain-based Message Authentication, Reporting, and Conformance. Il permet de publier une politique pour les messages qui échouent à DMARC et de demander des rapports sur l’utilisation de votre domaine comme expéditeur. La spécification de base est RFC 7489. Une authentification réussie ne garantit pas l’innocuité du contenu.

Pour comprendre la configuration de DMARC, retenez cette règle :

• SPF peut réussir sans que DMARC réussisse si le domaine authentifié n’est pas aligné sur From et que DKIM ne fournit pas non plus de résultat valide et aligné.
• DKIM peut réussir sans que DMARC réussisse pour la même raison, si SPF ne fournit pas le résultat valide et aligné manquant.
• DMARC réussit si SPF ou DKIM réussit sa vérification avec l’alignement requis. Un seul des deux suffit.

Les consignes de Google citées imposent aux expéditeurs en nombre SPF, DKIM et un enregistrement DMARC avec une politique minimale p=none. Pour réussir DMARC, SPF ou DKIM doit réussir avec l’alignement sur From. Vérifiez les exigences actuelles et leur champ d’application dans la FAQ des consignes d’envoi de Google.

Les vérifications préalables à DMARC

Avant de publier une politique DMARC, vérifiez votre configuration d’envoi. Un SPF incorrect, l’absence de DKIM ou une signature utilisant un autre domaine peuvent entraîner des échecs DMARC. Les détecter est utile ; appliquer des restrictions avant de les résoudre peut perturber le courrier légitime.

Commencez par ces trois vérifications.

1. SPF : publiez un seul enregistrement SPF valide pour chaque domaine réellement utilisé dans l’expéditeur d’enveloppe. Respectez la limite de 10 mécanismes ou modificateurs déclenchant des recherches DNS, y compris dans les évaluations imbriquées ; ce n’est pas une limite du nombre total de requêtes DNS.
2. DKIM : activez-le sur les plateformes d’envoi qui le permettent. Utilisez des clés de 2048 bits lorsque le fournisseur et sa configuration les prennent en charge.
3. Inventaire : répertoriez tous les services envoyant avec votre domaine : messagerie, CRM, facturation, assistance, formulaires, scanners et outils marketing.

Pour les domaines TrekMail, consultez les enregistrements DNS requis et l’ajout d’un domaine. Les contrôles disponibles peuvent détecter des enregistrements publiés et des erreurs courantes comme les doublons SPF, sans remplacer la vérification des messages réels et des réponses DNS externes.

Exemple : votre application de facturation envoie depuis billing@yourdomain.com, mais signe avec le domaine du fournisseur et utilise son return-path. SPF et DKIM réussissent pour ces domaines, sans être alignés sur le vôtre. DMARC échoue pour votre domaine.

Ce défaut d’alignement explique de nombreuses interruptions après l’activation de restrictions DMARC.

Étape 1 : publier une politique DMARC de surveillance

Pour un déploiement progressif, il est souvent utile de commencer par observer. Une politique p=none demande des rapports sans demander la mise en quarantaine ou le rejet au titre de DMARC. Les rapports ne sont pas garantis et les destinataires peuvent continuer à appliquer leurs filtres locaux.

Créez un enregistrement TXT sur _dmarc.yourdomain.com avec cette valeur :

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

Voici le même enregistrement au format d’un fichier de zone, et non un enregistrement supplémentaire :

_dmarc  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Cet exemple reprend le format de RFC 7489. Utilisez une adresse ou un alias dédié et surveillé, avec des règles d’accès et de traitement adaptées. Les rapports agrégés sont des fichiers XML qui peuvent rapidement s’accumuler. Une destination externe peut nécessiter une autorisation DNS dans le domaine recevant les rapports.

Après publication, vérifiez les réponses DNS et l’authentification de messages envoyés par chaque service. La FAQ sur les messages classés comme spam peut aussi aider à distinguer les effets du transfert d’autres problèmes.

Étape 2 : lire les rapports et identifier les expéditeurs

Cette étape est souvent négligée. Les rapports fournissent des données provenant des destinataires participants, pas un inventaire complet de tous les messages. Ils aident à examiner les services autorisés, les erreurs de configuration et les usurpations possibles, mais ne permettent pas à eux seuls de classer un trafic comme légitime ou abusif.

Les rapports DMARC présentent généralement :

• Les IP sources ayant envoyé des messages avec votre domaine
• Les résultats SPF
• Les résultats DKIM
• L’alignement de ces résultats sur le domaine de From
• Le traitement appliqué par le destinataire

Distinguez deux groupes à examiner.

D’abord, les expéditeurs autorisés dont l’alignement échoue : leur configuration doit être corrigée. Ensuite, les sources que vous ne reconnaissez pas encore. Une IP inconnue peut correspondre à un transfert ou à une infrastructure partagée ; elle ne prouve pas une usurpation.

Ces cas sont illustratifs : les résultats dépendent de la configuration et du message :

Avec de nombreux domaines, chaque nouvel outil SaaS impose une vérification de l’envoi. C’est pourquoi certaines agences étudient l’hébergement de messagerie multidomaine et une gestion plus structurée des boîtes. Changer de plateforme ne supprime pas ces tâches.

Étape 3 : corriger l’alignement, pas seulement l’authentification

DMARC exige un résultat réussi et aligné. SPF ou DKIM peut réussir avec un autre domaine sans contribuer à DMARC ; il suffit toutefois que l’autre mécanisme réussisse avec alignement. En mode souple, le domaine authentifié doit partager le même domaine organisationnel que From, et non simplement avoir une relation quelconque de domaine parent ou enfant.

RFC 7489 définit l’alignement souple par le même domaine organisationnel entre le domaine authentifié par SPF ou signataire DKIM et le domaine de RFC5322.From. La FAQ de Google indique qu’un mécanisme valide et aligné suffit pour DMARC, même si les expéditeurs en nombre doivent configurer les deux méthodes.

Voici les corrections habituelles :

• Plateformes marketing : configurez une signature DKIM utilisant votre domaine.
• Gestion des retours : configurez un return-path ou un domaine de rebond personnalisé si le fournisseur le permet, puis vérifiez l’alignement.
• Microsoft 365 : activez DKIM pour votre domaine personnalisé avant les restrictions, si vous choisissez ce mécanisme pour l’alignement.
• Envoi géré par TrekMail : publiez exactement les enregistrements SPF et DKIM indiqués pour le service sortant réellement utilisé.

La configuration doit correspondre au service d’envoi réel. Les offres facturées par utilisateur peuvent également fournir des outils DNS. TrekMail propose de séparer les boîtes du moteur d’envoi, avec le SMTP géré sur les offres payantes concernées ou votre propre SMTP sur Nano selon les conditions du plan. Le fournisseur SMTP choisi doit être configuré et vérifié.

Dans l’offre décrite, Nano utilise votre fournisseur SMTP et les plans payants incluent le SMTP géré. TrekMail présente des tarifs à partir de $3.50 par mois, un essai de 14 jours sur les plans payants soumis à ses conditions et Nano sans frais ni carte selon l’offre applicable. Vérifiez les conditions de l’essai et les fonctionnalités actuelles sur la page des tarifs TrekMail.

Étape 4 : envisager une politique de quarantaine

Une fois les expéditeurs autorisés authentifiés et alignés et les flux importants validés, vous pouvez envisager la quarantaine. Il s’agit déjà d’une politique restrictive qui demande un traitement particulier pour les messages échouant à DMARC. Le destinataire décide de son application : aucune garantie de dossier spam précis, de récupération du message ou d’adéquation à tous les domaines.

Remplacez la politique précédente par celle-ci, sans publier les deux :

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Pourquoi envisager la quarantaine avant le rejet ?

• Elle peut réduire l’exposition à certaines tentatives d’usurpation.
• Elle peut permettre d’examiner des erreurs avec un traitement moins strict, sans garantir la récupération des messages.
• Elle permet de tester une étape restrictive, avec une évaluation des risques et un suivi des flux critiques.

Combien de temps observer ? Cela dépend de vos flux. Quelques semaines peuvent constituer un premier repère pour un petit domaine ; 30 jours pour un domaine avec de nombreux fournisseurs restent aussi un repère, pas une preuve que le déploiement est prêt.

Vérifiez également les systèmes rarement utilisés : un module WordPress, un environnement de test du CRM, un ancien photocopieur ou un fournisseur envoyant chaque mois. Les processus trimestriels ou exceptionnels peuvent demander davantage de temps et des tests spécifiques. La quarantaine n’est pas un filet de sécurité garanti.

Étape 5 : passer au rejet après validation des flux

La politique p=reject demande au destinataire de refuser les messages échouant à DMARC, plutôt que de simplement les traiter comme suspects. Elle peut réduire l’usurpation directe du domaine, sans bloquer toutes les formes de fraude.

La politique de cette étape prend généralement cette forme :

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Selon RFC 7489, p=reject demande le rejet des messages échouant à DMARC. Les destinataires peuvent appliquer des exceptions et des politiques locales : ni le blocage universel ni la remise des messages légitimes dans la boîte de réception ne sont garantis.

Avant de poursuivre, vérifiez les points suivants :

• Votre fournisseur principal réussit SPF ou DKIM avec alignement
• Vos outils marketing et transactionnels réussissent aussi un mécanisme aligné
• Vous avez examiné plusieurs semaines de rapports et testé les flux critiques peu fréquents
• Vous comprenez les échecs restants et leurs conséquences

Continuez ensuite à examiner les rapports disponibles et à tester les changements. DMARC fait partie de la gestion continue de la messagerie.

Les erreurs courantes qui perturbent les messages

Connaître les politiques ne suffit pas : il faut connaître les expéditeurs. Un service oublié, un SPF en double, DKIM désactivé ou l’authentification par défaut d’un fournisseur peuvent provoquer des échecs lors de l’application de restrictions. La politique de surveillance ne crée pas à elle seule ces échecs.

• Appliquer des restrictions avant de disposer de SPF ou DKIM valide et aligné
• Publier plusieurs SPF au lieu de réunir les autorisations dans un seul enregistrement valide
• Supposer qu’un SPF réussi implique un DMARC réussi
• Oublier les fournisseurs à faible volume dont les messages peuvent être critiques
• Passer directement de l’absence de DMARC à p=reject
• Envoyer les rapports vers une boîte que personne ne surveille

Avec les alias et les transferts, SPF peut échouer tandis que DKIM permet encore à DMARC de réussir, à condition que la signature reste valide, alignée et que les données signées soient préservées après canonicalisation. N’ignorez pas automatiquement ces échecs. Consultez le transfert avec des alias e-mail et la messagerie sécurisée pour les entreprises pour élargir votre examen opérationnel.

Une liste pratique pour configurer DMARC

Cette liste résume un déploiement progressif. Elle organise les vérifications, sans garantir une transition sans incident.

1. Recensez tous les systèmes envoyant avec votre domaine.
2. Publiez un seul SPF valide pour chaque domaine d’enveloppe concerné.
3. Activez et vérifiez DKIM sur chaque plateforme compatible.
4. Publiez v=DMARC1; p=none; rua=mailto:....
5. Examinez les rapports en les confrontant à votre inventaire des expéditeurs.
6. Vérifiez un mécanisme valide et aligné pour chaque expéditeur autorisé.
7. Envisagez p=quarantine après avoir testé les flux.
8. Examinez à nouveau les rapports et le fonctionnement réel.
9. Passez à p=reject lorsque les tests et l’évaluation des risques le justifient.

Conclusion : configurer DMARC avec un déploiement maîtrisé

Une séquence courante consiste à commencer par p=none, à confronter les rapports à l’inventaire, à corriger l’authentification et l’alignement, puis à envisager p=quarantine et p=reject. Elle peut réduire les risques associés aux restrictions contre l’usurpation, mais exige des tests et un suivi.

La coordination peut rester simple avec un domaine ; avec des dizaines ou des centaines, les processus doivent être plus structurés. Selon le plan et l’offre actuelle, TrekMail propose des domaines personnalisés, des boîtes IMAP, un catch-all, le transfert, des outils de migration et votre propre SMTP ou un SMTP inclus. La copie IMAP ne remplace pas le changement de MX et ne migre pas automatiquement toutes les applications. Vérifiez les limites et les tarifs : ces outils ne dispensent pas de configurer DMARC et ne garantissent pas d’économies par rapport à une facturation par utilisateur.

Voilà l’approche opérationnelle pour configurer DMARC : observer, vérifier les expéditeurs, puis appliquer des restrictions. Appuyez vos décisions sur les rapports disponibles et des tests réels, pas sur des suppositions.