Problèmes de délivrabilité Gmail/Outlook : les vérifications qui comptent en 2025

octobre 25, 2025 • février 3, 2026 • Lecture : 26 min • Views: 9

Cet article vous a aidé ?

Vous avez envoyé un e‑mail tout à fait raisonnable. Le client ne l’a jamais vu. le support jure que « c’est Gmail », les commerciaux jurent que « c’est Outlook », et votre PDG transfère des captures d’écran d’une boîte de réception vide comme si c’était une pièce à conviction médico‑légale.

En 2025, la délivrabilité ne se résume plus à « mon serveur SMTP a‑t‑il parlé le protocole » mais à « ai‑je prouvé — cryptographiquement, réputationnellement et opérationnellement — que je mérite d’entrer dans la boîte de réception ». Ce guide se concentre sur les vérifications qui changent réellement les résultats : quoi regarder en premier, ce qui est du bruit, et quels correctifs tiennent au prochain envoi.

Playbook de diagnostic rapide (premiers 15 minutes)

Quand la livraison vers Gmail ou Outlook « casse soudainement », il est tentant de tout modifier en panique. Ne le faites pas. Il faut trouver le goulot d’étranglement : authentification, réputation, contenu ou transport.

0. Établir le mode d’échec (2 minutes)

Bounce : vous avez reçu un NDR/DSN. Bien. Il contient des indices.
Deferral : réponses 4xx ; le courrier reste en file et peut « finalement » être délivré.
Spam : livré mais mis en courrier indésirable ; c’est souvent une question de politique + réputation.
Disparition silencieuse : le système d’envoi dit « livré », le destinataire ne le trouve pas. Peut être spam/quarantaine, rejets côté transport, ou règles de routage internes.

1. Vérifiez d’abord l’alignement d’authentification (5 minutes)

En 2025, SPF ou DKIM réussis ne suffisent pas. L’alignement avec le domaine visible dans le From est crucial, notamment pour Gmail et Microsoft.

Récupérez un message réel et inspectez Authentication-Results.
Confirmez DKIM=pass pour votre domaine (ou un sous‑domaine aligné).
Confirmez SPF=pass et que le domaine SPF est aligné avec le From (ou que l’alignement relax DMARC le couvre).
Vérifiez DMARC=pass. Si DMARC échoue, tout le reste est aléatoire.

2. Puis vérifiez les signaux de réputation (4 minutes)

Pointe soudaine de rebonds, plaintes ou destinataires inconnus ? C’est la mort de la réputation par feuille de calcul.
Nouveau IP d’envoi ou changement de fournisseur ? Le warm‑up compte. Oui, même si vous « n’envoyez que des reçus ».
Êtes‑vous sur une liste de blocage ? Pas besoin de doctorat — regardez les logs SMTP pour des rejets de type RBL.

3. Ensuite seulement vérifiez le transport (4 minutes)

Échouez‑vous la négociation TLS, les contrôles MTA-STS, ou recevez‑vous des limitations de débit ?
Votre file grossit‑elle et les relances sont‑elles en backoff ?
Vos connexions sortantes proviennent‑elles de l’IP que vous pensez ?

Si vous effectuez ces trois étapes dans l’ordre, vous évitez l’incident classique où tout le monde discute du contenu alors que votre sélecteur DKIM a disparu du DNS.

Comment la livraison échoue en 2025 (et pourquoi ça semble aléatoire)

Gmail et Microsoft n’évaluent pas votre e‑mail comme un humain. Ils le notent comme un risque de production. L’authentification est le ticket d’entrée, mais leurs systèmes modélisent aussi l’historique de l’expéditeur, le comportement des destinataires et les schémas qui ressemblent à de l’abus — même si vous « n’envoyez que des factures ».

La boîte de réception moderne est gouvernée par des politiques

Les exigences de Gmail pour les expéditeurs en masse (et le filtrage de plus en plus strict de Microsoft) ont poussé l’industrie vers un socle commun : mails authentifiés, hygiène de listes raisonnable, gestion des plaintes et infrastructure cohérente. Ce n’est pas du « marketing ». C’est de l’hygiène opérationnelle. Votre système de messagerie est une API, et les fournisseurs de boîtes de réception sont la passerelle API la plus opiniâtre avec laquelle vous intégrerez jamais.

Quatre catégories d’échec

