Délivrabilité et DNS

Bonnes pratiques de délivrabilité des e-mails qui fonctionnent

Par Alexey Bulygin
Bonnes pratiques pour améliorer la délivrabilité des e-mails

Les bonnes pratiques de délivrabilité ne consistent pas à traquer les mots interdits ou compter les emojis. Elles commencent par l'authentification, l'alignement, la réputation et la discipline opérationnelle. Si ces éléments échouent, le message peut quitter votre serveur puis être rejeté à destination.

L'application indique envoyé et le journal SMTP affiche 250 OK, mais le prospect ne répond pas, la relance de facture disparaît ou le message d'assistance arrive dans le spam. Cet écart entre envoyé et vu coûte du temps et de l'argent.

Pour comprendre les signaux de confiance, consultez la réputation de l'expéditeur. Cet article est un guide pratique des contrôles, pannes courantes et améliorations de placement en 2025-2026.

Que sont les bonnes pratiques de délivrabilité ?

Ce sont les mesures techniques et opérationnelles qui aident un courrier légitime à atteindre la boîte plutôt que le spam ou le rejet. Les principaux leviers sont SPF, DKIM, l'alignement DMARC, le DNS inverse, TLS, les plaintes, les rebonds et un rythme stable. Le contenu vient ensuite.

Levier majeurCe qu'il affectePourquoi il compte davantage
SPF, DKIM, DMARCIdentité et confianceLes grands fournisseurs les utilisent comme contrôles de base
Réputation du domaine et de l'IPBoîte, spam ou blocageL'historique des plaintes et rebonds vous suit
Régularité du volumeLimites et ralentissementLes pics soudains ressemblent à des abus
FCrDNS et TLSLégitimité réseauUn PTR absent ou un transport faible peut déclencher les filtres
Hygiène des listes et désabonnementTaux de plainteLes expéditeurs sains peuvent se nuire ici
Aspect de l'objetScore de contenu mineurCompense rarement une infrastructure cassée
Rapport texte-imageAnciennes heuristiques antispamLes filtres modernes évaluent tout le message

Les conseils habituels commencent par la rédaction. Les pratiques efficaces commencent dans DNS, les en-têtes, journaux et retours des destinataires. Sans ces couches solides, optimiser l'objet apporte peu.

Un fondateur envoie 40 propositions depuis un nouveau domaine et reçoit des réponses. Il connecte ensuite trois outils SaaS, ajoute cinq inclusions SPF, transfère vers Gmail et expédie 2,500 messages de lancement en un après-midi. Le texte n'a pas changé, mais la délivrabilité peut chuter.

Corrigez d'abord l'authentification

S'il ne faut faire qu'une chose, corrigez l'authentification. SPF, DKIM et DMARC prouvent qui peut envoyer, si le message a changé et si le domaine De correspond à l'identité authentifiée. C'est le socle.

Les exigences publiées par Google sont une référence : les expéditeurs en nombre ont besoin de SPF, DKIM, d'un enregistrement DMARC, d'un DNS direct et inverse valide, de TLS et de faibles taux de spam. Consultez la FAQ des consignes aux expéditeurs de Google.

SPF : valide et court

SPF indique quels serveurs peuvent envoyer pour votre domaine. Il contrôle l'expéditeur de l'enveloppe, pas la ligne De visible. Un enregistrement propre vaut mieux que cinq enregistrements mal entretenus.

L'échec courant survient quand les fournisseurs ajoutés dépassent la limite de 10 requêtes DNS définie dans la RFC 7208. SPF peut alors renvoyer une erreur permanente que certains destinataires traitent comme un échec d'authentification.

dig txt example.com +short

# Expect one SPF TXT record, not two
# Example:
# "v=spf1 include:spf.trekmail.net include:_spf.google.com -all"

Pour aller plus loin, consultez l'enregistrement SPF pour les e-mails. En bref :

  1. Gardez un enregistrement SPF par domaine.
  2. Retirez les fournisseurs inutilisés.
  3. N'empilez pas les outils sans contrôle.
  4. Ne comptez pas seulement sur SPF pour le courrier transféré.

DKIM : protège le courrier transféré

DKIM signe le message avec la clé privée du domaine pour vérification par une clé DNS publique. Il permet souvent à DMARC de réussir quand SPF échoue pendant un transfert.

