Niveau de preuve : C — faits vérifiés à la source officielle. Aucun service n’a été testé ni payé pour rédiger cette page. Toutes les exigences chiffrées proviennent de la documentation publiée par les fournisseurs de boîtes aux lettres. Dernière vérification : 21 septembre 2026.
Onze points, séparés par un critère écrit dans la page : les cinq premiers — SPF, DKIM, DMARC, alignement du « From » et List-Unsubscribe — sont des exigences publiées noir sur blanc par Google et par Microsoft, et elles échouent de façon binaire, avec un code d’erreur à lire dans l’en-tête du message reçu. Les six suivants — réputation du domaine et de l’IP, rythme de montée en volume, contenu, listes de blocage, reverse DNS et TLS, envoi depuis le serveur du site — sont décrits par les fournisseurs sans aucun seuil chiffré. Un diagnostic qui commence par le sixième saute par-dessus tout ce qui se vérifie en quelques minutes. L’ordre des six derniers entre eux n’est appuyé par aucune statistique publiée : la page l’inscrit en « à vérifier » au lieu de trancher.
Le critère de classement de cette liste
Cette liste suit un critère unique et vérifiable : les points 1 à 5 sont des exigences publiées noir sur blanc par Google et par Microsoft, les points 6 à 11 ne le sont pas. Les cinq premiers s’échouent de façon binaire, avec un code d’erreur à la clé ; les suivants sont des facteurs décrits en termes généraux, sans seuil publié. Un diagnostic qui commence par le point 6 saute par-dessus ce qui est mesurable.
L’ordre des points 6 à 11 entre eux n’est appuyé par aucune statistique : aucun fournisseur n’en publie. C’est inscrit en « à vérifier » plus bas.
La liste en un tableau
| # | Quoi vérifier | Comment | Ce que ça veut dire si c’est mauvais |
|---|---|---|---|
| 1 | SPF publié et valide | TXT du domaine ; spf=pass dans l’en-tête reçu | Aucune liste d’expéditeurs autorisés à comparer |
| 2 | DKIM publié et valide | dkim=pass ; clé au sélecteur publié | Message non signé, ou signature cassée en transit |
| 3 | DMARC publié | TXT de _dmarc.domaine.com | Absent, l’exigence Microsoft échoue même sous p=none |
| 4 | Alignement du « From » | Comparer From:, Return-Path et d= | SPF et DKIM peuvent réussir et DMARC échouer |
| 5 | Désabonnement et List-Unsubscribe | Source brute du message reçu | Exigence publiée pour les envois commerciaux en volume |
| 6 | Réputation du domaine et de l’IP | Outils de postmaster | Un domaine neuf part de zéro, pas de bon |
| 7 | Rythme de montée en volume | Courbe des envois par jour | Une hausse brutale ressemble à un compte compromis |
| 8 | Contenu : images, liens, pièces jointes | Lecture du message source | Facteurs décrits sans seuil publié |
| 9 | Listes de blocage | Interrogation DNSBL sur l’IP et le domaine | L’inscription peut suivre un voisin d’IP partagée |
| 10 | Reverse DNS et TLS | dig -x sur l’IP ; en-tête Received | Exigence publiée, rarement vérifiée en PME |
| 11 | Envoi depuis le serveur du site web | Comparer l’IP d’envoi à celle du site | Cas particulier, traité en fin de page |
1. SPF — la liste des serveurs autorisés
Quoi. Un enregistrement TXT sur le domaine qui déclare quels serveurs ont le droit d’envoyer en son nom.
Comment vérifier. Ouvrir un message réellement reçu dans une boîte du fournisseur visé, afficher l’original, et lire la ligne d’authentification : spf=pass, spf=fail, spf=softfail ou spf=none.
Si c’est mauvais. none signifie qu’aucun enregistrement n’existe. fail signifie qu’un enregistrement existe et que le serveur qui a envoyé n’y figure pas — le cas typique d’une PME qui a ajouté un service d’envoi sans mettre à jour son SPF. Le détail des enregistrements, dont la limite de dix recherches DNS qui casse silencieusement un SPF trop long, est traité dans la page SPF, DKIM et DMARC expliqués sans jargon.
Google écrit que tous les expéditeurs, quel que soit leur volume, doivent « Set up SPF or DKIM email authentication for your sending domains », et que les expéditeurs en volume doivent configurer « SPF and DKIM » — les deux (lignes directrices Google, consultées le 21 septembre 2026 — voir « Méthode »).
2. DKIM — la signature du message
Quoi. Une signature cryptographique posée par le serveur d’envoi, vérifiable au moyen d’une clé publique publiée dans le DNS sous un sélecteur.
Comment vérifier. Lire dkim=pass dans l’en-tête du message reçu, puis vérifier que la clé publique répond au sélecteur indiqué dans la signature.
Si c’est mauvais. Une signature absente laisse le message sans preuve d’intégrité. Une signature invalide est un autre problème : un intermédiaire — liste de diffusion, passerelle antipourriel, règle de transfert — a modifié le message après signature.
Google précise une contrainte de longueur de clé : « Sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer » (support.google.com/mail/answer/81126, consulté le 21 septembre 2026). Une clé de 512 bits, encore proposée par défaut par certains panneaux d’hébergement, ne satisfait pas cette exigence.
3. DMARC — la politique publiée
Quoi. Un enregistrement TXT sur _dmarc.domaine.com qui dit au receveur quoi faire quand SPF et DKIM échouent tous les deux, et où envoyer les rapports.
Comment vérifier. Interroger le TXT de _dmarc. suivi du domaine. L’absence de réponse est en soi le résultat.
Si c’est mauvais. Microsoft publie l’exigence la plus explicite, pour les domaines qui envoient plus de 5 000 courriels par jour vers Outlook.com : « At least p=none (p=reject is recommended) and align with either SPF or DKIM (preferably both) » (substrate.office.com — Policies, Practices, and Guidelines, consulté le 21 septembre 2026). Un domaine sans enregistrement DMARC du tout échoue donc l’exigence, même avec SPF et DKIM parfaitement configurés.
4. L’alignement entre le domaine d’envoi et le domaine du « From »
Quoi. C’est le point qui explique les cas où « tout est vert » et où le message tombe quand même. SPF valide le domaine de l’enveloppe, celui du Return-Path. Le destinataire, lui, voit le domaine du From:. DMARC exige que les deux se correspondent — ou que le domaine signé par DKIM corresponde au From:.
Google l’écrit ainsi pour les expéditeurs en volume : « For direct email, the domain in the sender’s From: header must be aligned with either the SPF domain or the DKIM domain » (lignes directrices Google, consultées le 21 septembre 2026 — voir « Méthode »).
Comment vérifier. Dans l’original du message reçu, comparer trois valeurs : le domaine du From:, le domaine du Return-Path, et le domaine d= de la signature DKIM.
Si c’est mauvais. Le cas classique : une PME envoie par un service tiers qui pose son propre domaine dans le Return-Path tant que le domaine d’envoi n’est pas vérifié et délégué. SPF passe et DKIM passe — pour le domaine du service. DMARC échoue, parce que ni l’un ni l’autre ne correspond au From: affiché.
5. Le désabonnement et l’en-tête List-Unsubscribe
Quoi. Deux choses distinctes : un lien visible dans le corps du message, et un en-tête technique que le client de messagerie lit pour afficher son propre bouton.
Google exige des expéditeurs en volume que « Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link », et documente les deux en-têtes attendus : List-Unsubscribe-Post: List-Unsubscribe=One-Click et List-Unsubscribe: suivi de l’URL, en référence aux normes RFC 2369 et RFC 8058 (lignes directrices Google, consultées le 21 septembre 2026 — voir « Méthode »). Microsoft demande de son côté que « The mechanism for unsubscribing […] must be clearly documented and easy for recipients to find and use » (politiques du postmaster Outlook.com, consultées le 21 septembre 2026 — voir « Méthode »).
Comment vérifier. Afficher la source brute d’un message envoyé et chercher les deux lignes List-Unsubscribe. Le délai maximal de traitement d’une demande de désabonnement n’est pas chiffré sur la page de Google consultée — voir « à vérifier ».
Si c’est mauvais. Sans bouton natif, le destinataire qui veut que ça cesse utilise le seul bouton qui reste : « signaler comme pourriel ». Ce clic alimente le taux de plainte du point suivant.
6. La réputation du domaine et de l’adresse IP
Quoi. Deux réputations distinctes, souvent confondues. Celle de l’adresse IP qui émet — partagée sur un forfait d’entrée de gamme, exclusive sur une IP dédiée. Et celle du domaine, qui le suit partout, quelle que soit l’IP.
Comment vérifier. Les outils de postmaster des fournisseurs affichent les deux, plus le taux de plainte et le taux de livraison, après validation de la propriété du domaine.
Le seuil publié. Google écrit : « Keep spam rates reported in Postmaster Tools below 0.3% », et recommande plus bas encore : « Keep spam rates reported in Postmaster Tools below 0.10% » (support.google.com/mail/answer/81126, consulté le 21 septembre 2026). Aucun taux de plainte chiffré n’apparaît sur la page de politiques de Microsoft consultée.
Un domaine neuf part de zéro, pas de bon. Un domaine enregistré la semaine dernière n’a pas une bonne réputation en attendant la preuve du contraire : il n’a aucun historique, et l’absence d’historique est traitée avec prudence. Un domaine neuf qui expédie 20 000 courriels le premier jour a le profil d’un domaine jetable acheté pour une campagne de pourriel.
7. Le rythme de montée en volume
Quoi et comment. La variation du volume dans le temps, indépendamment du volume absolu. Tracer la courbe des envois par jour sur les trois derniers mois, à partir des journaux du service d’envoi.
Si c’est mauvais. Google recommande : « Start with a low sending volume to engaged users, and slowly increase the volume over time » et « Avoid sending email in bursts » (lignes directrices Google, consultées le 21 septembre 2026 — voir « Méthode »). Aucune courbe chiffrée n’est publiée : les recettes du type « doubler tous les deux jours » qui circulent en ligne ne viennent pas de cette source.
8. Le contenu du message
Les fournisseurs décrivent ces facteurs sans publier de seuil.
Le rapport texte/image. Un message qui n’est qu’une grande image, sans texte lisible, ne donne au filtre aucune matière à analyser. Aucun ratio chiffré n’est publié par Google ni par Microsoft sur les pages consultées.
Les liens raccourcis. Un raccourcisseur masque la destination réelle et partage sa réputation avec tous les autres liens du même service, dont ceux des campagnes d’hameçonnage. Vérifier si la source contient des domaines de redirection tiers plutôt que le domaine de l’entreprise.
Les pièces jointes. Les remplacer par un lien vers un fichier hébergé retire le facteur.
La conformité canadienne. Au-delà du filtrage, la Loi canadienne anti-pourriel exige un mécanisme d’exclusion fonctionnel et une identification de l’expéditeur dans tout message électronique commercial.
Comment vérifier. S’envoyer le message sur des comptes réels chez les deux grands fournisseurs, puis lire la source brute.
9. Les listes de blocage
Quoi. Des listes publiques d’IP et de domaines signalés pour envoi de pourriel, interrogées en temps réel par les serveurs receveurs.
Comment vérifier. Les interroger sur l’IP d’envoi et sur le domaine. Chacune publie sa page de recherche et sa procédure de retrait ; les délais varient.
Si c’est mauvais. Sur une IP partagée, l’inscription peut ne rien devoir à vos envois : elle suit le comportement d’un autre client du même bloc, et le retrait passe par le fournisseur. Sur une IP dédiée ou sur le domaine, elle pointe vers vos propres envois — souvent vers une liste de contacts qui n’a pas été nettoyée.
Distinction utile : les listes de blocage sont publiques et externes ; les listes de suppression sont internes à votre service d’envoi. Une adresse peut cesser d’être servie sans qu’aucune liste de blocage ne soit en cause. Le mécanisme est traité dans la page Pourquoi un client ne reçoit plus vos courriels : les listes de suppression.
10. Reverse DNS et connexion chiffrée
Deux exigences publiées, rarement vérifiées en PME parce qu’elles relèvent de l’hébergeur. Google demande de « Ensure that sending domains or IPs have valid forward and reverse DNS records » et de « Use a TLS connection for transmitting email » (lignes directrices Google, consultées le 21 septembre 2026 — voir « Méthode »). Microsoft écrit : « Email servers must have valid reverse DNS records » (politiques du postmaster Outlook.com, consultées le 21 septembre 2026 — voir « Méthode »).
Comment vérifier. Une requête DNS inverse sur l’IP d’envoi doit retourner un nom d’hôte, qui doit à son tour résoudre vers la même IP. Pour TLS, l’en-tête Received du message livré indique le protocole de la connexion.
Si c’est mauvais. Une IP sans reverse DNS ne ressemble à aucun serveur de courriel d’entreprise — le cas par défaut d’un serveur loué à la va-vite.
11. Le cas de la PME qui envoie depuis son serveur de site web
Configuration répandue, qui cumule plusieurs des points ci-dessus. Un site web — vitrine, boutique, formulaire de contact — envoie ses courriels par la fonction intégrée au serveur d’hébergement. Personne ne l’a décidé : c’est le comportement par défaut de la plupart des systèmes de gestion de contenu. Ce qui en découle :
- L’IP d’envoi est celle de l’hébergement mutualisé, partagée avec des dizaines
d’autres sites. La réputation (point 6) et l’inscription éventuelle sur une liste de blocage (point 9) ne dépendent pas de vous.
- Le
From:est souvent une adresse qui n’existe pas, et leReturn-Pathporte
le domaine technique de l’hébergeur : l’alignement (point 4) échoue.
- Le SPF du domaine liste rarement le serveur web quand le courriel d’affaires est
chez un autre fournisseur. Point 1 en échec.
- Aucune signature DKIM n’est posée par défaut par la plupart de ces fonctions
d’envoi. Point 2 en échec.
- Aucun journal exploitable : la fonction rend « vrai » dès que le message est
remis au serveur local. Ce qui suit n’est visible nulle part.
Comment vérifier. Envoyer un message par le formulaire du site vers une boîte chez chacun des deux grands fournisseurs, afficher l’original, et comparer l’IP de la ligne Received à l’IP publique du site.
La correction usuelle consiste à faire passer le site par un relais authentifié — SMTP ou API — plutôt que par la fonction locale, puis à aligner le From: sur le domaine d’envoi. La configuration DNS correspondante est traitée dans la page SPF, DKIM et DMARC expliqués sans jargon.
Ce qui reste à vérifier
- Fréquence relative des onze causes. Aucun fournisseur ne publie de répartition
des causes de classement en indésirables. L’ordre de cette page tient au critère annoncé en tête — exigence publiée ou non —, pas à une statistique.
- Taux de plainte maximal chez Microsoft. Aucun seuil chiffré sur la page de
politiques consultée le 21 septembre 2026.
- Délai maximal de traitement d’un désabonnement. Non chiffré sur la page de
Google consultée. À vérifier.
- Courbe de montée en volume, ratio texte/image, nombre de liens. Aucun seuil
publié par l’un ou l’autre fournisseur. À vérifier.
- Seuils des autres fournisseurs de boîtes — fournisseurs d’accès canadiens et
messageries d’entreprise hors Google et Microsoft. Non relevés à ce jour.
- Politique de Microsoft sous le seuil de 5 000 par jour. La page consultée
chiffre les exigences au-delà de 5 000 sans décrire ce qui s’applique en deçà.
Méthode
Les exigences de cette page ont été lues le 21 septembre 2026 sur deux pages officielles : les lignes directrices de Google pour les expéditeurs (support.google.com/mail/answer/81126) et la page de politiques du postmaster d’Outlook.com (substrate.office.com/ip-domain-management-snds/Postmaster/Policies). Les citations en anglais sont reproduites telles que publiées, sans traduction, pour qu’on les retrouve mot pour mot à la source.
Ce que cette page ne fait pas : elle ne compare aucun service d’envoi, ne recommande aucun outil et n’établit aucune fréquence des causes. Elle ne remplace pas la lecture des en-têtes d’un message réellement livré — la seule méthode qui dit ce que le receveur a vu. La page sera revue à chaque modification publiée par l’un des deux fournisseurs cités.
À lire aussi
- Configurer SPF, DKIM et DMARC pour Mailgun, expliqué sans jargon — comment se règlent SPF, DKIM et DMARC, champ par champ
- Combien coûte vraiment l’envoi de 50 000 courriels par mois : le coût mensuel relevé chez cinq services, dépassements compris — ce que coûte l’envoi de 50 000 courriels par mois, plateforme par plateforme
- Pourquoi un client ne reçoit plus vos courriels : comprendre les listes de suppression — à quoi sert une liste de suppression et ce qu’elle évite
Divulgation : certaines pages de ce site contiennent des liens d’affiliation, qui peuvent nous verser une commission sans coût supplémentaire pour vous. Cette page-ci ne contient aucun lien d’affiliation. Les liens externes ci-dessus pointent vers la documentation officielle des fournisseurs et ne rapportent rien. Les prix et conditions cités sont ceux publiés à la date de consultation indiquée et peuvent changer sans préavis. Contact : info@outilspme.ca