Authentification : SPF/DKIM/DMARC mal configurés, cassés par le DNS, ou rompus par le forwarding/la réécriture.
Réputation : nouvelle IP/domaine, plaintes spam, nombreux destinataires inconnus, comptes compromis, ou schémas d’envoi en rafales.
Contenu et formatage : URL suspectes, MIME malformé, List-Unsubscribe manquant, encodages étranges, ou templates « trop parfaits ».
Transport et politique : erreurs TLS, application MTA-STS, limites de débit, déferrals 4xx, ou blocages réseau.

Voici la vérité inconfortable : vous pouvez réussir SPF, DKIM et DMARC et finir quand même dans le spam. Les fournisseurs considèrent l’authentification comme une preuve d’identité, pas comme une permission automatique d’atterrir en boîte de réception.

Une citation à garder au mur

L’espoir n’est pas une stratégie. — General Gordon R. Sullivan

Le débogage de délivrabilité obéit à la même règle. Si vous ne pouvez pas le prouver avec des en‑têtes, des logs et du DNS, vous opérez sur des impressions.

Faits intéressants et contexte historique (édition délivrabilité)

SPF a commencé comme un mécanisme anti‑usurpation, pas comme un booster de délivrabilité. Il a été conçu pour réduire le spoofing en liant « qui peut envoyer » au DNS.
DKIM est issu d’expérimentations de signature de domaine (incluant DomainKeys et Identified Internet Mail) et est devenu le moyen de garantir l’intégrité à travers les sauts — jusqu’à ce que des intermédiaires modifient les messages.
DMARC a formalisé l’« alignement » : il ne suffit pas d’authentifier ; le domaine authentifié doit correspondre (s’aligner) au domaine From visible par les destinataires.
Google et Microsoft ont appris à se méfier des « expéditeurs parfaits » : un contenu uniformément identique ou des schémas d’engagement non naturels peuvent déclencher des alertes, même pour des envois transactionnels légitimes.
La réputation IPv4 est devenue un produit : les pools IP partagés et les IP dédiées existent principalement parce que les fournisseurs notent agressivement l’historique des IP.
ARC (Authenticated Received Chain) existe parce que le forwarding casse SPF et parfois DKIM ; ARC permet aux intermédiaires de préserver les résultats d’authentification à travers les sauts.
BIMI est une fonctionnalité de branding qui a du poids : elle incite les expéditeurs à appliquer DMARC strict parce que l’affichage du logo exige une posture de politique plus forte.
Les filtres anti‑spam sont passés des hacks par mots‑clés aux modèles comportementaux : l’interaction utilisateur (ouvertures, suppressions, réponses, signalements) influence le placement futur.
List-Unsubscribe est devenu un contrôle opérationnel : les fournisseurs s’en servent pour réduire les clics « c’est du spam » en offrant une désinscription propre.

Blague #1 : La délivrabilité des e‑mails, c’est comme un régime — tout le monde jure qu’il « a tout fait correctement », mais les logs se souviennent de ce qui s’est réellement passé.

En‑têtes et codes de rebond : arrêtez de deviner, commencez à lire

Si vous ne lisez pas les en‑têtes brutes et les DSN, vous diagnostiquez les yeux bandés. Gmail et Microsoft incluent assez de métadonnées pour vous dire ce qui a échoué — si vous savez où regarder.

En‑têtes qui comptent

Authentication-Results : SPF/DKIM/DMARC pass/failed et parfois des raisons.
Received chain : confirme l’hôte expéditeur et si une passerelle a réécrit le message.
From, Return-Path, Sender : utilisés pour l’alignement et le routage des rebonds.
Message-ID : utile pour corréler avec les logs ; indique aussi si votre appli génère des IDs étranges.
List-Unsubscribe et List-Unsubscribe-Post : de plus en plus importants pour les envois en masse ; des en‑têtes manquants peuvent nuire.

Codes de statut SMTP : ce qu’ils impliquent opérationnellement

5xx : rejeté. Ce n’est pas un problème de retry. Corrigez la cause.
4xx : différé / temporaire. Souvent limitation de débit, blocage réputationnel soft, ou contrôles de politique transitoires. La stratégie de retry compte.
2xx accepted : accepté par le MTA destinataire, pas nécessairement en boîte de réception. Pour les problèmes de placement en spam, concentrez‑vous sur l’authentification + réputation + contenu.

