# Mes e-mails n’arrivent pas ou partent en indésirables

> Un e-mail envoyé par un site traverse cinq étapes : le site le fabrique, un serveur l’expédie, le domaine prouve qu’il en est bien l’auteur, le fournisseur du destinataire lui attribue une note, et la boîte de réception décide du dossier. Le site n’est responsable que de la première. C’est pourtant lui qu’on accuse en premier.

- Source canonique : [https://allaux.fr/problemes/emails-non-recus-ou-en-spam](https://allaux.fr/problemes/emails-non-recus-ou-en-spam)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Testez l’expédition avant tout le reste : Paramètres avancés > E-mail sur PrestaShop envoie un message de test et affiche l’erreur SMTP brute. Sur WordPress, un journal d’envoi indique si le message est réellement parti. Si les messages partent mais tombent en indésirables, la panne est dans le DNS du domaine : contrôlez l’enregistrement SPF, la clé DKIM et la politique DMARC chez votre bureau d’enregistrement.

## Trois symptômes, trois étapes différentes

- Aucun message ne part, pas même vers votre propre adresse : la panne est dans la fabrication ou l’expédition, côté site et serveur.
- Les messages arrivent chez certains destinataires et pas chez d’autres, souvent selon le fournisseur de messagerie : la panne est dans l’authentification du domaine.
- Les messages arrivent mais dans les indésirables : rien n’est cassé, c’est la réputation d’envoi qui est en cause.

## Le point de rupture le plus fréquent : l’authentification

Un fournisseur de messagerie reçoit un message qui dit venir de votre domaine. Pour vérifier que c’est vrai, il consulte trois enregistrements publiés dans la zone DNS du domaine. SPF énumère les serveurs autorisés à envoyer en votre nom. DKIM permet de vérifier une signature cryptographique apposée au message. DMARC indique quoi faire quand les deux premiers échouent.

Quand le site envoie directement depuis le serveur d’hébergement alors que le SPF n’autorise que le serveur de messagerie de l’entreprise, la vérification échoue. Le message n’est pas rejeté — ce serait plus simple à diagnostiquer — il est simplement dégradé, et finit dans les indésirables chez les fournisseurs les plus stricts. C’est exactement le motif du symptôme « ça marche pour certains clients seulement ».

## Isoler l’étape qui échoue

1. **Envoyer un message de test vers deux adresses de fournisseurs différents** — Une adresse chez un grand fournisseur grand public et une adresse professionnelle. La différence de traitement est déjà un diagnostic.
2. **Regarder l’en-tête complet du message reçu** — Il contient le résultat des vérifications SPF et DKIM, écrit en clair. C’est la preuve, pas une supposition.
3. **Vérifier l’adresse d’expéditeur configurée** — Un site qui expédie au nom d’un domaine qu’il ne contrôle pas — l’adresse personnelle du gérant, par exemple — est presque systématiquement dégradé.
4. **Consulter les journaux d’envoi du serveur** — Ils disent si le message est parti, et avec quelle réponse du serveur destinataire. Un rejet y est explicite et souvent explicatif.
5. **Vérifier que le site n’envoie pas aussi autre chose** — Un site compromis qui expédie du courrier indésirable détruit la réputation du domaine, et vos confirmations de commande en subissent les conséquences.

## Passer par un service d’envoi dédié règle la majorité des cas

> Faire partir les messages transactionnels par un service d’envoi spécialisé plutôt que par la fonction d’envoi du serveur d’hébergement apporte l’authentification correcte, des journaux consultables et une réputation gérée. C’est un changement de configuration, pas un développement.

## Continuer sur la bonne page

- **E-mails de commande non reçus sur PrestaShop** — Si la panne est dans PrestaShop : modèles, hooks et paramètres d’envoi. ([/prestashop/problemes/emails-confirmation-commande-non-recus](/prestashop/problemes/emails-confirmation-commande-non-recus))
- **E-mails de commande non reçus sur WooCommerce** — L’équivalent côté WordPress, avec ses causes propres. ([/wordpress-woocommerce/problemes/emails-commande-non-recus](/wordpress-woocommerce/problemes/emails-commande-non-recus))
- **Mon site envoie des e-mails que je n’ai pas écrits** — Si le domaine a perdu sa réputation à cause d’envois parasites. ([/securite/mon-site-envoie-des-emails-que-je-n-ai-pas-ecrits](/securite/mon-site-envoie-des-emails-que-je-n-ai-pas-ecrits))
- **Le DNS expliqué** — Où se publient SPF, DKIM et DMARC, et pourquoi ils dépendent du domaine. ([/glossaire/dns](/glossaire/dns))

## FAQ

### Pourquoi mes clients chez certains fournisseurs reçoivent tout et d’autres rien ?

Parce que les fournisseurs n’appliquent pas la même sévérité aux mêmes signaux. Un message mal authentifié passe chez les uns et est écarté chez les autres. C’est le signe le plus fiable d’un problème SPF ou DKIM.

### Le problème peut-il venir de mon hébergeur ?

Oui, de deux façons : sa fonction d’envoi peut être limitée ou désactivée, et son adresse d’expédition peut être partagée avec des sites qui ont abîmé sa réputation.

### Faut-il un développement pour corriger cela ?

Rarement. La correction est presque toujours de la configuration : enregistrements DNS, paramètres d’envoi, adresse d’expéditeur. Le développement n’intervient que si les messages ne sont pas déclenchés du tout par le site.

### Comment savoir si mes messages sont classés en indésirables sans demander à mes clients ?

En envoyant des tests vers des boîtes que vous contrôlez chez plusieurs fournisseurs, et en lisant les rapports DMARC si l’enregistrement est publié avec une adresse de rapport.

### Mes messages partaient bien avant, qu’est-ce qui a changé ?

Le plus souvent la zone DNS a été modifiée lors d’un changement d’hébergeur ou de messagerie, ou les fournisseurs ont durci leurs exigences. Un envoi qui passait il y a deux ans peut être écarté aujourd’hui sans qu’aucun réglage n’ait bougé chez vous.