Votre soumission est partie. Pourquoi le client ne l'a-t-il jamais reçue?

La soumission est prête. Le représentant la relit, joint le PDF et clique sur « Envoyer » à 14 h 07. Outlook place le message dans les éléments envoyés. Aucun avis d'échec ne revient.

Trois jours plus tard, il relance le client. Réponse : « Nous n'avons jamais reçu votre soumission. Nous avons choisi un autre fournisseur hier. »

Le courriel avait pourtant été accepté par le système du destinataire. Il dormait simplement dans le dossier des pourriels, dans une quarantaine ou derrière un filtre que personne n'avait consulté.

Le problème n'était ni le contenu de l'offre ni le travail du représentant. C'était la délivrabilité : la capacité d'un courriel légitime à atteindre la boîte de réception plutôt que d'être ralenti, rejeté ou classé comme indésirable.

Pour une entreprise, ce n'est pas qu'une question de messagerie. Une soumission perdue, une facture invisible, un avis de renouvellement ignoré ou un lien de signature électronique bloqué peut retarder une vente, un paiement ou un projet entier.

« Envoyé » ne veut pas dire « livré dans la boîte de réception »

Le dossier des éléments envoyés confirme surtout que votre application a remis le message à votre système de messagerie. Il ne confirme pas que le serveur du destinataire l'a accepté, encore moins qu'il l'a placé dans la boîte de réception.

Entre les deux, plusieurs systèmes posent leurs propres questions :

• le serveur qui expédie ce message est-il autorisé à utiliser ce domaine?
• le contenu a-t-il été signé et est-il demeuré intact pendant le transport?
• l'adresse visible de l'expéditeur correspond-elle au domaine qui a été authentifié?
• ce domaine et cette infrastructure ont-ils une bonne réputation?
• les destinataires ouvrent-ils ces messages ou les signalent-ils comme pourriels?
• le volume, les liens, les pièces jointes et le comportement d'envoi semblent-ils normaux?

Un serveur peut accepter un message, puis le classer comme indésirable selon l'ensemble de ces signaux. À l'inverse, un message peut être refusé pendant le transport et produire un avis de non-livraison. L'absence d'avis d'échec ne constitue donc pas une preuve que le courriel a été vu — ni même qu'il se trouve dans la boîte de réception.

Les trois contrôles d'identité du courriel

SPF, DKIM et DMARC ressemblent à une soupe d'acronymes. Leur rôle devient plus simple lorsqu'on les voit comme trois contrôles complémentaires : qui a le droit d'envoyer, comment vérifier l'intégrité du message et quoi faire lorsque l'identité ne concorde pas.

SPF : qui a le droit d'envoyer pour votre domaine?

Le protocole SPF publie dans le DNS la liste des serveurs autorisés à envoyer des courriels pour un domaine. Lorsqu'un message arrive, le système destinataire compare l'infrastructure d'envoi avec cette liste.

Si votre entreprise utilise uniquement Microsoft 365, la configuration peut sembler simple. Mais combien d'autres systèmes envoient aussi des messages en son nom?

• le CRM qui transmet les suivis de vente;
• le logiciel comptable qui expédie les factures;
• la plateforme d'infolettre;
• le formulaire du site Web;
• le service de signature électronique;
• le système de billetterie;
• l'application de paie;
• le photocopieur qui numérise et envoie des documents.

Chacun peut devenir une source légitime à inventorier et à configurer correctement.

Deux erreurs reviennent souvent. La première consiste à créer plusieurs enregistrements SPF séparés pour un même domaine. Il ne doit y en avoir qu'un; plusieurs enregistrements entraînent une erreur permanente d'évaluation. La seconde consiste à ajouter des fournisseurs les uns après les autres sans tenir compte de la limite de dix recherches DNS imposée par SPF. Les références imbriquées d'un fournisseur peuvent en consommer plusieurs à elles seules.

SPF est donc une liste d'autorisation, pas un sceau de qualité. Il ne suffit pas à protéger le nom affiché dans le champ « De », et un transfert de message peut aussi compliquer son évaluation.

