Améliorer la délivrabilité : une vérification de 30 minutes

Un envoi peut recevoir 250 OK sans apparaître chez le destinataire. L’acceptation par le serveur d’envoi ne confirme ni la remise finale ni le classement en boîte de réception. Pour améliorer la délivrabilité des emails, vérifiez DNS, authentification et réputation. Le guide de la messagerie professionnelle présente le modèle d’ensemble ; voici la procédure de diagnostic.

Quand les messages arrivent dans les indésirables, réécrire leur objet ne suffit pas forcément. Un SPF incorrect, une clé DKIM ancienne ou un défaut d’alignement DMARC peuvent entraîner un filtrage. Des propositions commerciales disparaissent, des réinitialisations de mot de passe tardent et des réponses du support ne sont pas reçues.

Ce guide aide à améliorer la délivrabilité par une première revue d’environ 30 minutes. Cette durée sert à organiser le diagnostic, pas à garantir une résolution.

La revue de 30 minutes pour améliorer la délivrabilité

Examinez les listes de blocage, les files d’attente, SPF, DKIM, l’alignement DMARC, le DNS inverse et les signalements de spam. Cet ordre permet de rechercher les défauts techniques avant de changer le contenu ; la pertinence des messages et la qualité des listes restent importantes.

1. Vérifiez si l’IP d’envoi figure sur Spamhaus ou une autre liste de blocage pertinente.
2. Confirmez que les messages quittent votre serveur ou prestataire SMTP.
3. Contrôlez la syntaxe SPF et la limite de 10 termes déclenchant des recherches DNS.
4. Vérifiez le sélecteur DKIM, la longueur de clé et le domaine signataire.
5. Contrôlez l’alignement DMARC, pas seulement la présence du record.
6. Vérifiez la correspondance entre DNS direct et inverse, puis les signalements de spam.

Dans TrekMail, consultez l’état DNS et les contrôles de records avant toute modification manuelle. Commencez par les enregistrements DNS requis, puis les vérifications de l’état DNS.

Étape 1 : vérifier les listes de blocage de niveau 1

Si l’IP figure dans Spamhaus ZEN, modifier le texte ou relancer les messages peut laisser la cause intacte. Contenez l’envoi concerné, conservez les éléments utiles et recherchez l’origine du problème avant de demander le retrait.

Exemple : une boîte compromise envoie des logiciels malveillants pendant 20 minutes, l’IP est inscrite sur une liste et certains destinataires refusent des factures ou réponses légitimes. L’effet dépend de leurs politiques.

Étape 2 : vérifier que le courrier quitte le système

Une file d’attente peut refléter un blocage interne ou un report demandé par le destinataire ; les deux font partie de la chaîne de remise. Consultez la file MTA ou le tableau de bord SMTP et vérifiez les définitions du prestataire :

• Queued : en attente en raison d’une charge, d’un quota, d’un délai ou d’un report distant.
• Bounced : échec de remise ; lisez la cause et identifiez le système qui l’a produit.
• Sent mais absent : déterminez quelle acceptation cet état confirme avant d’examiner le filtrage.

Contrôler DNS et authentification dans l’ordre

SPF vérifie l’autorisation de l’IP pour MAIL FROM ou HELO lorsque cela s’applique, DKIM les parties signées et DMARC l’authentification alignée sur From. Le DNS inverse contribue à identifier le serveur, sans prouver à lui seul sa fiabilité ni la remise en boîte de réception.

1. Vérifier la limite SPF

Deux problèmes à vérifier sont les records SPF en double et les dépendances trop longues. La limite de 10 concerne les termes déclenchant une recherche DNS, y compris récursivement : a, mx, include, exists, ptr et redirect. Elle ne compte pas simplement tous les paquets DNS ou les include visibles. Son dépassement peut produire une erreur permanente.

dig txt example.com +short

Points à vérifier :

• Un seul enregistrement TXT SPF pour l’identité évaluée, commençant par v=spf1 ; ses chaînes entre guillemets sont concaténées et d’autres TXT de vérification peuvent coexister.
• Pas de +all, qui autorise toute origine.
• Une fin telle que ~all ou -all, selon la politique validée.
• Une chaîne d’include documentée avec ses dépendances récursives.