Utilisez des clés de 2048-bit si votre fournisseur les accepte. Employez la canonicalisation détendue sauf raison précise. Faites tourner les sélecteurs de façon planifiée. Une bonne gestion protège les transferts.

dig txt selector1._domainkey.example.com +short

# Expect something like:
# "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Certains panneaux DNS altèrent les longues valeurs DKIM. L'enregistrement semble présent dans l'interface, mais le résolveur renvoie des données invalides. Après un déplacement DNS, vérifiez d'abord l'enregistrement actif.

DMARC : l'alignement échoue souvent

DMARC réussit si SPF ou DKIM réussit et s'aligne avec le domaine De visible. SPF et DKIM peuvent réussir sans correspondre au domaine De, entraînant un échec DMARC.

dig txt _dmarc.example.com +short

# Good starting point:
# "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Suivez ce déploiement :

  1. Commencez avec p=none et collectez les rapports.
  2. Identifiez tous les expéditeurs légitimes, y compris les anciens outils et tâches cron oubliées.
  3. Configurez DKIM ou des domaines return-path personnalisés sur chaque plateforme.
  4. Passez à quarantine, puis reject lorsque l'alignement est propre.

Pour un fondateur, cela concerne souvent un workspace et un outil marketing. Pour une petite équipe, il faut retrouver un expéditeur ajouté par les ventes ou l'assistance. Pour une agence, standardisez avant qu'un mauvais réglage client n'en affecte dix autres.

Corrigez les lacunes d'hygiène réseau

Les pratiques ne s'arrêtent pas à SPF, DKIM et DMARC. Les destinataires évaluent aussi l'IP, le DNS inverse et le chiffrement. S'ils sont déficients, le courrier peut être ralenti ou bloqué avant l'analyse du contenu.

FCrDNS est nécessaire

L'IP d'envoi doit avoir un PTR vers un hostname qui résout à son tour vers la même IP. Les serveurs cloud nus l'oublient souvent.

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

dig mail.example.com +short
203.0.113.10

Si les valeurs diffèrent, corrigez-les d'abord. Google cite les PTR absents ou discordants et le DNS direct parmi les problèmes des expéditeurs.

TLS doit être imposé

Corrigez tout transport faible ou non chiffré. TLS est une hygiène de base; son absence peut être pénalisante.

Selon la configuration publiée, le SMTP géré de TrekMail utilise la soumission authentifiée sur 465 ou 587, signe avec le DKIM du domaine dans les offres payantes et standardise le chemin d'envoi. Consultez Enregistrements DNS requis et SMTP TrekMail géré.

Protégez la réputation par des habitudes régulières

Les dommages de réputation viennent souvent d'erreurs ordinaires. Plaintes, rebonds, listes anciennes et volumes irréguliers pèsent davantage que les mots tape-à-l'œil. La réputation se construit lentement et peut se dégrader en une semaine.

Surveillez le seuil de plaintes

Google indique que les expéditeurs en nombre devraient rester sous 0.1% de spam et éviter 0.3% ou plus. Trois plaintes pour mille messages distribués peuvent créer des difficultés.

Le désabonnement en un clic est donc important pour les promotions. Il réduit le risque que des destinataires frustrés choisissent « Signaler comme spam ».

Gardez les rebonds bas

Les rebonds définitifs sont un signal de qualité. Continuer à écrire à des adresses mortes peut nuire à l'évaluation de la liste. Retirez vite les destinataires invalides et évitez les anciens CSV non vérifiés.

Une petite agence a migré cinq domaines et réutilisé une vieille liste pour sa première newsletter. La création était correcte, pas le taux de rebond. Deux semaines plus tard, même des messages individuels arrivaient dans le spam, car la réputation partagée avait souffert.

Réchauffez progressivement les nouveaux domaines

Les nouveaux domaines devraient commencer petit et croître régulièrement. Les conseils TrekMail recommandent de ne pas envoyer des milliers de messages immédiatement depuis un domaine neuf. Commencez par du courrier personnel et attendu.

Une règle prudente pour un domaine froid est de 20 à 50 e-mails par jour la première semaine, puis une croissance graduelle. Pour un volume élevé immédiat, utilisez une configuration établie avec un véritable historique d'engagement.

