Le formulaire de contact n’envoie plus de courriels : que vérifier ?
Trouvez où s’arrête la demande avant de modifier la messagerie. Le formulaire a-t-il accepté l’envoi ? Le site a-t-il transmis le message à un service d’envoi ? Ce service l’a-t-il livré, rejeté ou classé comme indésirable ? Un écran de remerciement ne répond pas à lui seul à ces trois questions.
Vérifiez la bonne boîte, y compris les indésirables
Convenez d’un test contrôlé avec des données fictives, notez son heure et vérifiez l’adresse de destination réelle. Cherchez dans les indésirables autant que dans la boîte de réception. Examinez aussi les règles de transfert et l’accès aux boîtes partagées : le message peut se trouver ailleurs que dans le dossier surveillé par votre collègue.
Le guide WordPress de Jetpack commence par les indésirables et cite les réglages de l’expéditeur, les restrictions de l’hébergement et les conflits d’extensions comme causes possibles. Ce sont des pistes, pas la preuve de la cause sur votre site. WordPress sert ici d’exemple ; avec une autre plateforme, la demande peut s’arrêter à d’autres étapes.
Distinguez authentification et livraison réussie
Pour les comptes Gmail personnels, Google exige SPF ou DKIM de tous les expéditeurs. Au-delà de 5 000 messages quotidiens vers ces comptes, les deux et DMARC sont exigés. Ces règles propres au fournisseur ne créent pas d’exemption universelle sous ce volume.
Faites vérifier par l’hébergeur ou le développeur le service d’envoi réel, la configuration du domaine et les exigences du destinataire. L’authentification et le chiffrement du transport répondent à des questions différentes. Ajouter des enregistrements DNS ne prouve pas la réception, et l’emploi de PHP mail() seul ne permet pas de connaître le chiffrement utilisé sur le trajet du message.
WordPress précise qu’un résultat true de wp_mail() ne prouve pas la réception. PHP distingue également l’acceptation pour livraison de l’arrivée à destination. Demandez des éléments au service d’envoi et à la boîte destinataire, sans prendre un appel de fonction réussi pour le résultat final.
Vérifiez les réglages et les changements récents
Vérifiez l’adresse de destination, l’expéditeur configuré et le champ de réponse. Identifiez le service qui envoie réellement, sans supposer que l’hébergeur du site gère aussi la boîte de messagerie. Si plusieurs outils peuvent envoyer des courriels, cherchez celui qui a traité ce test précis.
Comparez le premier échec observé aux changements récents du formulaire, des extensions, de l’hébergement, du DNS ou des identifiants de messagerie. Une mise à jour proche dans le temps est une piste utile, pas une preuve de responsabilité. Faites examiner les journaux pertinents avant de remplacer des composants ou de modifier plusieurs réglages à la fois.
Suivez la demande dans l’ordre
- Notez l’heure et le destinataire convenus, puis vérifiez le résultat visible du formulaire et l’éventuel enregistrement de la demande.
- Vérifiez si le site a créé une demande d’envoi et si le service de messagerie configuré l’a acceptée.
- Cherchez les événements de livraison, les détails d’un rejet ou un avis d’échec, puis examinez les indésirables et les règles de la boîte.
- Vérifiez avec le responsable l’authentification du domaine d’envoi et les exigences du fournisseur destinataire.
- Corrigez la cause identifiée et répétez le test contrôlé jusqu’à la boîte de réception attendue.
Une connexion SMTP authentifiée ou un service de courriels transactionnels peut faire partie de la réparation si le dispositif d’envoi actuel est en cause. Aucun ne garantit le placement en boîte de réception. Après le changement, vérifiez la configuration réelle, les identifiants, le signalement des erreurs et la réception finale.
Que transmettre à l’hébergeur ou au développeur ?
Donnez l’adresse de la page, l’heure du test, le destinataire attendu, le message affiché et tout identifiant d’erreur ou de livraison pertinent. Précisez si la demande a été enregistrée et si d’autres messages du site arrivent. N’incluez ni mots de passe ni contenu confidentiel de demandes clients dans un ticket courant.
Demandez qui prend en charge l’étape suivante : responsable du formulaire, hébergeur, service d’envoi ou administrateur de la boîte destinataire. Si le premier service a accepté le message, demandez le résultat de son étape de livraison suivante. L’investigation reste ainsi liée au point où les preuves s’arrêtent.
Questions
Cela fonctionnait le mois dernier. Une mise à jour est-elle forcément responsable ?
Non. Comparez les dates des mises à jour et des réglages modifiés au premier échec constaté. Identifiants, routage, quotas et filtrage du destinataire doivent aussi être examinés. Corrigez la cause identifiée, puis vérifiez de nouveau le parcours complet de la demande.
L’authentification compte-t-elle pour un formulaire qui envoie très peu ?
Vérifiez les règles du fournisseur destinataire même à faible volume. Un petit formulaire n’est pas automatiquement exempté d’authentification. Une authentification valide fait partie du dispositif d’envoi ; elle ne promet pas l’arrivée de chaque message en boîte de réception.
Faut-il acheter un outil pour consulter les enregistrements DNS ?
Une simple consultation DNS ne nécessite pas, par principe, un abonnement séparé. L’hébergeur ou le développeur peut examiner les enregistrements publiés. Choisir les bonnes valeurs et vérifier le service d’envoi réel sont d’autres tâches : n’ajoutez pas de valeurs supposées et ne partagez pas d’identifiants pour cette seule consultation.
Sources
Pour poursuivre
Étape suivante
Intégrez la réception en boîte à la surveillance régulière
La surveillance et la maintenance comprennent un envoi de test par votre formulaire à intervalles réguliers, pour aider à repérer une interruption des demandes. Le contrôle doit confirmer la réception dans la bonne boîte, plutôt que s’arrêter à l’écran de remerciement.
Nous interroger sur la surveillance
ou écrivez à contact@ergostrat.com