Tâches pratiques (commandes, sorties, décisions)

Voici des tâches de niveau production que vous pouvez exécuter aujourd’hui. Chaque élément inclut : une commande, un exemple de sortie, ce que cela signifie, et la décision à prendre. Elles supposent un hôte Linux avec Postfix (courant), mais l’analyse DNS et des messages s’applique partout.

Task 1 — Identifier votre IP d’egress réelle (pas celle que vous « pensez » avoir)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.45

Ce que ça signifie : C’est l’IP publique que voient les destinataires (sauf si vous relayer via un provider).

Décision : Toute la réputation, rDNS/PTR et les allowlists doivent correspondre à cette IP. Si vous attendiez une IP différente, stoppez : vous déboguez la mauvaise identité d’expéditeur.

Task 2 — Confirmer le reverse DNS (PTR) existe et correspond à votre stratégie HELO

cr0x@server:~$ dig +short -x 203.0.113.45
mail1.example.com.

Ce que ça signifie : L’IP pointe vers mail1.example.com.

Décision : Configurez Postfix smtpd_banner/myhostname et outbound smtp_helo_name pour que HELO/EHLO soit un nom d’hôte valide qui résout en avant vers la même IP. S’il n’y a pas de PTR, corrigez‑le — Microsoft déteste particulièrement l’absence de rDNS.

Task 3 — Vérifier le DNS direct du nom d’hôte d’envoi (A/AAAA)

cr0x@server:~$ dig +short mail1.example.com A
203.0.113.45

Ce que ça signifie : Le nom direct résout vers l’IP.

Décision : Si le forward et le reverse ne concordent pas, attendez‑vous à plus de throttling et de problèmes de placement en spam. Corrigez le DNS avant de toucher au contenu.

Task 4 — Inspecter l’enregistrement SPF et vérifier le risque de « trop de requêtes DNS »

cr0x@server:~$ dig +short TXT example.com | sed 's/" "/""/g'
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.45 -all"

Ce que ça signifie : SPF autorise Google, Microsoft et une IP spécifique.

Décision : Vérifiez que vos sources d’envoi réelles correspondent. Si vous avez beaucoup de include:, vous pouvez dépasser la limite de 10 requêtes DNS de SPF. Si SPF renvoie parfois « permerror », simplifiez SPF (flatten prudemment, ou réduisez les includes).

Task 5 — Valider SPF pour une IP spécifique avec un vérificateur local

cr0x@server:~$ spfquery -ip 203.0.113.45 -sender bounce@example.com -helo mail1.example.com
result=pass
smtp.comment=domain of bounce@example.com designates 203.0.113.45 as permitted sender

Ce que ça signifie : SPF passe pour le domaine de l’expéditeur d’enveloppe.

Décision : Si cela échoue, corrigez SPF. Si ça passe mais que DMARC échoue ensuite, l’alignement est votre problème (domaine d’enveloppe != domaine From, ou alignement relax non satisfait).

Task 6 — Vérifier que les enregistrements du sélecteur DKIM existent dans le DNS

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtw..."

Ce que ça signifie : Le sélecteur s1 existe et publie une clé publique.

Décision : Si c’est vide ou tronqué, corrigez le DNS (souvent des TXT fractionnés) et re‑signez le courrier. Un sélecteur manquant est une manière nette de se retrouver massivement en dossier spam.

Task 7 — Vérifier la politique DMARC et le mode d’alignement

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=s; aspf=r; pct=100"

Ce que ça signifie : DMARC enforce (quarantaine), alignement DKIM strict, alignement SPF relax.

Décision : Si vous utilisez des envoyeurs tiers, l’alignement DKIM strict (adkim=s) peut les casser à moins qu’ils ne signent avec votre domaine. Décidez de relaxer l’alignement ou reconfigurez les senders pour signer de manière alignée.

Task 8 — Extraire un message en direct des logs (Postfix) et inspecter la réponse de Gmail/Microsoft

