Délivrabilité des emails : gestion et diagnostic

La délivrabilité des emails était souvent traitée comme une installation de base : ajouter un domaine, copier quelques enregistrements DNS et passer à autre chose. Cette approche est insuffisante en 2025 et 2026. Si les factures n'arrivent plus, les réponses des clients disparaissent ou Microsoft retourne des erreurs 421 et 550, examinez l'exploitation de la messagerie plutôt que de supposer un problème uniquement marketing.

Pour la configuration générale, lisez la messagerie professionnelle. Ce guide suppose que vous utilisez déjà votre domaine et souhaitez maintenir les envois. La délivrabilité combine des systèmes évolutifs, différents modes de panne et des erreurs potentiellement coûteuses. L'acceptation SMTP ne garantit pas le placement en boîte de réception.

Ces systèmes peuvent être étudiés. Séparez authentification, infrastructure, réputation et réponse aux incidents : chaque problème semblera moins arbitraire.

Ce qui a changé après 2024

La messagerie demande un suivi, pas seulement une configuration initiale. Gmail et Yahoo ont renforcé leurs exigences en février 2024. Google indique qu'un domaine ayant atteint son seuil d'expéditeur en nombre peut conserver cette classification. Il faut donc entretenir l'authentification, maîtriser les signalements et surveiller le fonctionnement au-delà du lancement.

Google décrit les expéditeurs en nombre comme des domaines envoyant près de 5,000 messages ou plus aux comptes Gmail personnels en 24 heures, avec agrégation au niveau du domaine principal. Ainsi, alerts.example.com, billing.example.com et marketing.example.com sont comptabilisés ensemble. Séparer les sous-domaines ne contourne pas ce calcul et ne garantit pas l'isolation de réputation.

Les petites équipes peuvent ignorer cette portée en pensant que seules les grandes newsletters sont concernées. Les exigences propres aux envois en nombre sont plus strictes, mais authentification de base et bonnes pratiques comptent aussi pour les autres messages. Un domaine récent peut être limité pour différentes raisons avant d'atteindre de gros volumes.

Google recommande de maintenir le taux de spam signalé par les utilisateurs sous 0.1% et d'éviter 0.3% ou plus dans sa métrique applicable. Vérifiez la portée actuelle pour votre trafic : ces seuils ne sont ni une garantie universelle de livraison ni une mesure de tous les envois.

Trois vérifications essentielles pour l'authentification

SPF, DKIM et DMARC fournissent des contrôles complémentaires. SPF évalue l'autorisation d'une IP pour une identité d'enveloppe SMTP. DKIM vérifie une signature et l'intégrité des données signées; il ne certifie pas l'innocuité du message. DMARC exige une voie validée et alignée sur le From visible. Les résultats influencent l'évaluation du destinataire, mais un échec isolé ne détermine pas toujours le traitement final.

Beaucoup d'équipes connaissent les sigles. La difficulté est de reconnaître leur comportement sur les parcours réels.

SPF : utile, mais facile à mal configurer

SPF publie dans le DNS une politique d'autorisation pour le domaine évalué, généralement celui de l'expéditeur d'enveloppe. Il est important, mais présente deux difficultés opérationnelles fréquentes.

D'abord, le transfert peut faire échouer SPF. Le destinataire voit l'IP du relais, pas celle de l'expéditeur original. Si l'identité d'enveloppe reste inchangée et que la nouvelle IP n'est pas autorisée, SPF échoue. Il ne couvre donc pas seul tous les parcours indirects et ne garantit pas la délivrabilité.

Ensuite, il existe un budget de termes nécessitant des recherches DNS. RFC 7208 fixe une limite de 10 durant l'évaluation, y compris les termes concernés imbriqués. La dépasser, et non simplement l'atteindre, peut produire permerror même si le TXT semble correct.

example.com. TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.trekmail.net -all"

Cet enregistrement est illustratif, pas prêt à publier. Les dépendances imbriquées peuvent dépasser le budget, et les valeurs des prestataires peuvent changer. Vérifiez les autorisations actuelles et retirez les services obsolètes après examen de l'inventaire.

DKIM : une voie qui peut survivre au transfert

DKIM signe des données du message avec une clé privée et publie la clé de vérification dans le DNS. Si SPF échoue lors d'un transfert, une signature DKIM valide et alignée peut permettre à DMARC de réussir.

Des clés anciennes ne respectant pas les exigences du destinataire peuvent poser problème. Les modifications après signature aussi : avertissement, pied de page ou réécriture des données signées peuvent invalider la vérification. L'effet dépend des éléments signés et de la canonicalisation utilisée.

dkim._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

La clé présentée est incomplète. Lors d'une rotation, publiez le nouveau sélecteur avant de changer les signatures, testez chaque parcours et conservez l'ancienne clé publique tant que des messages signés sont encore en transit ou en attente. Une rotation partielle peut produire des échecs peu visibles pour l'utilisateur.

