Vous cliquez sur Envoyer et le serveur répond 250 OK. Deux semaines plus tard, vous découvrez que le message n'est pas arrivé dans la boîte de réception : il se trouvait dans les indésirables ou, selon la politique de la passerelle, a pu être supprimé avant la connexion du destinataire. L'objet et le contenu peuvent aussi jouer un rôle, mais la réputation de votre domaine de messagerie, qui se dégradait peut-être depuis plusieurs semaines, est une autre cause possible.
Depuis que Google et Yahoo ont durci leurs exigences en février 2024, les expéditeurs et flux qui relèvent de leurs définitions doivent respecter des règles précises. Un manquement peut réduire la distribution ou entraîner des rejets, sans pour autant provoquer une mise en sourdine universelle. Ce guide explique pourquoi la réputation d'un domaine se dégrade, ce que signalent différents codes d'erreur et comment organiser le rétablissement. Si vous devez d'abord poser les bases DNS, commencez par configurer la messagerie sur votre domaine.
Ce qu'est réellement la réputation d'un domaine de messagerie
La réputation du domaine regroupe les signaux de confiance que Google, Microsoft, Yahoo et d'autres fournisseurs associent à un domaine selon le comportement passé des messages envoyés. Un taux élevé de plaintes, des échecs d'authentification et une liste mal entretenue peuvent la dégrader. Il n'existe ni score universel ni délai fixe de rétablissement : chaque fournisseur pondère ses propres signaux et l'activité récente.
La réputation ne revient pas non plus spontanément à une valeur par défaut. Un domaine doté d'un historique solide peut mieux absorber des erreurs occasionnelles, tandis qu'un domaine affecté par des plaintes ou des échecs d'authentification peut mettre des semaines ou des mois à s'améliorer. Le résultat dépend de la cause, du fournisseur et de la qualité des envois ultérieurs.
Certains signaux peuvent être agrégés au niveau du domaine racine, mais les sous-domaines ne sont pas traités de façon identique par tous les fournisseurs. Si marketing.example.com est inscrit sur une liste de blocage, ceo@example.com n'atterrira pas automatiquement dans les indésirables, même si le problème peut influencer des signaux associés. La séparation est utile, mais ne constitue pas une barrière absolue.
Le niveau maximal atteint et une classification persistante
Lorsque Google classe un domaine comme expéditeur de masse, soit environ 5,000 messages par jour vers des comptes Gmail personnels, cette classification peut rester en vigueur même si le volume diminue ensuite. Il ne s'agit pas d'un statut permanent chez tous les fournisseurs. Pour les flux concernés, des exigences comme le désabonnement en un clic pour les messages promotionnels et la publication d'une politique DMARC continuent de s'appliquer. Les règles générales n'imposent pas à elles seules p=quarantine ou p=reject. Vérifiez toujours la politique en vigueur.
Si votre volume reste inférieur à ~100 messages/jour vers Gmail, Postmaster Tools peut afficher "No Data" faute de données suffisantes. Les tests sur des comptes témoins et l'analyse des rejets donnent des indices limités, mais ne remplacent pas les données réelles et ne garantissent aucune conclusion.
Les 4 causes fréquentes d'une dégradation de la réputation
Lorsque la réputation du domaine chute, quatre domaines méritent souvent d'être examinés : le taux de plaintes, l'alignement de l'authentification, la limite de recherches SPF et les rejets définitifs. Ce ne sont pas les seules causes possibles. Déterminer laquelle touche votre trafic évite d'appliquer une correction inadaptée et de perdre du temps.
1. Le risque associé au seuil de plaintes de 0.3%
Les plaintes pour spam peuvent rapidement nuire à un domaine. Google et Yahoo publient des seuils et des critères qui leur sont propres. Atteindre 0.3%, soit 3 plaintes pour 1,000 messages, accroît le risque de filtrage et peut modifier l'éligibilité à certaines mesures d'atténuation, sans provoquer un blocage immédiat et universel. Google recommande de rester sous 0.1%. Le seuil de 0.3% représente un risque, pas un objectif. Vérifiez les règles actuelles applicables à votre trafic.
Yahoo peut calculer ou présenter ces indicateurs sur une base différente. Avant d'affirmer que seuls les messages arrivés en boîte de réception servent de dénominateur, consultez sa définition actuelle.
Scénario illustratif : vous envoyez 1,000 messages. 900 sont automatiquement filtrés comme indésirables. 100 arrivent dans la boîte de réception. 1 personne se plaint.
Calcul illustratif : 1 plainte ÷ 100 messages reçus = un taux de plaintes de 1.0%.
Résultat : cette valeur serait 3× supérieure à la limite de l'exemple, mais le calcul réel dépend de la définition du fournisseur.
Le taux d'ouverture peut baisser, mais sa mesure n'est pas fiable comme preuve isolée. Google Postmaster Tools peut afficher "Low" ou "Bad" lorsque suffisamment de données sont disponibles, et les libellés comme l'interface peuvent évoluer. Recoupez ces informations avec les rejets, les plaintes et les réponses SMTP.
2. Défaut d'alignement de l'authentification et signal d'usurpation
SPF et DKIM peuvent être configurés sans que DMARC réussisse si aucun des deux ne s'aligne sur le domaine visible de l'expéditeur. DMARC passe lorsqu'un résultat SPF ou DKIM est aligné, les deux ne sont pas obligatoires. Des échecs répétés peuvent dégrader la réputation et ressembler à une usurpation, mais le diagnostic doit s'appuyer sur les en-têtes complets.
Supposons que vous utilisiez un prestataire d'envoi comme Mailchimp ou SendGrid. L'expéditeur d'enveloppe utilisé par SPF pointe vers mail.sendgrid.net, alors que l'en-tête From utilise yourcompany.com. SPF peut réussir parce que l'adresse IP est autorisée, mais l'alignement DMARC échoue s'il n'existe pas non plus de signature DKIM alignée. Un domaine personnalisé chez le prestataire peut aligner SPF, DKIM ou les deux, selon la configuration.
Microsoft peut renvoyer 550 5.7.515 dans certains scénarios d'authentification ou de politique, notamment pour du trafic à fort volume. Il ne s'agit pas toujours d'un blocage de contenu, et modifier seulement Return-Path ne suffit pas nécessairement. Lisez la réponse complète et configurez l'authentification de domaine personnalisée proposée par votre prestataire selon sa documentation.
3. La limite de 10 recherches SPF (RFC 7208)
SPF n'est pas une liste infinie. La RFC 7208, dans sa section 4.6.4, limite à 10 les termes qui provoquent des recherches DNS lors d'une évaluation SPF. Avec Google, Outlook, Zendesk, Mailchimp et un CRM, vous pouvez déjà approcher la limite. Les directives include: imbriquées consomment elles aussi des recherches lorsqu'elles sont évaluées.
Avec 11 recherches concernées, l'évaluation peut produire PermError. Ne partez pas du principe que certains fournisseurs accepteront toujours un SPF invalide au moyen d'analyseurs permissifs. Le symptôme varie selon le destinataire et sa politique : vérifiez le résultat SPF et l'arborescence des recherches.
4. Rejets définitifs et détection d'adresses
Microsoft tient compte des rejets définitifs. Un taux de 2-3% peut servir de signal opérationnel illustratif pour revoir une liste, mais il ne s'agit pas d'un seuil officiel déclenchant toujours un blocage immédiat pour activité automatisée. Distinguez les adresses définitivement inexistantes des erreurs permanentes liées à une politique ou à l'authentification. Parmi les réponses possibles figurent 550 5.7.1 et des erreurs temporaires comme 421 RP-001.
Un taux de plaintes de 0% ne protège pas contre un blocage motivé par d'autres facteurs. Les indicateurs sont distincts, mais l'absence de plaintes ne garantit pas la distribution. Validez la liste et analysez les codes d'état améliorés avant de contacter des adresses Microsoft.
Informations propres à chaque fournisseur
Pour améliorer la réputation du domaine, déterminez d'abord quel fournisseur filtre ou rejette le trafic. Chacun pondère différemment ses signaux et propose des outils distincts. La disponibilité des données, les conditions de volume et les fonctions évoluent : consultez la documentation actuelle.
| Fournisseur | Points d'attention | Outil de diagnostic | Nuance importante |
|---|---|---|---|
| Google (Gmail / Workspace) | Plaintes et engagement, entre autres signaux | Google Postmaster Tools | À faible volume (<100/jour vers Gmail), "No Data" peut s'afficher; les comptes témoins ne donnent qu'un échantillon |
| Microsoft (Outlook / 365) | Conformité technique et réputation IP, entre autres signaux | SNDS (Smart Network Data Services), sous réserve d'inscription et de disponibilité | Les nouvelles IP nécessitent souvent une montée en charge progressive; la limitation dépend du trafic et de la politique |
| Yahoo / AOL | Contenu et plaintes, entre autres signaux | Yahoo Sender Hub et CFL, pour les expéditeurs éligibles | Le Complaint Feedback Loop exige une inscription et la disponibilité des rapports ARF dépend de sa couverture et de ses conditions |
Procédure de diagnostic : isoler la défaillance
Ne procédez pas au hasard. Lancez ces vérifications en lecture seule uniquement sur des systèmes que vous êtes autorisé à interroger, puis examinez les en-têtes. Les résultats donnent des indices sur l'infrastructure, l'authentification ou le comportement d'envoi, sans identifier à eux seuls une cause précise.
Vérification de l'infrastructure dans le terminal
Contrôlez la chaîne d'authentification avant de modifier les politiques. Ces trois requêtes en lecture seule couvrent plusieurs points fréquents; remplacez les valeurs d'exemple par vos propres ressources autorisées.
# Check SPF - count the includes, verify it ends in ~all or -all
dig txt yourdomain.com +short
# Check DMARC - p= should be quarantine or reject for live domains
dig txt _dmarc.yourdomain.com +short
# Check FCrDNS (Forward-Confirmed Reverse DNS)
# Step 1: Get the hostname from your sending IP
dig -x 1.2.3.4 +short
# Expected output: mail.yourdomain.com.
# Step 2: Verify the hostname resolves back to the same IP
dig mail.yourdomain.com +short
# Expected output: 1.2.3.4
Si le contrôle FCrDNS échoue et que l'adresse IP ne correspond pas au nom d'hôte, le risque de rejet par Gmail, Yahoo ou d'autres destinataires peut augmenter, sans qu'il existe pour autant de rejet universel automatique. Corrigez la configuration autorisée et attendez sa propagation avant de relancer la requête.
Analyse des en-têtes
Envoyez un seul message de test attendu vers un compte Gmail que vous contrôlez. Ouvrez-le, cliquez sur les trois points et choisissez "Afficher l'original". Recherchez l'en-tête Authentication-Results ajouté par le destinataire; ne vous fiez pas à une copie insérée par l'expéditeur.
Signal problématique, défaut d'alignement :
spf=pass smtp.mailfrom=sendgrid.net
dkim=pass header.d=sendgrid.net
dmarc=fail (p=reject) header.from=yourcompany.com
SPF a réussi. DKIM aussi. DMARC échoue parce qu'aucun des domaines ne s'aligne sur yourcompany.com. Cet exemple montre une configuration non alignée susceptible de nuire à la réputation, mais un seul échantillon ne représente pas tout le trafic.
Signal correct, authentification alignée :
spf=pass smtp.mailfrom=em.yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass
Protocole de rétablissement
Si Google Postmaster Tools affiche "Bad", le rétablissement peut demander 2-4 semaines ou davantage d'envois structurés et de qualité. Ce délai n'est pas garanti et il n'existe pas une seule méthode valable dans tous les cas. Procédez par étapes et observez les réponses du fournisseur avant d'augmenter le volume.
Phase 1 : révision de la liste
Ne purgez pas automatiquement les contacts au seul motif qu'ils n'ont ni ouvert ni cliqué depuis 90 jours, car la mesure des ouvertures est incomplète. Vérifiez le consentement, l'activité réelle, les rejets et les obligations de conservation; supprimez des envois les adresses invalides confirmées et les destinataires qui n'attendent pas les messages. Si une même adresse renvoie deux fois User Unknown, analysez les codes d'état améliorés et votre mécanisme de suppression avant le lot suivant.
Phase 2 : correction technique
Ne passez pas DMARC de p=none à p=quarantine sans autorisation, sans étudier les rapports et sans recenser tous les expéditeurs légitimes. Déployez la politique progressivement; la quarantaine réduit certains abus, mais n'empêche pas à elle seule toute usurpation. Si vous utilisez des clés DKIM de 1024 bits, vérifiez l'algorithme, la compatibilité et la politique actuelle du fournisseur avant de passer à 2048 bits et de mettre à jour le DNS. Le guide des enregistrements DNS requis présente le format prévu pour les domaines TrekMail.
Phase 3 : montée en charge progressive
Commencez par les destinataires qui attendent le message et dont l'activité récente repose sur des signaux fiables, pas uniquement sur une ouverture au cours des 30 derniers jours. Le calendrier suivant est illustratif et doit être adapté au fournisseur, à la capacité et aux réponses :
- Jour 1 : 50 messages
- Jour 2 : 100 messages
- Jour 3 : 200 messages
- Jour 4 : 400 messages
Consultez chaque jour les données disponibles. Si la réputation recule, une pause de 48 heures suivie d'un retour au volume précédent peut être une option, et non une règle universelle. Adaptez le plan aux codes et aux politiques en vigueur.
Hygiène de l'infrastructure : problèmes peu visibles
Deux aspects de l'infrastructure peuvent nuire à la réputation sans produire de signal évident. Même si l'authentification est correcte, examinez le transport chiffré et le pool d'adresses IP avec les autres facteurs.
Politique TLS
De nombreux fournisseurs attendent TLS lorsqu'il est disponible, et certains flux ou certaines politiques imposent le chiffrement. Cela ne signifie pas que chaque MTA doive exiger TLS 1.2 pour toutes les destinations : SMTP peut utiliser TLS de manière opportuniste ou appliquer des politiques obligatoires ciblées. Vérifiez la configuration et les exigences actuelles de TrekMail ou de votre fournisseur.
Autres expéditeurs sur une IP partagée
Sur un hébergement partagé économique ou l'offre gratuite d'un prestataire d'envoi, vous pouvez partager une IP avec des milliers d'expéditeurs. Si l'un d'eux envoie du spam, l'IP peut être inscrite dans Spamhaus SBL et affecter vos messages, même si votre domaine n'est pas à l'origine de l'abus. Les conséquences et la correction dépendent de la liste et du fournisseur.
Au-delà de 100k/mois, une IP dédiée peut offrir davantage de contrôle, mais elle n'est pas systématiquement préférable et demande un volume suffisant ainsi qu'une gestion active. En dessous, un fournisseur qui administre correctement son pool ou un SMTP externe peut convenir. L'option BYO SMTP de TrekMail permet de connecter Amazon SES, SendGrid ou Mailgun lorsque le forfait le prend en charge; cela ne signifie pas nécessairement que l'IP vous appartient, qu'elle est sous votre contrôle exclusif ou qu'elle jouit d'une bonne réputation.
La place de TrekMail
La réputation du domaine est une contrainte opérationnelle, pas une variable marketing. Elle exige un DNS précis, une gestion responsable des destinataires et une infrastructure de sortie adaptée.
Si vous gérez plusieurs domaines, consultez le guide de l'hébergement de messagerie multidomaine pour les structurer et limiter les risques partagés. Pour approfondir l'authentification, les principes de sécurité de la messagerie détaillent les politiques DMARC et la rotation des clés DKIM.
Selon la configuration et le forfait en vigueur, TrekMail peut fournir des fonctions de réception comme le stockage à tarif fixe, les boîtes IMAP, le routage catch-all et la migration côté serveur, sans tarification par utilisateur dans les offres décrites. Pour l'envoi, vous connectez un fournisseur SMTP compatible. L'assistant facilite la configuration de SPF/DKIM/DMARC lors de l'intégration, mais vous devez valider le DNS et chaque flux; il ne garantit pas l'authentification automatique de tous les messages.
L'offre décrite annonce des forfaits à partir de $3.50/mois. Elle mentionne aussi un essai gratuit de 14 jours nécessitant une carte et un forfait Nano sans carte, présenté comme gratuit, avec 10 domaines et 5 GB. Les prix, limites, fonctions et conditions peuvent évoluer; consultez trekmail.net/pricing avant de souscrire.
Résumé
Parmi les causes fréquentes de dégradation figurent un taux de plaintes supérieur à 0.3%, un défaut d'alignement DMARC chez un prestataire d'envoi, le dépassement de la limite de 10 recherches SPF et les rejets définitifs. Ce ne sont pas les seules causes, et chacune suit son propre parcours de diagnostic.
Si la réputation est déjà dégradée, révisez la liste selon des critères fiables, corrigez progressivement la couche technique et augmentez le volume en fonction des réponses. Deux à quatre semaines ne sont qu'un ordre de grandeur possible; il n'existe ni délai fixe ni protocole unique.
Vérifiez votre DNS aujourd'hui au moyen de requêtes autorisées. Si vous trouvez une erreur, planifiez sa correction et validez-la avant la prochaine campagne.