cr0x@server:~$ sudo grep -E "to=|status=" /var/log/mail.log | tail -n 20
Jan  3 10:17:12 mail1 postfix/smtp[24177]: 8F2C02A1B3: to=, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=2.1, delays=0.2/0.1/1.2/0.6, dsn=2.0.0, status=sent (250 2.0.0 OK  1704277032 x12-20020a1709032f4c00b003b7c2c1a8d3si1234567plb.123 - gsmtp)
Jan  3 10:18:44 mail1 postfix/smtp[24210]: 1B7D02A1C9: to=, relay=outlook-com.olc.protection.outlook.com[104.47.15.36]:25, delay=45, delays=0.3/0.2/10/34, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 451 4.7.0 Temporary server error. Please try again later. PRX4 (in reply to MAIL FROM command))

Ce que ça signifie : Gmail a accepté ; Microsoft a différé avec une erreur temporaire 4.7.0.

Décision : Les problèmes avec Gmail sont probablement de placement en spam, pas de transport. Pour les déferrals Outlook, vérifiez la limitation de débit, la réputation, et si vous envoyez en rafales. N’essayez pas de « corriger » en augmentant la fréquence des retries ; cela aggrave souvent le throttling.

Task 9 — Inspecter la file Postfix pour les mails bloqués ou en explosion

cr0x@server:~$ mailq | head -n 25
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
1B7D02A1C9      4123 Fri Jan  3 10:18:44  bounce@example.com
                                         user@outlook.com
                                         (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 451 4.7.0 Temporary server error. Please try again later. PRX4 (in reply to MAIL FROM command))

-- 1 Kbytes in 1 Request.

Ce que ça signifie : Vous avez des messages différés en attente pour Outlook.

Décision : Si la file grandit rapidement, il faut limiter la concurrence sortante vers Microsoft, améliorer la réputation, ou déplacer les envois bulk hors de votre IP transactionnelle. Si c’est une petite file avec un comportement de retry normal, ne paniquez pas.

Task 10 — Confirmer que vous signez DKIM sur les messages que vous croyez signer

cr0x@server:~$ sudo postcat -q 8F2C02A1B3 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:            38912            392
sender: bounce@example.com
*** MESSAGE CONTENTS ***
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;
 t=1704277032; bh=7yQf...; h=from:to:subject:date:mime-version;
 b=Z1m...
From: Example Billing 
To: user@gmail.com
Subject: Your receipt

Ce que ça signifie : Le message est signé DKIM avec d=example.com, sélecteur s1.

Décision : Si la signature DKIM manque pour certains parcours applicatifs (réinitialisations de mot de passe vs factures), vous avez probablement plusieurs chemins sortants. Consolidez ou assurez‑vous que tous les chemins signent de façon cohérente.

Task 11 — Vérifier la poignée de main TLS et la présentation du certificat au MTA destinataire

cr0x@server:~$ openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com -tls1_2 </dev/null | sed -n '1,25p'
CONNECTED(00000003)
depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R1
verify return:1
depth=1 C=US, O=Google Trust Services LLC, CN=GTS CA 1C3
verify return:1
depth=0 CN=gmail-smtp-in.l.google.com
verify return:1
---
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

Ce que ça signifie : Le destinataire supporte TLS moderne ; votre côté devrait en faire autant.

Décision : Si votre MTA sortant négocie un TLS ancien ou échoue STARTTLS, vous verrez plus de déferrals et d’échecs politiques. Mettez à jour les bibliothèques et Postfix, et assurez‑vous que votre politique de chiffrement n’est pas bloquée en 2014.

Task 12 — Vérifier si votre domaine publie MTA-STS et si la ressource se parse

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20250101T120000Z"

Ce que ça signifie : Vous publiez un id de politique MTA-STS.

Décision : Si vous annoncez MTA-STS mais que votre hôte de politique est cassé, vous pouvez provoquer des problèmes de livraison vers vous (pas forcément en sortie). C’est quand même utile à vérifier parce que les tickets « l’e‑mail est cassé » ne précisent que rarement la direction.

Task 13 — Vérifier la santé de la résolution DNS locale (car des résolveurs cassés causent des SPF/DKIM instables)

cr0x@server:~$ resolvectl status | sed -n '1,35p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 1.1.1.1

Ce que ça signifie : Votre MTA dépend de ces résolveurs pour les vérifs SPF/DKIM/DMARC.

Décision : Si vous avez des échecs intermittents de délivrabilité, vérifiez les timeouts des résolveurs et le détournement NXDOMAIN. Utilisez des résolveurs fiables et envisagez un cache local (unbound) avec des timeouts raisonnables.

