# Pourquoi votre hébergeur mutualisé envoie vos emails WordPress dans les spams

> Les commandes WooCommerce n'arrivent jamais par email. Le code est propre, wp_mail() fonctionne : le vrai coupable est la réputation de l'IP partagée.

- Auteur : Clément Hadrot
- Publié le : 2020-04-24
- Mis à jour le : 2020-04-24
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/hebergeur-mutualise-emails-wordpress-spams/

## L’essentiel

- Une IP mutualisée porte la réputation de tous ses locataires
- Un test technique isolé ne révèle rien
- La liaison à un service d'envoi tiers règle 90 % des cas

« Mes clients ne reçoivent jamais leur confirmation de commande. » La boutique WooCommerce fonctionnait sans erreur visible : les commandes s'enregistraient, le paiement passait, mais l'email de confirmation n'arrivait jamais dans la boîte du client. Ni en spam, ni ailleurs. Le réflexe naturel est de suspecter le code, un hook mal branché sur `woocommerce_order_status_completed`, une extension SMTP mal configurée. Ici, rien de tout cela n'était en cause.

Ce cas illustre un phénomène propre à l'hébergement mutualisé, distinct de tout bug de code : la réputation d'IP partagée. Un serveur mutualisé héberge des dizaines, parfois des centaines de domaines sur la même adresse IP sortante. Si un seul de ces domaines se met à envoyer des emails perçus comme indésirables, c'est toute l'IP qui en paie le prix, y compris les sites parfaitement légitimes qui la partagent sans le savoir.

## Comprendre ce que voit réellement le fournisseur de messagerie

Quand un serveur de messagerie comme celui de Gmail ou d'Outlook reçoit un email, il n'évalue pas seulement son contenu. Il consulte l'historique de l'adresse IP émettrice : volume d'envoi récent, taux de plaintes pour spam, présence sur des listes de blocage comme celles de Spamhaus, cohérence du DNS inverse. Sur une IP mutualisée, cet historique est un agrégat de comportements que le propriétaire du site n'a jamais choisis ni contrôlés.

Un site e-commerce parfaitement sain peut donc se retrouver pénalisé simplement parce qu'un autre client de l'hébergeur, sur la même IP, a laissé un formulaire de contact ouvert aux robots ou installé une extension compromise qui envoie des emails frauduleux en masse. Le fournisseur de messagerie ne fait pas de distinction fine : il voit une IP, un volume anormal, et applique un filtrage global.

## Pourquoi les tests techniques classiques ne détectent rien

> L'essentiel à retenir : Une IP mutualisée porte la réputation de tous ses locataires ; Un test technique isolé ne révèle rien ; La liaison à un service d'envoi tiers règle 90 % des cas

C'est ce qui rend ce problème difficile à diagnostiquer pour un développeur habitué à déboguer du code. Un test avec `wp_mail()` en ligne de commande fonctionne, l'email part bien du serveur, les en-têtes SPF et DKIM peuvent même être correctement configurés. Le message est envoyé, il transite normalement... et se fait discrètement filtrer côté destinataire, sans jamais générer d'erreur exploitable côté expéditeur.

```
wp eval 'wp_mail("client@exemple.fr", "Test", "Contenu de test");'
```

Cette commande retournera presque toujours `true`, qu'elle soit exécutée depuis un serveur à la réputation intacte ou depuis une IP blocklistée. Le point de contrôle des grands fournisseurs de messagerie se situe après l'envoi, invisible depuis le serveur expéditeur. C'est la raison pour laquelle tant de développeurs tournent en rond sur ce type de ticket : ils cherchent une erreur qui n'existe pas dans leur code.

## Vérifier la réputation avant de blâmer le code

Avant de retoucher la moindre ligne de PHP, quelques vérifications externes permettent de confirmer ou d'écarter la piste de la réputation :

- Consulter l'adresse IP sortante du serveur sur un outil de vérification de blocklists (MXToolbox, Spamhaus) pour voir si elle figure sur une liste noire connue.
- Vérifier le DNS inverse (PTR) de l'IP : un mutualisé mal configuré pointe parfois vers un nom générique du type `server123.hebergeur.net`, ce qui alerte les filtres anti-spam plus qu'un nom cohérent avec le domaine.
- Demander à l'hébergeur son historique de plaintes ("feedback loop") sur cette IP précise : certains le communiquent sur demande, d'autres refusent, ce qui est déjà une indication.

## La solution qui fonctionne réellement

Une fois la cause confirmée, corriger le code ne sert à rien : il faut sortir l'envoi transactionnel du circuit mutualisé. La solution la plus fiable consiste à relayer les emails WordPress via un service d'envoi tiers spécialisé (SendGrid, Mailgun, Brevo, entre autres), qui dispose de sa propre réputation d'IP, gérée et surveillée en continu, indépendamment de l'hébergement du site.

Concrètement, cela passe par une extension comme WP Mail SMTP configurée avec les identifiants API du service choisi, en remplacement du transport `mail()` par défaut de PHP. L'email ne transite plus jamais par l'IP mutualisée : il part directement du service d'envoi, avec sa propre infrastructure et sa propre surveillance anti-abus.

> Un client qui refuse ce changement en pensant économiser un abonnement finit toujours par revenir six mois plus tard avec le même symptôme, aggravé. La réputation d'IP mutualisée ne s'améliore jamais d'elle-même : elle se dégrade au rythme des autres locataires du serveur.

## Pour aller plus loin

Ce sujet ne doit pas être confondu avec les erreurs de configuration autour de `wp_mail()`, comme l'absence d'enregistrements SPF ou DKIM correctement déclarés pour le domaine d'envoi : ce sont deux problèmes distincts, qui peuvent d'ailleurs coexister. Un domaine bien configuré sur le plan SPF/DKIM mais hébergé sur une IP mutualisée mal réputée continuera de souffrir en délivrabilité. La bonne pratique reste de traiter les deux niveaux séparément : la configuration DNS du domaine d'un côté, l'infrastructure d'envoi de l'autre.