Pourquoi votre helpdesk perd des emails : SPF, DKIM, DMARC et le joker qui n'existe pas

« Un client dit qu'il a écrit, on n'a rien reçu. » C'est la panne la plus fréquente d'une mise en service de helpdesk, et c'est aussi celle qui se diagnostique le plus mal, parce qu'elle a six causes possibles et que cinq d'entre elles sont silencieuses.

Ce texte les prend dans l'ordre du chemin d'un email, du DNS jusqu'au ticket. Il contient un détail d'intégration que nous avons découvert en construisant la nôtre, et qui invalide une bonne partie des tutoriels disponibles.

Le détail qui casse la moitié des tutoriels : il n'y a pas de joker

L'idée intuitive, celle que suggèrent la plupart des guides, est de router `*@support.exemple.fr` vers son helpdesk : un enregistrement, et tous les espaces derrière.

Chez le routeur d'emails entrants que nous utilisons — et le comportement est courant — la réception ne se déclenche que sur le domaine destinataire exact. Pas de sous-domaine implicite, pas de motif. La conséquence est structurelle : une route doit être créée par espace, avec son propre domaine, ses enregistrements DNS explicites, son authentification et son webhook dédié.

Nous avons dû, pour cette raison, faire de la création de route un travail asynchrone séparé du reste de la mise en service : l'authentification du domaine peut retenter pendant plus de deux minutes le temps que le DNS se propage, et bloquer une inscription dessus faisait passer une création d'espace de quelques secondes à plus d'une minute.

Les six causes, dans l'ordre du chemin

1. Le MX ne pointe pas là où vous croyez

Un domaine n'a qu'un jeu d'enregistrements MX. Si votre domaine principal est chez un fournisseur de messagerie, vous ne pouvez pas le détourner vers votre helpdesk sans casser vos boîtes. D'où la pratique du sous-domaine dédié (`support.exemple.fr`), qui a ses propres MX.

La vérification, en une commande : `dig MX support.exemple.fr +short`. Si la réponse est vide, rien n'arrivera jamais, et aucun réglage dans votre helpdesk n'y changera quoi que ce soit.

2. SPF autorise l'expéditeur, pas la réception

Confusion très répandue : SPF ne concerne que l'envoi. Il déclare quels serveurs ont le droit d'envoyer au nom de votre domaine. Il n'a aucun effet sur ce que vous recevez.

Il devient pourtant central dès que votre helpdesk répond : vos réponses partent depuis les serveurs de l'éditeur, avec votre domaine en expéditeur. Si SPF ne les autorise pas, vos réponses tombent en spam chez vos clients — et vous conclurez, à tort, que le client ne répond plus.

3. DKIM, et le piège des deux clés

DKIM signe vos envois. Le piège de mise en œuvre : votre fournisseur vous donne un ou deux enregistrements CNAME à poser, souvent nommés d'après lui. Il en faut les deux. Avec un seul, la signature échoue une fois sur deux selon la clé utilisée — donc une délivrabilité aléatoire, ce qui est plus difficile à diagnostiquer qu'une panne franche.

4. DMARC, qui transforme un avertissement en rejet

DMARC dit ce qu'il faut faire quand SPF et DKIM échouent. En `p=none`, on observe. En `p=quarantine` ou `p=reject`, vos propres emails de support peuvent être rejetés si l'un des deux précédents est mal posé.

L'ordre correct est donc : poser SPF et DKIM, vérifier avec les rapports DMARC en `p=none` pendant deux semaines, puis durcir. Beaucoup d'équipes font l'inverse parce qu'un audit de sécurité leur a demandé `p=reject`, et découvrent la panne après.

5. Le fil qui ne se recolle pas

L'email arrive, mais il crée un nouveau ticket au lieu de s'ajouter au fil. Le recollage repose sur les en-têtes `In-Reply-To` et `References`, que certains clients de messagerie mutilent — et sur une adresse de réponse qui porte un identifiant.

Symptôme reconnaissable : des doublons de tickets sur les réponses venant d'Outlook, ou après un transfert. Ce n'est pas une perte d'email, mais ça y ressemble dans les statistiques, et ça fausse les compteurs de première réponse — voir les huit pièges du calcul d'un SLA.

6. L'email est arrivé, et il est parti au spam interne

La cause la moins technique et la plus fréquente : le message est bien dans l'outil, mais dans une vue que personne ne regarde — filtré par une règle d'automatisation trop large, assigné à une équipe vide, ou marqué comme indésirable par un filtre côté éditeur.

Avant de soupçonner le DNS, cherchez le message par l'adresse de l'expéditeur sans filtre de statut ni de vue. Une fois sur trois, il est là.

La séquence de diagnostic, dans l'ordre

Elle prend un quart d'heure et évite les journées perdues. L'ordre compte : chaque étape élimine une famille de causes.

1. 1Cherchez le message dans l'outil, sans aucun filtre. Élimine la cause 6, la plus fréquente.
2. 2`dig MX` sur l'adresse de réception. Élimine la cause 1. Vide = rien n'arrive.
3. 3Envoyez-vous un email depuis une adresse externe (pas votre domaine), et regardez les journaux de réception de l'éditeur. S'ils ne montrent rien, le problème est avant l'outil.
4. 4Vérifiez que la route existe pour CE domaine exact, et pas pour son parent. C'est le piège du joker.
5. 5Répondez au ticket et regardez où arrive la réponse. Élimine ou confirme SPF, DKIM et DMARC d'un seul coup, dans le sens qui compte pour vos clients.

Ce qu'il faut demander à un éditeur

• Existe-t-il un journal de réception consultable, avec les messages rejetés et le motif ? Sans lui, l'étape 3 du diagnostic est impossible et vous êtes dépendant du support de l'éditeur pour chaque incident.
• Une route par domaine ou un joker ? Et si c'est par domaine, la création est-elle automatisée ?
• Les deux clés DKIM sont-elles fournies, et l'outil vérifie-t-il leur présence au lieu de vous laisser deviner ?
• Que devient une pièce jointe de 30 Mo ? Rejet franc, troncature silencieuse, ou lien externe ?

Notre pile de réception, ses adaptateurs et ses tests sont lisibles sous licence AGPL-3.0 — page open source — et ce que font les canaux est décrit avec ses limites. La limite du joker en est une : elle est écrite dans le code, en commentaire, avec la date où nous l'avons découverte.

Une réception d'emails qui échoue en silence est une fonctionnalité qui a l'air de marcher jusqu'au premier client perdu.