Un cabinet comptable de Saint-Julien-en-Genevois envoie ses relances de fin de mois un jeudi soir. Le lundi suivant, trois clients signalent qu'ils n'ont rien reçu, et l'un d'eux retrouve la facture dans ses courriers indésirables. Le commercial en conclut que les filtres de Gmail sont devenus trop sévères, le dirigeant soupçonne l'hébergeur du site. Personne n'a pourtant touché à la messagerie : le domaine de l'entreprise envoie du courrier depuis quatre endroits différents, et le DNS n'en déclare qu'un seul.
Nous rencontrons cette situation après une migration de messagerie, après un changement d'hébergeur, ou sur un site qui expédie ses formulaires par la fonction d'envoi de PHP. Le symptôme est commercial, la cause tient dans trois enregistrements DNS que personne ne relit jamais. Nous traitons ce sujet dans la gestion des messageries professionnelles, parce qu'il ne se règle pas en cochant une case dans Outlook.
Ce que fait exactement chacun des trois mécanismes
Les trois sigles répondent à trois questions distinctes, et c'est leur combinaison qui construit la confiance du destinataire.
Le SPF (Sender Policy Framework) déclare, dans une entrée DNS de votre domaine, la liste des serveurs autorisés à envoyer du courrier en votre nom. Quand un message se présente, le serveur du destinataire regarde l'adresse IP qui le lui remet et vérifie qu'elle figure dans cette liste. Si votre messagerie, votre site vitrine, votre outil d'emailing et votre copieur envoient chacun de leur côté alors que le SPF n'en cite qu'un, les trois autres passent pour des usurpateurs. Cet enregistrement souffre d'une limite pratique : le destinataire ne suit qu'un nombre restreint de renvois vers d'autres domaines, ce que l'on appelle les lookups. Un SPF qui empile les directives include: finit par dépasser ce plafond et devient invalide dans son ensemble.
La signature DKIM (DomainKeys Identified Mail) répond à une autre question : le message reçu est-il bien celui qui a été émis ? Le serveur d'envoi calcule une signature cryptographique sur les en-têtes et le corps du message, et le destinataire récupère la clé publique dans votre DNS pour vérifier que rien n'a été altéré en route. Cette signature survit à une redirection, là où le SPF échoue puisque l'adresse IP du dernier relais n'est plus la vôtre. Chaque plateforme qui envoie pour vous publie sa propre clé.
La politique DMARC (Domain-based Message Authentication, Reporting and Conformance) ne vérifie rien par elle-même. Elle indique au destinataire ce qu'il doit faire quand le SPF et la signature DKIM échouent tous les deux, et lui donne une adresse à laquelle envoyer ses rapports. Trois consignes existent : p=none demande de laisser passer en rapportant, p=quarantine demande de basculer le message en indésirables, p=reject demande de le refuser à la porte. DMARC ajoute une exigence d'alignement : le domaine que votre correspondant voit à l'écran doit correspondre à celui validé par le SPF ou par la signature. Un envoi peut donc être authentifié et échouer quand même au contrôle, parce que l'enveloppe technique porte le domaine du prestataire.
Pourquoi une politique stricte posée le premier jour bloque vos envois légitimes
La tentation est forte de publier directement p=reject, puisque c'est la position qui protège le mieux votre nom contre l'usurpation. C'est aussi la manière la plus sûre de faire disparaître des messages dont vous avez besoin.
Le copieur du couloir en donne l'exemple le plus fréquent. Il numérise un bon de livraison et l'expédie vers la comptabilité au nom du domaine de l'entreprise, sans signature et depuis une connexion rarement déclarée au SPF. Avec un rejet, ce flux disparaît sans message d'erreur lisible pour l'utilisateur, et personne ne fait le lien avec la modification DNS de la semaine précédente. Nous détaillons ce cas dans notre article sur le scan vers mail du copieur. Le même raisonnement vaut pour un logiciel de facturation, pour l'alerte d'un NAS ou pour un formulaire de site jamais raccordé à la messagerie authentifiée.
C'est pour cette raison que nous avançons par étapes. Nous publions d'abord une politique en p=none accompagnée d'une adresse de rapports, nous laissons passer plusieurs semaines afin de couvrir un cycle de facturation complet, puis nous lisons ce que les destinataires nous renvoient. Ces rapports énumèrent les adresses IP qui ont envoyé sous votre nom et le résultat des vérifications pour chacune. Ils séparent donc vos propres outils oubliés, qu'il faut déclarer, des envois qui ne sont pas de vous. Une fois la première catégorie traitée, le passage en quarantaine puis en rejet devient une formalité sans risque commercial.
Les configurations qui expliquent la majorité des cas que nous reprenons
Quatre situations reviennent, souvent combinées.
- Le site envoie ses formulaires par la fonction d'envoi de PHP, depuis l'adresse IP mutualisée de l'hébergeur, alors que la boîte officielle est ailleurs. Le message part, mais rien ne l'authentifie. Nous décrivons ce mécanisme dans notre article sur le formulaire qui dit merci sans que le mail arrive.
- Un outil d'emailing a été branché sans publier sa clé de signature ni compléter le SPF. Les premières campagnes passent, puis un filtre se resserre et la délivrabilité s'effondre alors que rien n'a changé chez vous.
- Une migration de messagerie a laissé les anciens enregistrements en place. Le DNS contient deux versions concurrentes de la vérité, et le destinataire retient la plus défavorable.
- Le domaine principal est correctement configuré, mais un sous-domaine utilisé par un service métier ne l'est pas. Comme il hérite de la politique du parent, ses messages se font rejeter sans que personne ne le remarque.
Pour un dirigeant, un test simple donne une direction. Envoyez le même devis vers une adresse Gmail, vers une boîte Outlook.com et vers un client hébergé en Suisse, puis demandez à chacun où le message a atterri. Trois échecs désignent le DNS, un échec unique désigne la réputation de l'adresse IP d'envoi.
L'inventaire des émetteurs, l'étape que l'on saute presque toujours
Le travail utile ne commence pas dans le DNS, il commence sur un relevé des flux réels. Nous listons chaque système qui envoie du courrier sous votre nom : la messagerie, le site, l'outil de devis, le logiciel de paie, le copieur, la supervision du serveur, la signature électronique. Cette liste est plus longue que ce que le dirigeant imagine, et c'est elle qui détermine le contenu du SPF.
Il faut ensuite distinguer ce que l'authentification règle de ce qu'elle ne réglera jamais. Elle prouve votre identité, donc elle retire un motif de rejet. Elle ne compense pas un contenu qui ressemble à une publicité, ni un correspondant qui vous a classé en indésirable. Elle ne protège pas ce que vous recevez : les faux fournisseurs et les demandes de changement de coordonnées bancaires relèvent du filtrage en amont, décrit dans notre offre d'antispam.
Notre séquence pour authentifier un domaine sans couper un flux
- Nous relevons les domaines et sous-domaines en service, puis nous cartographions les émetteurs réels avec la personne qui utilise chaque outil.
- Nous lisons les en-têtes complets d'un message qui a échoué, ce qui indique lequel des trois contrôles a échoué et pour quelle raison.
- Nous reconstruisons un SPF unique et valide, sous la limite de lookups, et nous activons la signature DKIM sur chaque plateforme qui le permet.
- Nous publions DMARC en surveillance avec une adresse de rapports, nous observons un cycle de facturation entier, puis nous durcissons en quarantaine et enfin en rejet.
- Nous documentons le résultat, afin que le prochain outil raccordé passe par le même contrôle.
Ce suivi vit dans un contrat d'infogérance à partir de 120 HT / mois, parce qu'un domaine correctement authentifié se dérègle dès qu'un nouvel outil est branché sans prévenir. Une remise en service dans l'urgence, hors contrat, se facture 230 HT / h. Le DNS se traite à distance, et nous nous déplaçons dans le Bassin Genevois quand le copieur ou le serveur d'envoi demandent une vérification sur place.
Nous ne promettons pas qu'aucun message ne partira plus jamais en indésirables, car le contenu et la réputation d'une plage d'adresses restent hors de notre portée. Nous garantissons en revanche que votre domaine cesse d'être utilisable par n'importe qui et que vos outils légitimes sont nommés. Si vos devis disparaissent, transmettez-nous l'en-tête complet d'un message qui a échoué. Nous vous dirons s'il s'agit du DNS, de l'hébergement du site, ou d'un émetteur que personne n'avait recensé.