DKIM : le message porte-t-il une signature valide?

Le protocole DKIM ajoute une signature cryptographique au courriel. Le système expéditeur signe certaines parties du message avec une clé privée. Le destinataire récupère la clé publique publiée dans le DNS et vérifie que la signature est valide.

Cette vérification aide à confirmer deux choses : le message a été signé par un système autorisé pour le domaine, et les parties signées n'ont pas été modifiées pendant le transport.

Le détail important pour une PME est que DKIM doit être activé pour chaque service qui envoie au nom de l'entreprise. Le fait que Microsoft 365 signe correctement les messages des employés ne signifie pas que le CRM, l'outil marketing ou le logiciel de facturation le fait aussi avec votre domaine.

Un fournisseur peut apposer sa propre signature et réussir son contrôle DKIM, mais signer avec son domaine plutôt qu'avec le vôtre. Techniquement, la signature est valide. Pour DMARC, cependant, l'identité peut ne pas correspondre à l'adresse que le client voit.

DMARC : les identités correspondent-elles, et que faire sinon?

Le protocole DMARC relie les deux contrôles précédents à l'adresse visible dans le champ « De ». Un message passe DMARC si SPF ou DKIM réussit et si le domaine authentifié est aligné avec le domaine présenté au destinataire.

Cet alignement empêche un expéditeur de réussir SPF avec son propre domaine tout en affichant le vôtre pour paraître légitime.

DMARC indique aussi aux systèmes destinataires comment traiter un message qui échoue :

• p=none : recueillir de l'information sans demander d'action particulière;
• p=quarantine : recommander la mise en quarantaine ou dans les pourriels;
• p=reject : recommander le rejet.

Les rapports agrégés DMARC permettent ensuite de voir quels services envoient au nom du domaine et lesquels réussissent ou échouent les contrôles. Ces rapports sont précieux, mais leur format brut est difficile à lire; il faut les faire analyser par un outil ou une personne qui sait distinguer un service oublié d'une tentative d'usurpation.

Il serait risqué de publier immédiatement une politique p=reject sans connaître toutes les sources légitimes. Le déploiement devrait être progressif : inventorier les expéditeurs, activer SPF et DKIM, observer les rapports avec p=none, corriger les écarts, passer à p=quarantine, puis à p=reject lorsque les résultats le permettent.

Cette progression améliore la délivrabilité tout en protégeant le domaine contre l'usurpation. Elle complète directement les mesures décrites dans notre article sur la fraude au président , où un attaquant tente de donner à un message frauduleux l'apparence d'un vrai courriel de direction.

DMARC a changé en mai 2026 — ce que ça implique

Si vous avez configuré DMARC il y a quelques années, votre enregistrement fonctionne toujours. Mais la spécification a été remplacée, et deux nouveautés méritent une modification à votre prochain changement DNS.

Le 20 mai 2026, l'IETF a publié trois documents qui font passer DMARC sur la voie des standards et remplacent la spécification de 2015 : RFC 9989 pour le protocole de base, RFC 9990 pour les rapports agrégés, RFC 9991 pour les rapports d'échec.

Les points à retenir :

• Rien ne casse. Les enregistrements commençant par v=DMARC1 demeurent valides, et les balises p, sp, rua, ruf, adkim, aspf et fo conservent leur sens.
• Trois balises sont dépréciées : pct=, rf= et ri=. Les systèmes destinataires les ignorent plutôt que de rejeter l'enregistrement, mais autant les retirer pour la propreté.
• Trois nouvelles balises apparaissent : np= pour la politique des sous-domaines inexistants, t= comme indicateur de mode test, et psd= reprise d'une spécification devenue obsolète — cette dernière ne concerne que les opérateurs de suffixes publics.
• La liste des suffixes publics est remplacée par un parcours d'arbre DNS pour déterminer le domaine organisationnel.
• DMARC n'évalue plus SPF que sur l'adresse MAIL FROM, sans repli sur l'identifiant HELO.

