Ce qui se passe probablement
L’authentification du domaine est incomplète
Le domaine peut ne pas disposer d’un SPF, d’une signature DKIM ou d’un enregistrement DMARC exploitable. Il arrive aussi qu’une partie des messages soit authentifiée alors qu’un autre flux d’envoi ne l’est pas.
Le domaine visible n’est pas aligné
SPF peut être validé avec le domaine du Return-Path et DKIM avec celui du prestataire, sans qu’aucun des deux ne soit aligné avec le domaine affiché dans le champ From. Dans ce cas, DMARC peut échouer malgré des tests SPF ou DKIM positifs.
La désinscription est absente ou mal configurée
Un lien visible dans le message est nécessaire pour les communications promotionnelles. Pour les expéditeurs à fort volume, les en-têtes List-Unsubscribe et List-Unsubscribe-Post doivent aussi permettre une désinscription en un clic lorsqu’elle est requise.
La réputation ou la qualité de la base est dégradée
Des plaintes fréquentes, des rebonds, des contacts sans engagement, des listes achetées, des adresses pièges ou une augmentation soudaine du volume peuvent provoquer des rejets ou un classement en spam même si le DNS est correct.
Une plateforme envoie sans être correctement autorisée
Un CRM, un prestataire d’envoi, une automatisation ou un alias peut utiliser votre domaine sans figurer dans SPF ou sans produire une signature DKIM alignée. Le problème apparaît souvent après l’ajout ou le remplacement d’un outil.
L’infrastructure ou les en-têtes ne respectent pas les exigences
Un DNS inverse absent, une connexion TLS incorrecte, des en-têtes non conformes, un Message-ID problématique ou plusieurs champs From peuvent entraîner un filtrage ou un rejet.
Comment vérifier sans casser la configuration
Séparez trois résultats dans vos mesures : rejet SMTP, message accepté mais placé en spam, et message livré en boîte de réception. Ces situations n’ont pas les mêmes causes.
Copiez le message de rebond complet et son code SMTP exact, par exemple 421, 450, 550, 554 ou un code détaillé de type 5.7.x.
Ouvrez les en-têtes d’un message réellement reçu et comparez le champ From, le Return-Path, le domaine DKIM indiqué par d=, le résultat SPF et le résultat DMARC.
Recensez toutes les sources d’envoi : plateforme d’e-mail marketing, CRM, automatisations, site web, support, facturation et alias éventuels.
Contrôlez SPF pour vérifier que tous les prestataires autorisés sont inclus et que l’enregistrement ne dépasse pas les limites de recherches DNS prévues par SPF.
Vérifiez que le sélecteur DKIM publié est actif, que la signature passe et que son domaine est aligné avec le domaine visible de l’expéditeur.
Confirmez la présence de DMARC, au minimum avec une politique p=none pour commencer, puis utilisez une adresse rua valide si vous souhaitez analyser les rapports.
Pour les messages promotionnels concernés, contrôlez le lien visible de désinscription ainsi que les en-têtes List-Unsubscribe et List-Unsubscribe-Post.
Vérifiez le DNS inverse de l’adresse IP d’envoi, l’utilisation de TLS et la conformité générale des en-têtes au format attendu.
Analysez la réputation par domaine destinataire : plaintes, rebonds, désinscriptions, engagement et données disponibles dans Google Postmaster Tools ou les boucles de rétroaction accessibles.
Recherchez un changement récent de domaine, d’adresse IP, de prestataire, de signature DKIM, de modèle ou de volume. Une montée en charge progressive doit privilégier les destinataires actifs.
Ne vous limitez pas aux outils de test en ligne. Envoyez un message réel vers Gmail et Yahoo, puis vérifiez les en-têtes et sa destination finale : réception, spam ou rejet.
Comment je le résoudrais étape par étape
Cartographier et clarifier l’identité d’envoi
Déterminez quel domaine, sous-domaine, champ From et prestataire sont utilisés par chaque type de message. Lorsque le volume ou le risque le justifie, évitez de faire partager la même identité aux promotions, aux messages transactionnels, au support et à la prospection à froid.
Corriger SPF, DKIM, DMARC et leur alignement
Autorisez chaque source réelle dans SPF, activez DKIM depuis la plateforme d’envoi et publiez DMARC pour le domaine visible. Validez ensuite l’alignement réel : la seule présence des enregistrements DNS ne prouve pas que les messages passent DMARC.
Rendre la désinscription simple et fonctionnelle
Ajoutez un lien de désinscription visible dans le contenu et les en-têtes nécessaires à la désinscription en un clic lorsqu’ils s’appliquent. Le parcours ne doit pas imposer de connexion ni d’étapes inutiles.
Assainir la base avant d’augmenter le volume
Retirez les rebonds définitifs, les adresses achetées et les contacts anciens sans interaction. Reprenez avec les segments les plus actifs, puis ajustez progressivement le volume selon les rejets, les plaintes et les désinscriptions observés.
Suivre la réputation avec les résultats commerciaux
Regroupez les données de livraison, spam, rebonds, plaintes, désinscriptions et résultats par domaine destinataire. Le taux d’ouverture ne permet pas, à lui seul, d’établir si les messages atteignent correctement la boîte de réception.
Si cela devient technique
Tu peux suivre cette route seul. Si le diagnostic révèle un écart de données, une configuration tracking délicate, une décision d'enchères risquée ou un blocage qui demande un accès compte, Lia garde le contexte et le transmet à CreatikLab.
Transmettre ce contexte à LiaCe que je ne ferais pas
Modifier l’objet ou le design avant d’avoir lu le code SMTP et les en-têtes.
Changer de plateforme d’envoi sans mettre à jour SPF, DKIM et DMARC.
Considérer qu’un résultat SPF positif garantit la validation DMARC.
Signer les messages uniquement avec le domaine du prestataire sans vérifier l’alignement avec le champ From.
Envoyer depuis un alias ou une automatisation qui n’est pas correctement autorisé pour le domaine.
Utiliser une base achetée ou très ancienne, puis attribuer les rejets au contenu du message.
Masquer le lien de désinscription dans l’espoir de réduire les départs, au risque d’augmenter les plaintes.
Augmenter brutalement le volume après un changement de domaine, d’adresse IP, de prestataire ou de modèle.
Questions fréquentes
SPF, DKIM et DMARC sont-ils obligatoires pour Gmail et Yahoo ?
Pour les expéditeurs à fort volume, ils doivent être considérés comme indispensables. Gmail demande notamment SPF, DKIM et DMARC aux expéditeurs qui dépassent 5 000 messages par jour vers des comptes Gmail personnels, avec une politique DMARC au minimum p=none. Yahoo impose également une authentification renforcée et DMARC aux expéditeurs à fort volume.
Que signifie l’alignement DMARC ?
Le domaine visible dans le champ From doit correspondre, selon les règles d’alignement DMARC, au domaine validé par SPF ou à celui utilisé dans la signature DKIM. Un message peut donc passer SPF ou DKIM tout en échouant à DMARC si les domaines ne sont pas alignés.
La désinscription en un clic concerne-t-elle tous les messages ?
Non. Elle vise les messages promotionnels ou issus d’un abonnement, notamment pour les expéditeurs à fort volume. Les messages strictement transactionnels, comme une réinitialisation de mot de passe ou une confirmation de commande, ne sont pas traités de la même manière.
Pourquoi Yahoo rejette-t-il un message accepté par Gmail ?
Chaque fournisseur applique ses propres filtres et peut évaluer différemment la réputation, l’alignement ou la route d’envoi. Une faiblesse technique ou réputationnelle peut donc produire un rejet chez Yahoo et un classement en spam ou une livraison chez Gmail.
Combien de temps faut-il pour rétablir la délivrabilité ?
Il n’existe pas de délai garanti. Une erreur DNS peut être corrigée rapidement après sa propagation, mais une réputation dégradée demande une période de trafic propre, un volume maîtrisé et une baisse durable des plaintes et des rebonds.