Exemple à examiner :

example.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:spf.trekmail.net ~all"

Ce record peut respecter la limite ou la dépasser à cause des recherches imbriquées. Pour améliorer la délivrabilité, retirez les autorisations de prestataires réellement désactivés. Ne remplacez pas aveuglément leurs include par des IP fixes, car leur infrastructure peut évoluer.

Pour envoyer avec TrekMail, fusionnez les autorisations dans un seul record et utilisez les valeurs actuelles du panneau. L’exemple ne remplace pas la configuration propre à votre domaine. Pour la mise en place initiale, consultez la configuration du courrier sur son domaine.

2. Vérifier le sélecteur et la clé DKIM

Il faut valider cryptographiquement la signature avec le sélecteur et la clé publique publiés, sur les parties couvertes. Une ancienne clé, un sélecteur absent ou une rotation incomplète peuvent empêcher cette validation même si SPF réussit.

dig txt selector._domainkey.example.com +short

Premiers contrôles :

• Le bon record est présent.
• Si la version est indiquée, elle utilise v=DKIM1 ; ce texte ne prouve pas la validité de la signature.
• La valeur p= contient une clé publique valide et utilisable, pas seulement une chaîne qui lui ressemble.
• Le signataire emploie le sélecteur indiqué dans les en-têtes et la vérification cryptographique réussit.

Un résultat pass dans un outil ne termine pas le contrôle. Pour satisfaire DMARC par DKIM, le domaine signataire doit s’aligner sur le From visible. SPF peut aussi satisfaire DMARC s’il réussit avec un domaine aligné, y compris chez un prestataire externe.

3. Vérifier l’alignement DMARC

DMARC relie SPF ou DKIM au From visible. Publier le record ne suffit pas : au moins une de ces authentifications doit réussir et s’aligner sur ce domaine.

dig txt _dmarc.example.com +short

Exemple de record d’observation :

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Cas à examiner : Return-Path: bounce.provider.com représente sous forme abrégée le domaine de l’adresse réelle de l’enveloppe SMTP, pas un en-tête Return-Path complet valide. Le prestataire signe avec d=provider.com, alors que le From visible est team@example.com. SPF et DKIM peuvent réussir, mais DMARC échouer si aucun domaine ne s’aligne. La politique d’observation de l’exemple n’annule pas les autres filtres et ne garantit pas la remise.

Vérifier chaque flux autorisé peut prendre des heures lorsque plusieurs prestataires interviennent. Dans TrekMail, contrôlez les droits Managed SMTP des plans payants ou conservez votre moteur via BYO SMTP. Séparer hébergement et envoi peut permettre de changer la couche sortante sans déplacer toutes les boîtes ; cela ne garantit pas des réputations indépendantes.

4. Confirmer le DNS inverse par résolution directe

FCrDNS vérifie que le PTR de l’IP désigne un nom dont la résolution directe contient cette même IP. Les destinataires peuvent tenir compte de cette correspondance, mais elle ne prouve ni la confiance ni la remise.

dig -x 203.0.113.10 +short
dig A mail.example.com +short

La résolution directe doit retrouver l’IP initiale ; contrôlez aussi AAAA lorsque nécessaire. Le propriétaire ou prestataire de l’IP maîtrise généralement le PTR. Demandez la correction appropriée et vérifiez les deux sens avant de poursuivre les efforts pour améliorer la délivrabilité.

Surveiller les signalements de spam

Associez une authentification correcte à des messages attendus. Google recommande un taux de spam inférieur à 0.1% et d’éviter qu’il atteigne 0.3% ou davantage. Il s’agit de sa métrique de domaine pour Gmail personnel, soumise à des conditions de disponibilité, pas d’un score universel de délivrabilité.

Des SPF, DKIM et DMARC valides n’annulent pas les signalements des utilisateurs. Consultez régulièrement Google Postmaster Tools, par exemple chaque semaine. Un volume insuffisant peut empêcher l’affichage de données ; leur absence ne prouve pas l’absence de plaintes.

Pour interpréter cette métrique :