La nouveauté qui vaut la peine d'être appliquée : np

La balise np définit la politique applicable aux sous-domaines qui n'existent pas du tout. Elle ferme une brèche d'usurpation courante : un attaquant qui envoie depuis facturation.entreprise.ca alors que ce sous-domaine n'a jamais été créé.

Publier np=reject coûte une modification DNS et ne présente aucun risque pour vos envois légitimes, puisque par définition aucun service n'envoie depuis un sous-domaine inexistant. C'est l'un des rares gains de sécurité sans contrepartie.

Ce que la nouvelle spécification vous enlève

L'ancienne balise pct permettait d'appliquer la politique à un pourcentage croissant du trafic — 10 %, puis 50 %, puis 100 %. Elle est retirée, et la nouvelle balise t n'est qu'un interrupteur de mode test, pas un curseur.

L'échelonnement décrit plus haut demeure la bonne approche, mais il doit maintenant se faire opérationnellement : en corrigeant les sources d'envoi une à une avant de durcir la politique, plutôt qu'en exposant graduellement une fraction du trafic.

Une bonne configuration n'achète pas automatiquement la boîte de réception

SPF, DKIM et DMARC sont essentiels, mais ils ne constituent pas un laissez-passer. Les grands fournisseurs utilisent aussi la réputation du domaine, celle de l'adresse IP d'envoi et le comportement observé au fil du temps.

Cette réputation n'est pas une note universelle que l'on peut consulter une fois par année. Chaque fournisseur applique ses propres modèles et combine plusieurs signaux, notamment :

• les plaintes et signalements comme pourriel;
• les adresses inexistantes et les rebonds permanents;
• les variations soudaines du volume d'envoi;
• l'historique et la constance des envois associés au domaine;
• les liens et domaines présents dans les messages;
• l'engagement des destinataires;
• les antécédents de l'infrastructure d'envoi;
• la qualité générale des listes de diffusion.

Le vrai seuil de Google, et il est plus strict qu'on le croit

Google demande de maintenir le taux de pourriel signalé dans Postmaster Tools sous 0,10 %, et de ne jamais atteindre 0,30 % ou plus.

La nuance est importante. On cite souvent 0,3 % comme si c'était la cible; c'est en réalité le seuil au-delà duquel l'impact devient nettement plus grave. L'objectif est trois fois plus strict.

Trois précisions utiles :

• Le taux est calculé quotidiennement, et son effet sur la livraison est graduel plutôt que binaire. Maintenir un taux bas donne de la résilience face aux pointes occasionnelles de signalements.
• Il existe un chemin de retour. Un expéditeur de masse demeure inadmissible à toute atténuation tant que son taux dépasse 0,3 %, et le redevient lorsque le taux reste sous ce seuil pendant sept jours consécutifs.
• Google ne mesure pas les taux d'ouverture et ne peut pas vérifier ceux rapportés par des tiers. Un faible taux d'ouverture n'est pas un indicateur fiable d'un problème de livraison.

Une petite entreprise qui envoie beaucoup moins de messages peut elle aussi subir un classement défavorable si ses envois provoquent des plaintes, utilisent une vieille liste ou augmentent brutalement.

Séparez l'opérationnel du marketing

Il faut distinguer les courriels opérationnels des campagnes marketing. Une facture, une réinitialisation de mot de passe et une soumission n'ont pas le même rôle qu'une infolettre.

Utiliser un sous-domaine distinct pour les envois marketing — par exemple nouvelles.entreprise.ca — peut limiter l'impact d'une campagne sur la réputation de la messagerie quotidienne. Microsoft recommande cette séparation pour les services d'envoi de masse qui ne sont pas sous le contrôle direct de l'entreprise.

Au passage, une précision qui rassure souvent : le désabonnement en un clic n'est exigé que pour les messages marketing et promotionnels. Les messages transactionnels en sont exclus — réinitialisations de mot de passe, confirmations de réservation, confirmations de formulaire. Vos factures ne tombent pas sous cette règle.