Le transfert demande un traitement particulier

Le transfert casse souvent SPF, car le serveur intermédiaire ne figure pas dans l'enregistrement d'origine. C'est normal. La solution passe par DKIM aligné et, au niveau du domaine, une réécriture correcte de l'expéditeur.

Consultez le transfert d'e-mail de domaine et le transfert SRS. Si le courrier disparaît, examinez les résultats d'authentification avant le texte.

Adaptez le processus à la taille de l'équipe

Les pratiques varient avec les domaines, utilisateurs et outils. Les règles restent, mais le mode d'échec change : négligence chez un fondateur, transmission dans une équipe, échelle dans une agence.

Fondateurs seuls

Gardez un expéditeur transactionnel et un autre pour les campagnes si nécessaire. Vérifiez SPF, DKIM et DMARC avant le lancement. N'envoyez pas à plein volume depuis un domaine neuf. En cas d'échec, inspectez DNS et les en-têtes avant de réécrire.

Petites équipes et PME

Attribuez les responsabilités. Quelqu'un doit connaître les outils autorisés, gérer les rapports DMARC et approuver les fournisseurs. Beaucoup de problèmes viennent d'un manque de responsabilité, pas d'un mystère technique.

Agences et MSP

Standardisez. Avec des dizaines de domaines, le travail manuel dérive : un compte a deux SPF, un autre un sélecteur DKIM erroné, un troisième transfère vers Gmail sans SRS. Lors de la découverte, le placement peut déjà avoir baissé.

TrekMail vise les opérations multidomaines avec boîtes IMAP, stockage mutualisé, migration IMAP, catch-all, SMTP propre ou inclus, transfert et API aux niveaux supérieurs, selon les fonctions actuelles. Starter est affiché dès $3.50/month; les offres payantes ont un essai de 14-day avec carte et Nano reste gratuit sans essai.

Ancienne et nouvelle méthode pour préserver la délivrabilité

Les pratiques sont faciles à énoncer et pénibles à maintenir. L'ancienne méthode disperse outils, changements DNS et responsabilités. La nouvelle centralise la vérification et les boîtes afin de réduire la dérive de configuration.

Ancienne méthodeNouvelle méthode
Chaque domaine a ses habitudes DNS et expéditeursUne configuration reproductible pour domaines et envoi
Les transferts cassent SPF sans être remarquésDKIM aligné et configuration adaptée au transfert réduisent les échecs
La migration déplace manuellement les boîtes et risque l'historiqueLa migration IMAP intégrée aide à contrôler la transition
Le prix par utilisateur pousse aux compromisLa gestion multidomaine forfaitaire rend l'administration plus prévisible

Cela ne garantit pas l'arrivée en boîte; personne ne peut la promettre. Mais des outils qui réduisent la dérive facilitent l'application des pratiques. Ils peuvent réduire les enregistrements cassés, expéditeurs inconnus et erreurs de migration.

Conclusion : les pratiques qui comptent

La délivrabilité fonctionne mieux comme infrastructure que comme exercice de rédaction. Authentifiez chaque expéditeur, alignez DMARC, maintenez DNS inverse et TLS, contrôlez plaintes, rebonds, transferts et pics, puis optimisez le contenu.

Pour gérer un ou cent domaines, TrekMail propose selon ses fonctions actuelles un hébergement multidomaine forfaitaire avec boîtes IMAP, stockage mutualisé et migration IMAP. Consultez les offres et le niveau gratuit ou l'essai payant sur https://trekmail.net/pricing.

Partager cet article

Nous utilisons les technologies nécessaires au fonctionnement et à la sécurité de TrekMail. En confirmant, vous autorisez aussi des analyses limitées et la mesure publicitaire décrites dans notre Politique relative aux cookies.

Se connecter à TrekMail

Accédez à votre tableau de bord, vos boîtes et vos DNS.

ou

12 caractères les mots de passe correspondent

ou

E-mail de réinitialisation envoyé

Si un compte existe pour cette adresse, nous venons d’envoyer les instructions de réinitialisation du mot de passe.

En continuant, vous acceptez les Conditions d’utilisation et la Politique de confidentialité de TrekMail.