Task 14 — Confirmer que votre nom HELO (Postfix) est celui prévu

cr0x@server:~$ postconf smtp_helo_name myhostname | sed 's/^/postfix: /'
postfix: smtp_helo_name = mail1.example.com
postfix: myhostname = mail1.example.com

Ce que ça signifie : Votre outbound se présente comme mail1.example.com.

Décision : Si vous voyez un HELO générique comme localhost ou un nom interne, corrigez‑le. Ce n’est pas toujours fatal, mais ça hurle « non géré » aux systèmes de réputation.

Task 15 — Détecter rapidement des taux élevés de rebonds/destinataires inconnus (échantillonnage de logs)

cr0x@server:~$ sudo grep -E "status=bounced|5\.1\.1|User unknown" /var/log/mail.log | tail -n 15
Jan  3 10:10:02 mail1 postfix/smtp[23910]: 9A1F12A0D2: to=, relay=outlook-com.olc.protection.outlook.com[104.47.15.36]:25, delay=3.2, dsn=5.1.1, status=bounced (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 550 5.1.1 RESOLVER.ADR.RecipNotFound; Recipient not found (in reply to RCPT TO command))

Ce que ça signifie : Vous envoyez à des destinataires inexistants.

Décision : Arrêtez l’hémorragie. Suspendez les envois en masse, nettoyez les listes, et imposez la vérification d’adresse au moment de la capture. Des taux élevés de 5.1.1 détruisent rapidement la réputation, surtout chez Microsoft.

Task 16 — Confirmer l’inclusion des en‑têtes List-Unsubscribe pour le mail en masse

cr0x@server:~$ sudo postcat -q 7C0A12A19F | grep -i -E '^List-Unsubscribe:|^List-Unsubscribe-Post:'
List-Unsubscribe: , 
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Ce que ça signifie : Les messages en masse offrent des options propres de désinscription.

Décision : Si vous envoyez du marketing ou des mises à jour produit sans ces en‑têtes, ajoutez‑les. Cela réduit les plaintes spam, et c’est un levier de délivrabilité que vous pouvez réellement contrôler.

Blague #2 : Si votre enregistrement SPF contient 14 includes, ce n’est pas de la « sécurité », c’est une danse DNS interprétative.

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne avait une configuration « simple » : les serveurs applicatifs envoyaient les réinitialisations de mot de passe via un fournisseur cloud, et les factures passaient par une machine Postfix on‑prem qui tournait depuis la fin d’un stage.

Un nouveau domaine de marque a été lancé. Le marketing a mis à jour le From: visible en billing@newbrand.example partout. Ils n’ont pas touché l’expéditeur d’enveloppe, qui est resté bounce@oldbrand.example. SPF passait. DKIM passait (pour l’ancien domaine). DMARC échouait. Silencieusement, systématiquement et de façon catastrophique.

La mauvaise hypothèse était subtile : « Si SPF et DKIM passent, DMARC passera. » Ce n’est pas comme ça que ça marche. DMARC exige l’alignement avec le domaine From visible par l’utilisateur. L’identité visible a changé ; l’identité authentifiée non.

Les symptômes étaient laids mais déroutants : Gmail livrait en spam, Outlook différé certains envois et classait le reste en indésirable, et les parties prenantes internes insistaient que c’était « le contenu » parce que le template avait changé cette semaine.

La correction fut ennuyeuse mais immédiate : signer DKIM avec d=newbrand.example et aligner l’expéditeur d’enveloppe, ou utiliser l’alignement relax avec une stratégie de sous‑domaine contrôlée. Une fois DMARC passé de façon fiable, le placement s’est rétabli en quelques jours, pas en quelques minutes. Les systèmes de réputation ont de la mémoire ; ce n’est pas du poisson rouge.

Mini‑histoire 2 : L’optimisation qui a échoué

Une autre entreprise a essayé d’« optimiser les coûts » en consolidant tout l’e‑mail sortant — transactionnel, marketing, notifications partenaires — sur une seule IP dédiée. Une IP pour tout gouverner. Un seul tableau de bord. Un seul ensemble de règles de pare‑feu. Quelqu’un a même appelé ça « simplification ».