Le domaine principal demeure un actif critique. Notre article sur la propriété et le renouvellement du nom de domaine explique pourquoi les accès au registraire et au DNS doivent rester sous le contrôle de l'organisation : c'est justement là que SPF, DKIM et DMARC sont publiés.

Pourquoi la soumission est-elle souvent le message qui disparaît?

Une soumission réunit parfois plusieurs facteurs inhabituels : un nouveau destinataire, une première conversation, une pièce jointe volumineuse, plusieurs liens et un message envoyé depuis un CRM plutôt que depuis la boîte habituelle du représentant.

Aucun de ces éléments ne rend le courriel mauvais en soi. Leur combinaison donne cependant moins de contexte positif au filtre du destinataire.

Le problème peut aussi se trouver du côté du client. Sa passerelle de sécurité peut placer le PDF en quarantaine, bloquer un type de lien ou appliquer une règle plus stricte aux nouveaux expéditeurs. Une politique interne peut même livrer le message à une quarantaine réservée aux administrateurs et invisible pour l'utilisateur.

C'est pourquoi personne ne peut garantir un placement systématique dans la boîte de réception. On peut authentifier correctement le domaine, maintenir une bonne hygiène d'envoi et surveiller les résultats. La décision finale appartient toujours au système destinataire.

Demander à chaque client d'ajouter votre adresse à sa liste d'expéditeurs approuvés peut dépanner un cas isolé. Ce n'est pas une stratégie de délivrabilité. Si plusieurs organisations ne reçoivent plus vos messages, il faut corriger la cause à la source.

Le silence et le rebond ne disent pas la même chose

Voici une nuance qui a changé récemment et qui améliore le diagnostic.

Gmail est passé de l'avertissement à l'application. Le courrier qui échoue aux exigences pour les expéditeurs reçoit maintenant des rejets SMTP temporaires ou permanents plutôt que d'être filtré silencieusement — et le code de rejet indique quelle exigence a échoué.

Autrement dit :

• Un rebond avec un code d'erreur pointe généralement vers un problème d'authentification ou de conformité aux exigences. C'est la bonne nouvelle : l'information est dans le message de rejet.
• Le silence — votre message accepté, puis introuvable — pointe plutôt vers la réputation, le contenu, ou un filtre chez le destinataire.

Le scénario d'ouverture de cet article est un cas de silence. C'est justement le plus difficile à diagnostiquer, parce qu'aucun système ne vous dit ce qui s'est passé.

Comment enquêter sur un courriel disparu

Une enquête utile part d'un message précis, pas de la question générale « Est-ce que nos courriels fonctionnent? »

1. Fixer les faits. Notez l'adresse exacte de l'expéditeur et du destinataire, l'heure d'envoi, l'objet, le système utilisé et la présence de pièces jointes. Un message envoyé depuis Outlook et un autre envoyé par le CRM peuvent afficher la même adresse tout en suivant des chemins complètement différents.

2. Consulter la trace du message. Microsoft 365 et les plateformes d'envoi conservent des traces permettant de déterminer si le message a été soumis, remis, retardé ou rejeté. Une mention « livré » indique généralement que le système destinataire l'a accepté; elle ne prouve pas qu'il l'a placé dans la boîte de réception.

3. Obtenir les en-têtes complets. Si le destinataire retrouve le message dans ses pourriels ou sa quarantaine, les en-têtes complets révèlent les résultats SPF, DKIM et DMARC, les serveurs traversés et plusieurs décisions de filtrage. Une capture d'écran du courriel ne contient pas ces renseignements.

4. Vérifier l'alignement, pas seulement les mentions « pass ». SPF et DKIM peuvent chacun afficher une réussite tandis que DMARC échoue, simplement parce que les domaines authentifiés ne correspondent pas à l'adresse visible. C'est fréquent lorsqu'un service tiers envoie au nom de l'entreprise sans signature DKIM personnalisée ni adresse de retour alignée.