• Sous 0.1% : dans l’objectif recommandé, sans confirmer toute la qualité de l’envoi.
• 0.1% - 0.3% : examinez consentement, ciblage et contenu.
• À partir de 0.3% : suspendez les campagnes non essentielles et recherchez la cause avant leur reprise.

Avec plusieurs marques, séparez droits, flux et suivi. Des domaines ou signatures DKIM distincts ne garantissent pas des réputations isolées si l’IP ou l’infrastructure reste partagée. L’hébergement email multidomaine facilite l’organisation, mais ces dépendances doivent être évaluées.

Lire l’erreur de remise avant toute modification

Le code et la réponse complète du destinataire orientent le diagnostic. Corrigez le problème vérifié plutôt que d’ajouter une panne par des changements DNS arbitraires.

Si vous transférez des messages entre systèmes, distinguez les défauts d’authentification du transfert de la réputation du signataire. Le guide de configuration et diagnostic du transfert détaille ces chemins.

Ce qu’il ne faut pas modifier à l’aveugle

Évitez les changements urgents qui effacent les indices ou ajoutent des risques. Changer d’IP sans diagnostic, exclure toute erreur temporaire ou modifier le DNS à 2 heures du matin peut compliquer les 48 heures suivantes.

1. Ne changez pas d’IP pour contourner une liste. Recherchez une éventuelle compromission et planifiez tout changement autorisé ; une nouvelle IP ne garantit pas la confiance.
2. N’excluez pas une adresse au premier échec temporaire. Un 4xx nécessite son contexte et des relances limitées.
3. N’accumulez pas les prestataires dans SPF : retirez ceux qui n’envoient plus de courrier autorisé.
4. N’imposez pas p=reject avant de vérifier les flux autorisés et leur alignement.
5. N’oubliez ni les sous-domaines ni leurs dépendances de réputation partagées.

Deux modèles d’exploitation de la délivrabilité

L’hébergement et l’envoi peuvent être liés ou séparés. La séparation peut simplifier un changement sortant sans migrer chaque boîte, mais compatibilité, quotas et réputation partagée restent à examiner.

Modèle intégré : un prestataire gère les boîtes et l’infrastructure d’envoi. En cas de problème partagé, examinez les options disponibles avant de décider de migrer.

Modèle à envoi séparable : TrekMail réunit hébergement, stockage mutualisé au niveau du compte avec quotas individuels et limites du plan, migration IMAP et administration multidomaine selon le plan. Seul le modèle Nano décrit nécessite votre propre SMTP externe via BYO SMTP pour tous les envois et réponses. La référence historique à des plans payants dès $3.50 par mois comprend Managed SMTP, sous réserve des droits et des paramètres d’un client compatible. L’essai de 14 jours pour les plans payants est décrit avec carte bancaire obligatoire. Vérifiez les conditions actuelles ; Nano peut permettre de tester la réception sans carte lorsqu’il est proposé, sans engagement de permanence.

Cette séparation peut permettre de corriger l’envoi sans reconstruire toute la messagerie. La migration IMAP demande un accès autorisé, la compatibilité, une sauvegarde et la vérification des dossiers et messages, ainsi que DNS et synchronisation finale. Contacts et calendriers doivent être traités séparément.

Comparez licences par utilisateur, quotas mutualisés et souplesse d’envoi selon vos besoins. Garder votre propre prestataire permet de gérer cette couche, sans garantir une réputation indépendante ni supprimer tous les risques partagés.

Conclusion : commencer par les contrôles vérifiables

Pour améliorer la délivrabilité, examinez SPF, les signatures DKIM, l’alignement DMARC, le DNS inverse, les signalements et les services autorisés. Ces contrôles aident à localiser les erreurs ; consentement et qualité des destinataires demeurent essentiels.

Pour améliorer la délivrabilité avec un modèle multidomaine, comparez stockage, conditions de migration IMAP et droits BYO SMTP ou Managed SMTP du plan. Les tarifs TrekMail permettent de vérifier les conditions actuelles et les éventuels frais.

Consultez les questions fréquentes de Google sur les exigences d’envoi et la spécification SPF dans la RFC 7208. Si le problème persiste, récupérez les en-têtes et journaux pertinents avec autorisation et examinez la chaîne d’erreurs plutôt que de deviner.