Ça a fonctionné jusqu’à la newsletter trimestrielle. L’engagement était médiocre, les désinscriptions ont grimpé, et une petite fraction des destinataires a cliqué sur « Signaler comme spam » parce que l’e‑mail leur semblait inconnu. Le lendemain, les réinitialisations de mot de passe ont commencé à arriver en spam pour les utilisateurs Gmail et à être différées chez Microsoft.

Ils avaient créé un couplage de réputation : le flux le moins vertueux a empoisonné le flux le plus critique. L’incident a coûté cher, mais la leçon fut inestimable : séparez les trafics selon le risque.

Le plan de rétablissement n’était pas magique. Ils ont séparé l’envoi : un chemin IP/domaine pour le transactionnel, un autre pour le marketing, avec des limites de débit différentes et des contrôles d’hygiène plus stricts sur le marketing. Ils ont aussi mis en place des listes de suppression et arrêté d’e‑mailer des adresses inactives depuis des mois. La délivrabilité est revenue progressivement, et la rotation d’astreinte a cessé de considérer les jours de campagne comme une saison d’ouragans.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande plateforme B2B avait une habitude qui paraissait bureaucratique : chaque changement DNS pour l’authent auth e‑mail nécessitait une revue par les pairs et une « vérification canari » depuis un domaine de staging. Personne n’aimait ça. Tout le monde respectait la règle.

Un vendredi, un ingénieur bien intentionné a tenté de faire une rotation des clés DKIM et de nettoyer des « anciens sélecteurs ». La revue a détecté qu’une appli legacy signait encore avec le sélecteur s0 parce qu’il était figé dans un fichier de configuration présent dans une image de conteneur que personne ne voulait reconstruire.

La rotation des clés a été déployée avec les deux sélecteurs actifs. Ils ont planifié la suppression de s0 seulement après avoir confirmé — via les logs — qu’aucun message ne l’utilisait plus. Le changement s’est déroulé sans histoire, ce qui est la seule issue acceptable pour des modifications d’authentification.

Deux semaines plus tard, une rotation similaire chez un partenaire a provoqué des pannes généralisées parce qu’ils ont supprimé le sélecteur actif en premier et posé des questions ensuite. Le mail de la plateforme a continué de circuler, et personne n’a été alerté. Le salut n’était pas un génie ; c’était un processus de changement pensé pour la réalité : les systèmes de messagerie sont étendus et inconsistants.

Listes de contrôle / plan étape par étape

Checklist A — Si des utilisateurs Gmail signalent « ne reçoivent pas »

Obtenez un exemple réel : message ID, horodatage, domaine destinataire, et si la recherche a été faite dans « Tous les messages » et Spam.
Déterminez : bounce, deferral ou livré à partir de vos logs.
Récupérez les en‑têtes bruts d’un échantillon livré et confirmez DMARC pass et l’alignement.
Vérifiez le DNS du sélecteur DKIM existe et est stable (pas de NXDOMAIN intermittent).
Confirmez la stabilité de l’IP d’envoi : pas de changements NAT surprises, pas de nouveaux relais.
Validez l’hygiène de liste si c’est du bulk : destinataires inconnus et plaintes vous enterrent.
Segmentez les flux : gardez le transactionnel isolé du marketing si vous aimez dormir.

Checklist B — Si Outlook/Microsoft diffère ou rejette

Lisez le code de statut SMTP étendu : 4.7.x (throttle), 5.7.x (politique/auth), 5.1.1 (mauvais destinataires).
Vérifiez rDNS et HELO : Microsoft n’est pas sentimental sur les expéditeurs mal configurés.
Throttlez et lissez : les envois en rafales déclenchent des deferrals ; réduisez la concurrence et montez en charge progressivement.
Vérifiez les comptes compromis : les déferrals Microsoft coïncident souvent avec des pics soudains d’un même identity expéditeur.
Séparez bulk et transactionnel par IP/domaine si ce n’est pas déjà fait.
Confirmez l’alignement DKIM/DMARC et que les en‑têtes ne sont pas réécrits par des relais intermédiaires.

Checklist C — Base d’authentification pour 2025 (faire une fois, puis monitorer)

SPF : includes minimaux ; -all quand vous êtes confiants ; restez sous 10 requêtes DNS.
DKIM : clés 2048 bits quand possible ; faire des rotations ; documenter les sélecteurs.
DMARC : commencez en p=none pour observer, puis quarantine, puis reject quand les flux alignés sont propres.
Stratégie d’alignement : décidez si le From utilise le domaine racine ou un sous‑domaine dédié ; restez cohérent.
ARC : si vous exploitez des services de forwarding (helpdesk, ticketing), implémentez ARC pour préserver la confiance d’authentification.
List-Unsubscribe : incluez‑le pour le bulk ; supportez le one‑click si possible.