5. Lire le code de rejet s'il y en a un. Un rebond vers Gmail indique désormais quelle exigence a échoué. C'est le diagnostic le plus rapide disponible — encore faut-il regarder.

6. Chercher un problème de tendance. Un seul message bloqué peut venir d'une règle chez le client. Plusieurs échecs vers Gmail, Outlook ou différents domaines indiquent plutôt un problème d'authentification, de réputation ou d'infrastructure. Les rebonds, plaintes, suppressions et variations de volume aident à voir cette tendance.

Pour tester, utilisez de vraies boîtes Gmail et Outlook que vous contrôlez, puis examinez le résultat et les en-têtes. Envoyer en masse vers de fausses adresses pour « voir ce qui arrive » détériore la qualité de vos envois et peut nuire davantage à votre réputation.

La vérification à faire cette semaine

Une PME peut déjà réduire une grande partie du risque avec cette démarche :

1. Dressez la liste de tous les domaines et sous-domaines utilisés pour envoyer des courriels.
2. Inventoriez chaque source : Microsoft 365, site Web, CRM, comptabilité, marketing, signature électronique, appareils et applications métiers.
3. Confirmez qu'un seul enregistrement SPF existe par domaine et qu'il autorise seulement les sources encore utilisées, sans dépasser la limite de recherches DNS.
4. Activez DKIM avec votre domaine sur chaque plateforme qui le permet.
5. Publiez DMARC en mode d'observation et faites analyser les rapports.
6. Retirez les balises pct, rf et ri si elles figurent dans votre enregistrement, et ajoutez np=reject.
7. Corrigez les sources non alignées avant de passer progressivement à la quarantaine, puis au rejet.
8. Séparez les envois marketing des messages opérationnels lorsque le volume ou le risque le justifie.
9. Surveillez votre taux de pourriel signalé dans Postmaster Tools, avec 0,10 % comme cible réelle.
10. Vérifiez les rebonds, plaintes et suppressions; retirez rapidement les adresses invalides.
11. Refaites le contrôle lorsqu'un fournisseur, un logiciel ou le DNS change.

Cette démarche ne remplace pas les protections de la boîte elle-même. L'authentification du domaine, les politiques antipourriel, l'analyse des liens et pièces jointes, le MFA et la surveillance travaillent ensemble. Notre guide pour sécuriser Microsoft 365 en entreprise présente les autres priorités autour de la messagerie, des identités et des appareils.

Le mot de la fin

Le courriel paraît instantané parce que le bouton « Envoyer » l'est. Derrière ce bouton, chaque message doit pourtant prouver son identité, préserver son intégrité et inspirer suffisamment confiance au système qui le reçoit.

Une entreprise qui configure SPF une seule fois lors de son passage à Microsoft 365 n'a pas nécessairement terminé le travail. Ses outils évoluent. Un CRM est ajouté, une plateforme marketing change, un ancien fournisseur demeure dans le DNS et un formulaire Web commence à envoyer des messages. La configuration qui était correcte il y a deux ans peut aujourd'hui être incomplète, trop complexe — ou simplement écrite selon une spécification qui a changé depuis.

Le bon objectif n'est pas de promettre que chaque courriel atteindra toujours la boîte de réception. C'est de pouvoir répondre clairement à trois questions : qui envoie au nom de notre domaine, est-ce correctement authentifié et voyons-nous rapidement lorsqu'un problème apparaît?

Avant la prochaine soumission importante, le meilleur test n'est donc pas de vérifier si elle se trouve dans les éléments envoyés. C'est de vérifier si votre domaine mérite encore la confiance des systèmes qui la recevront.

Un projet TI ou une question?

MMO Techno peut auditer vos sources d'envoi, vérifier SPF, DKIM et DMARC, analyser les rapports et retracer les problèmes de livraison — sans vous promettre l'impossible, mais en corrigeant les causes qui placent inutilement vos courriels professionnels dans les pourriels.

Parlez à un expert MMO Techno .