DMARC : l'alignement souvent oublié

DMARC publie une politique demandée pour les messages n'obtenant ni SPF validé et aligné ni DKIM valide et aligné. Le destinataire garde ses décisions locales. SPF validé sans alignement ne suffit pas, pas plus qu'une signature DKIM valide non alignée, sauf si une autre voie remplit les conditions.

Shopify, Help Scout, outils d'assistance, CRM, marketing et facturation peuvent envoyer en votre nom. L'authentification technique peut réussir et DMARC échouer si aucune identité n'est alignée sur le domaine visible. Vérifiez les options d'authentification personnalisée de chaque service.

Vous envoyez depuis billing@yourdomain.com. Le prestataire signe avec d=vendor.com. SPF valide l'IP pour son identité et DKIM valide sa signature. Dans cet exemple, DMARC échoue car aucune identité validée n'est alignée sur yourdomain.com.

Si le comportement varie entre les outils, examinez d'abord les identités. Une configuration héritée peut réunir 10 ou 15 expéditeurs, avec seulement quelques-uns correctement alignés. Le mode relâché accepte le même domaine organisationnel; le mode strict exige une correspondance exacte.

Pour le DNS, consultez ajouter un domaine et les enregistrements DNS requis de TrekMail. Ils donnent une base pour configurer et tester les parcours avant d'interpréter la réputation.

La réputation influence aussi la délivrabilité

Il n'existe pas de score universel déterminant toute la livraison. Chaque destinataire peut combiner authentification, réputation des domaines et IP, signalements, échecs de livraison, qualité des listes, régularité et comportement des utilisateurs. Ces signaux peuvent influencer boîte de réception, spam, limitation ou rejet.

Le DNS paraît souvent plus facile à contrôler parce que ses enregistrements sont visibles. La réputation est moins directe, mais mérite un suivi une fois l'authentification correctement configurée.

Google recommande aux expéditeurs en nombre de rester sous 0.1% de spam signalé et d'éviter 0.3% ou plus. Trois signalements parmi 1,000 messages livrés en boîte de réception atteindraient ce dernier seuil dans cet exemple; ne le calculez pas automatiquement sur tous les envois.

Si peu de messages arrivent en boîte de réception, chaque signalement peut représenter une part plus importante de cette métrique. Classement et signalements peuvent être liés, mais les données disponibles ne permettent pas toujours de démontrer une boucle causale ou d'expliquer chaque message.

L'historique d'envoi peut aussi compter. Après plusieurs semaines d'inactivité, reprendre brutalement tout le volume peut provoquer des limitations. Envisagez une progression du trafic consenti et surveillez les réponses, sans supposer un délai universel de montée en charge.

Gardez dans votre procédure les règles de montée en charge du domaine et pourquoi les emails arrivent dans le spam. Vérifiez leur portée actuelle et adaptez les contrôles aux parcours.

Les vérifications d'infrastructure à ne pas oublier

SPF, DKIM et DMARC corrects ne prouvent pas la délivrabilité. DNS inverse, TLS, désabonnement, réputation du relais et modifications pendant le transfert peuvent fournir d'autres signaux. Examinez-les lorsque l'authentification semble correcte mais que le traitement change.

Commencez par l'IP qui livre réellement au destinataire. Elle doit disposer d'un PTR approprié vers un nom résolvant à nouveau vers cette IP. Cela relève généralement du propriétaire de l'IP ou du prestataire SMTP, pas du registraire du domaine. Certains destinataires exigent cette cohérence et peuvent rejeter les connexions qui ne la respectent pas.

Vérifiez TLS à chaque relais SMTP pertinent et les exigences applicables. Un relais négociant mal le transport peut affecter l'envoi. SMTP peut utiliser TLS opportuniste selon la configuration; cela ne constitue pas un chiffrement de bout en bout du contenu.

Pour le marketing soumis à cette exigence, vérifiez le désabonnement en un clic. RFC 8058 définit le mécanisme et ses en-têtes :

List-Unsubscribe: <https://example.com/unsub/abc123>, <mailto:unsubscribe@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

POST compte parce que les systèmes de sécurité peuvent visiter automatiquement les liens. Un GET désabonnant immédiatement peut retirer des abonnés par erreur. Testez le mécanisme complet, avec un point de terminaison HTTPS fonctionnel pour POST et une signature DKIM valide couvrant les deux en-têtes, pas seulement leur présence.

Les transferts vers Gmail ou Outlook demandent aussi des tests. Si l'IP change tandis que l'enveloppe conserve une identité non autorisée pour le relais, SPF peut échouer. SRS peut permettre SPF pour une nouvelle identité sans l'aligner sur le From original; DKIM valide et aligné peut préserver DMARC. Consultez transférer la messagerie du domaine vers Gmail et le transfert d'email pour examiner ces parcours.

Un diagnostic initial en 10 minutes