Erreurs courantes : symptôme → cause → correction

Ce sont les échecs que je vois répétitivement en production. Ils ne sont pas glamour, mais ce sont les raisons pour lesquelles votre mail est « OK en staging » et maudit en production.

1) Symptom : Gmail accepte (250 OK) mais les utilisateurs trouvent le mail en Spam

Cause racine : DMARC échoue ou passe de façon inconsistante ; réputation dégradée ; en‑têtes bulk manquants.
Correction : Faites passer DMARC avec SPF ou DKIM aligné. Ajoutez List-Unsubscribe pour le bulk. Séparez marketing et transactionnel. Cessez d’envoyer à des listes froides.

2) Symptom : Outlook renvoie 451 4.7.0 erreur temporaire pour de nombreux destinataires

Cause racine : Throttling dû à la réputation, au rythme en rafales, ou à une mauvaise hygiène IP (mismatch rDNS/HELO).
Correction : Lissez les envois (baisser la concurrence, cadence cohérente). Corrigez rDNS et HELO. Séparez les flux. Nettoyez les listes à forte proportion de rebonds.

3) Symptom : « SPF passe » mais DMARC échoue

Cause racine : Le domaine SPF est le domaine de l’expéditeur d’enveloppe, pas aligné avec le From.
Correction : Utilisez un domaine return‑path aligné (ou un sous‑domaine) et assurez‑vous que SPF autorise la vraie source d’envoi ; ou comptez sur DKIM aligné pour valider DMARC.

4) Symptom : DKIM échoue parfois uniquement pour certains types de messages

Cause racine : Plusieurs chemins sortants ; un chemin ne signe pas, ou un relais modifie le corps/en‑têtes après signature.
Correction : Centralisez la signature au dernier hop de confiance. Assurez‑vous que la canonicalization est appropriée. Évitez les intermédiaires qui réécrivent le contenu après signature.

5) Symptom : Effondrement soudain après un « nettoyage » DNS

Cause racine : Suppression d’un sélecteur DKIM actif ; casse de la chaîne include SPF ; changement trop agressif de politique DMARC.
Correction : Restaurez les sélecteurs. Déployez DMARC progressivement (pct, monitor). Traitez le DNS d’authentification e‑mail comme de la conf de production, pas comme un hobby.

6) Symptom : Taux élevé de rebonds (5.1.1) puis dégradation généralisée

Cause racine : Échec d’hygiène de listes ; listes anciennes ; fautes de frappe ; abus lors des inscriptions.
Correction : Implémentez suppression, validation et double opt‑in quand approprié. Arrêtez d’envoyer aux adresses qui hard bounce — immédiatement et automatiquement.

7) Symptom : Les messages disparaissent lors du forwarding (surtout vers Gmail)

Cause racine : Le forwarding casse SPF ; DKIM est cassé par des modifications ; la politique DMARC provoque rejet/quarantaine.
Correction : Encouragez l’utilisation de forwarding moderne qui supporte ARC. Pour vos propres services de forwarding, implémentez ARC et évitez la réécriture de contenu.

8) Symptom : Tests internes réussissent, destinataires externes échouent

Cause racine : Vous testez contre des MTA internes permissifs. Les fournisseurs externes appliquent des politiques et un scoring de réputation plus stricts.
Correction : Testez avec de vraies boîtes externes, inspectez les en‑têtes, et mettez en scène les changements d’authentification avec des domaines canaris.

FAQ

1) « Nous ne sommes pas expéditeur en masse. Les règles bulk de Gmail comptent‑elles ? »

Elles comptent indirectement. Les fournisseurs appliquent de plus en plus des attentes « bulk‑like » (authentification, patterns de désinscription, contrôle des plaintes) à quiconque se comporte comme du bulk — même par accident. Un expéditeur transactionnel avec un compte compromis peut ressembler à du bulk en quelques minutes.

2) Si SPF passe, pourquoi Outlook nous throttle‑t‑il encore ?

Parce que SPF prouve l’identité, pas la réputation. Le throttling concerne souvent les schémas de rythme, les destinataires inconnus, les signaux de plainte, et l’hygiène d’infrastructure (rDNS/HELO). Un SPF pass ne vous ouvre pas la voie rapide.

3) Devons‑nous mettre DMARC en p=reject immédiatement ?

Seulement si vous êtes sûr que tous les flux légitimes s’alignent (SPF ou DKIM) et que vous avez observé les rapports assez longtemps pour détecter des envoyeurs legacy étranges. Sinon vous rejetterez vos propres mails sous couvert de « sécurité ».

4) DKIM ou SPF : lequel est le plus important en 2025 ?

DKIM a tendance à être plus robuste pour l’alignement DMARC parce que SPF casse lors du forwarding et certains relais. La meilleure pratique reste : publier les deux, s’assurer qu’au moins un s’aligne, et surveiller DMARC.

5) Un changement de contenu seul peut‑il provoquer un placement en spam ?

Oui, mais le contenu est généralement le multiplicateur, pas la cause racine. Si votre authentification et votre réputation sont saines, des ajustements de contenu entraînent rarement une chute totale. Si vous êtes déjà sur la corde raide, un changement « innocent » (nouveau domaine de lien, raccourcisseur d’URL, modifications de tracking) peut vous faire basculer.

6) Pourquoi certains destinataires reçoivent le mail et d’autres pas ?

Les fournisseurs effectuent des scores par destinataire et par domaine. Un expéditeur peut être temporairement throttlé pour certaines régions, clusters de boîtes ou cohortes de destinataires. De plus, votre propre système peut router différemment selon le domaine destinataire (relais différents, IP différentes).

7) Quel est l’artefact le plus utile à demander à un utilisateur ?

Les en‑têtes complets d’un message arrivé en spam, ou le texte exact du bounce/NDR. Les captures d’écran sont décoratives ; les en‑têtes sont des preuves.

8) Changer notre IP d’envoi aide‑t‑il ?

Parfois, mais c’est aussi un excellent moyen de remettre votre réputation à « inconnue », ce qui peut être pire. Changez d’IP quand l’actuelle est irrémédiablement empoisonnée ou partagée avec de mauvais acteurs, et planifiez un warm‑up.

9) Nous utilisons une plateforme e‑mail tierce. Que pouvons‑nous réellement contrôler ?

Plus que vous ne le pensez : stratégie de domaine From, alignement DKIM, politique DMARC, hygiène de listes, segmentation (transactionnel vs marketing), contenu/domaines de liens, et cadence d’envoi. Vous pouvez aussi choisir IP partagée vs dédiée et contrôler l’onboarding/warm‑up.

10) Pourquoi les tableaux de bord « livrés » divergent de la réalité ?

Beaucoup de dashboards signifient « accepté par le MTA destinataire », pas « en boîte de réception ». Le placement en inbox est un résultat distinct. Utilisez les en‑têtes, les boucles de rétroaction des destinataires (là où disponibles) et vos propres métriques d’engagement pour valider.

Conclusion : prochaines étapes robustes en production

Les incidents de délivrabilité sont ressentis comme personnels parce qu’ils bloquent de l’argent et de la confiance. Mais les correctifs sont mécaniques : prouvez l’identité (SPF/DKIM/DMARC alignés), protégez la réputation (hygiène et segmentation), et rendez le transport ennuyeux (rDNS, HELO, TLS, comportement de retry raisonnable).

Prochaines étapes qui font réellement avancer :

Choisissez un exemple qui échoue (destinataire + horodatage) et tracez‑le de bout en bout via logs et en‑têtes.
Faites passer DMARC de façon consistante avec alignement. N’y négociez pas.
Séparez les flux transactionnel et bulk par IP et/ou domaine, et appliquez une hygiène plus stricte sur le bulk.
Stabilisez l’identité de l’infrastructure : rDNS, DNS direct, nom HELO, et IP d’egress cohérente.
Ajoutez des garde‑fous opérationnels : revue des changements DNS, inventaire des sélecteurs DKIM, monitoring de file, alertes sur taux de rebond.

Les fournisseurs de boîtes ne sont pas vos amis, mais ils sont prévisibles si vous traitez l’e‑mail comme du trafic de production. Mesurez. Vérifiez. Changez une chose à la fois. Et gardez les logs près de vous.