Lors d'un incident, une courte séquence aide à cerner les causes. Vérifiez si le message est sorti du système, lisez la réponse SMTP, examinez les en-têtes disponibles et distinguez authentification, réputation, routage et filtrage du destinataire. Le délai de résolution dépend des données et des systèmes impliqués.

Ne devinez pas. Suivez ces contrôles :

1. Examiner les journaux sortants : message envoyé, différé, supprimé ou abandonné avant la tentative de livraison ?
2. Lire la réponse complète. Un 550 décrivant une erreur d'authentification n'est pas un 421 de limitation; le chiffre seul ne suffit pas.
3. Obtenir les en-têtes du message reçu ou le .eml original. Examiner Authentication-Results ajouté par un serveur récepteur de confiance, Return-Path et le domaine DKIM d=.
4. Déterminer si un seul parcours est touché ou plusieurs. Une application SaaS peut avoir une configuration différente de la correspondance habituelle.
5. Rechercher les changements récents : domaine, relais, pied de page, CRM ou règle de transfert. Confirmer leur lien avec l'incident plutôt que le supposer.

Exemples d'indices SMTP, dont le texte dépend du prestataire :

550 5.1.1  User unknown
550 5.7.1  Access denied or policy block
421 RP-001 Temporary throttle on new or suspicious sender
550 5.7.515 Authentication failure or alignment problem

Si le message arrive dans le spam, les en-têtes du destinataire peuvent fournir des preuves. Cet exemple montre des validations d'authentification, pas une garantie de boîte de réception :

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Des résultats comme spf=softfail, dkim=neutral ou dmarc=fail doivent être interprétés ensemble. Un Return-Path différent du From ne prouve pas seul une erreur : l'alignement configuré et les autres voies validées comptent. Contenu et politiques du destinataire peuvent intervenir même avec une authentification correcte.

Approche précédente et approche actuelle pour la délivrabilité

Une approche précédente traitait la messagerie comme un produit de boîtes. Une autre traite la délivrabilité comme une exploitation avec responsables, portée des incidents et contrôles répétables. Pour plusieurs domaines, cette organisation peut faciliter le diagnostic sans supprimer les incidents.

Selon ses fonctions actuelles, TrekMail propose hébergement multidomaine à tarif fixe, stockage mutualisé, création de comptes par invitation et migration IMAP des boîtes. La source permet votre propre SMTP sur Nano et décrit SMTP géré sur les offres payantes à partir de $3.50 par mois. Vérifiez prix, facturation, limites et disponibilité actuels. Séparer hébergement et envoi peut faciliter la gestion sans séparer toute la réputation.

Pour de nombreux domaines, comparez ce modèle à des configurations partagées, notamment avec cPanel. Un parcours commun peut propager des problèmes entre clients, mais tous les déploiements ne sont pas identiques. Inventaire multidomaine et contrôles DNS peuvent aider à localiser les erreurs; contrôles de comptes et tests restent nécessaires.

Pour établir vos procédures internes, poursuivez avec l'hébergement email multidomaine et la gestion de la messagerie des clients.

À quoi ressemble une messagerie bien entretenue

L'objectif est prévisible : DNS vérifié, authentification alignée, peu de signalements, volume progressif et outils testés avant activation. Les transferts sont conçus explicitement. En cas de panne, journaux et en-têtes aident à cerner la cause, mais des informations supplémentaires du destinataire peuvent être nécessaires.

C'est un objectif opérationnel, pas de la magie ni une liste générique remplaçant les tests.

Comme base pratique, adoptez ces contrôles :

1. Une politique SPF par nom de domaine, avec les autorisations nécessaires.
2. DKIM valide sur tous les parcours sortants légitimes.
3. DMARC publié et surveillé; application des mesures après inventaire, tests et plan de retour arrière.
4. Chaque service SaaS avec SPF validé et aligné ou DKIM valide et aligné.
5. Augmenter progressivement le trafic consenti sur les domaines nouveaux ou inactifs.
6. Supprimer les adresses inexistantes confirmées et classer les autres erreurs permanentes selon leur code.
7. Maintenir le spam signalé sous 0.1% dans la métrique et le trafic concernés.
8. Tester transfert et désabonnement avant les campagnes.

Acheter une boîte plus sophistiquée ne résout pas seul la délivrabilité. Il faut exploiter la messagerie comme une infrastructure : DNS entretenu, parcours clairs et contrôles. Selon l'offre, TrekMail peut fournir domaines personnalisés, boîtes IMAP, catch-all, SMTP externe ou géré, transfert, migration des boîtes et accès API avec des conditions sans frais par utilisateur. Vérifiez ressources et limites actuelles sans supposer de garantie de livraison.

Si chaque incident demande de reconstruire toute la configuration, améliorez le processus ou évaluez une autre plateforme. Dans les deux cas, ne traitez plus la délivrabilité comme une tâche unique. Le suivi continu aide à détecter les risques, sans éliminer toutes les causes de spam.