Fiabilité de l’envoi des formulaires sur un site autonome : configuration SMTP, taux de délivrabilité, nouvelles tentatives en cas d’échec et journaux
1. Pourquoi PHP mail() n’est pas fiable
Beaucoup de webmasters pensent que tout est réglé une fois la page de confirmation affichée après un clic sur “Envoyer”. En réalité, la fonction wp_mail() de WordPress passe par la fonction mail() intégrée à PHP : pas d’authentification de l’expéditeur, pas de chiffrement TLS, pas de pool d’IP dédié. Les e-mails envoyés sont très souvent classés comme spam par Gmail et Outlook.
Ce n’est pas un problème de plugin, c’est un problème de protocole. mail() confie l’e-mail au MTA local (agent de transfert de courrier), qui se connecte directement au serveur MX du destinataire sur le port 25. Or la grande majorité des hébergeurs cloud (Alibaba Cloud, Tencent Cloud, AWS) bloquent par défaut le port 25 sortant pour lutter contre le spam. Résultat : le formulaire affiche un succès, mais l’e-mail n’est jamais parti.
Un constat contre-intuitif :Plus une méthode d’envoi est “simple”, plus elle vous fait perdre de commandes. Se passer d’un plugin SMTP donne l’impression d’économiser une demi-heure de configuration, mais vous perdez en réalité 20 % à 40 % de vos demandes chaque mois, sans jamais le savoir, puisque la page de soumission affiche une coche verte. Pour savoir comment concevoir les champs d’un formulaire afin de concilier conversion et filtrage, voir Conception des champs du formulaire de demande et taux de conversion.
| Méthode d’envoi | Taux de délivrabilité moyen | Complexité de configuration | Cas d’usage |
|---|---|---|---|
| PHP mail() (par défaut) | 40 % à 60 % | Aucune configuration | Déconseillé pour tout site en production |
| SMTP local de l’hébergeur | 60 % à 75 % | Faible | Pour un environnement de test |
| Relais SMTP tiers (offre gratuite) | 85 % à 92 % | Moyenne | Jusqu’à 5 000 e-mails par mois |
| Service d’e-mails transactionnels dédié | Plus de 95 % | Moyenne à élevée | Plus de 5 000 e-mails par mois |
2. Configuration SMTP : choix du plugin et paramètres
Configurer SMTP sur WordPress ne demande aucune modification de code : il suffit d’installer un plugin. Trois choix dominent : WP Mail SMTP (le plus répandu, interface claire), FluentSMTP (open source et gratuit, avec bascule vers un autre fournisseur en cas de panne) et Post SMTP (les journaux les plus complets). Choisissez-en un seul, n’en installez pas deux à la fois, ils entreraient en conflit.
7 paramètres sont essentiels : l’hôte SMTP, le port (587 ou 465, jamais 25), le chiffrement (TLS ou SSL), le nom d’utilisateur, le mot de passe ou la clé API, l’adresse d’expédition et le nom de l’expéditeur. L’adresse d’expédition doit correspondre à votre domaine, par exemple noreply@yourdomain.com. N’utilisez pas une adresse Gmail ou QQ : l’enregistrement SPF ne correspondrait pas et vos e-mails finiraient en spam.
Exemple concret : vous utilisez SendGrid comme relais SMTP. Hôte : smtp.sendgrid.net, port : 587, chiffrement : TLS, nom d’utilisateur : apikey (valeur fixe), mot de passe : la clé API générée dans votre interface SendGrid. Adresse d’expédition : noreply@yourdomain.com. Ajoutez ensuite trois enregistrements DNS, on voit ça dans la section suivante.
| Caractéristique | Valeur correcte | Erreur fréquente |
|---|---|---|
| Hôte SMTP | smtp.sendgrid.net / smtp.mailgun.org | localhost ou l’IP de la machine |
| Port | 587 (TLS) ou 465 (SSL) | 25, bloqué par l’hébergeur |
| Chiffrement | TLS (587) ou SSL (465) | “Aucun chiffrement”, transmission en clair |
| Nom d’utilisateur | apikey (fixe) chez SendGrid, postmaster@mg.xxx chez Mailgun | votre propre adresse e-mail |
| Expéditeur | noreply@votredomaine.com | une adresse Gmail ou QQ personnelle |
| Nom de l’expéditeur | nom anglais de la société + service | vide ou caractères illisibles |
3. Authentification du domaine : les trois enregistrements SPF, DKIM et DMARC
Configurer le plugin SMTP n’est que la première étape. Pourquoi le serveur du destinataire croirait-il que ce message vient bien de vous ? Grâce à trois enregistrements DNS : SPF (quels serveurs ont le droit d’envoyer vos e-mails), DKIM (une signature numérique qui protège le message de toute modification) et DMARC (la consigne donnée au destinataire quand un message ne respecte pas les règles). S’il en manque un, votre taux de délivrabilité ne décollera pas.
SPF est un enregistrement TXT qui ressemble à v=spf1 include:sendgrid.net ~all : “seuls les serveurs de SendGrid peuvent envoyer du courrier avec mon domaine, tout le reste échoue en douceur”. DKIM est un enregistrement CNAME : le fournisseur SMTP publie une clé publique et le destinataire s’en sert pour vérifier la signature. DMARC est aussi un enregistrement TXT, commence par v=DMARC1 ; commencez par p=none pendant une semaine, puis passez à p=quarantine.
Comment vérifier : saisissez votre domaine dans MXToolbox ou dans l’outil Checkup de Google Admin Toolbox. Les trois voyants doivent être au vert. Si SPF affiche “not found” ou DKIM “no key”, ajoutez l’enregistrement manquant dans votre panneau DNS, attendez 15 minutes qu’il soit actif, puis relancez le test. Pour articuler conformité du domaine et RGPD, voir Fondations de conformité pour un site à l’international.
| Type d’enregistrement | Rôle | Configuration minimale | Outil de vérification |
|---|---|---|---|
| SPF (TXT) | Déclare les serveurs autorisés à envoyer | v=spf1 include:fournisseur ~all | Vérification SPF MXToolbox |
| DKIM (CNAME/TXT) | Signature numérique anti-falsification | enregistrement selector fourni par le service | Vérification de clé DKIM Core |
| DMARC (TXT) | Politique et collecte des rapports | v=DMARC1; p=none; rua=e-mail | Google Admin Toolbox |
| MTA-STS (TXT) | Impose le chiffrement TLS | v=STSv1; id=20260921 | MXToolbox MTA-STS |
4. Indicateurs de délivrabilité et nouvelles tentatives en cas d’échec
Configurer SMTP et DNS ne suffit pas : il faut surveiller les indicateurs. Trois chiffres clés : le taux de délivrabilité en boîte de réception (la part qui arrive en inbox, pas en spam), le taux de hard bounce (adresse inexistante, domaine inexistant, échec permanent) et le taux de soft bounce (boîte pleine, serveur occupé, échec temporaire). Les seuils sains : délivrabilité ≥ 95 %, hard bounce ≤ 2 %, soft bounce ≤ 5 %.
Ne comptez pas sur les réglages par défaut du plugin pour les nouvelles tentatives. Par défaut, les plugins de formulaires WordPress envoient une fois et s’arrêtent, sans signaler d’erreur sur la page. La bonne méthode : ajouter une couche de retry. Après le premier échec, réessayer au bout d’1 minute, puis 5 minutes, puis 15 minutes, puis 60 minutes. Si les quatre tentatives échouent, déclencher une alerte (vers votre boîte de secours ou WeCom) et enregistrer la demande en base pour un renvoi manuel.
Exemple concret : un client en Allemagne remplit le formulaire à 23 h (6 h chez vous à Pékin), au moment même où SendGrid effectue une maintenance et où SMTP renvoie une erreur temporaire. Sans retry, la demande est perdue. Avec un backoff exponentiel, la quatrième tentative aboutit 60 minutes plus tard et le client reçoit votre réponse automatique à son réveil. Pour définir le délai de première réponse, voir SLA de première réponse aux demandes et taux de conversion.
| Indicateur | Seuil de vigilance | Seuils d’alerte | Action à mener |
|---|---|---|---|
| Délivrabilité en boîte de réception | ≥ 95 % | Moins de 90 % | Vérifier les logs SPF/DKIM |
| Taux de hard bounce | ≤ 2 % | Supérieur à 5 % | Nettoyer la liste des adresses invalides |
| Taux de soft bounce | ≤ 5 % | Supérieur à 10 % | Vérifier l’état du fournisseur SMTP |
| Taux de réussite des retries | ≥ 80 % | Inférieur à 50 % | Basculer sur le canal SMTP de secours |
| Volume quotidien de soumissions | Baseline ±20 % | Chute de plus de 50 % | Vérifier si le JS front-end renvoie une erreur |
V. Journalisation et auto-contrôle hebdomadaire
Sans logs, aucun diagnostic possible. Le plugin Post SMTP intègre une table de journal des e-mails qui enregistre pour chaque message le from, le to, le subject, l’heure d’envoi, le code de réponse SMTP et le nombre de tentatives. FluentSMTP propose une fonction équivalente. Conservez les logs au moins 30 jours, avec purge automatique au-delà, pour éviter de saturer la base de données.
Faites un auto-contrôle chaque semaine : prélevez 5 e-mails récents et vérifiez que le code de réponse SMTP appartient à la série 250 (250 = succès, 4xx = échec temporaire, 5xx = échec permanent). Envoyez aussi un message de test vers votre Gmail, cliquez sur « Afficher l’original » et vérifiez que SPF=pass, DKIM=pass et DMARC=pass sont tous au vert. Si l’un d’eux est en fail, vérifiez immédiatement le DNS.
Autre point souvent négligé : le plugin de formulaire doit lui aussi journaliser. Si une erreur JS empêche la requête de partir après la soumission, rien n’apparaîtra dans les logs SMTP. Il faut donc ajouter au niveau serveur une surveillance du Nginx access log, en comptant les requêtes POST vers /wp-admin/admin-ajax.php (ou l’endpoint REST API). Si ce volume chute de plus de 50 % un jour donné, c’est que le front-end a un problème. Pour configurer la surveillance du site, voir Surveillance et alertes du site.
| Couche de journalisation | Donnée enregistrée | Durée de conservation | Mode de consultation |
|---|---|---|---|
| Journal des soumissions de formulaire | Valeurs des champs, IP, UA, horodatage | 90 jours | Back-office du plugin / table de base de données |
| Journal des envois SMTP | Codes de réponse, tentatives, messages d’erreur | 30 jours | Page de journal de l’extension SMTP |
| Journal de livraison ESP | Ouvertures, clics, plaintes, rejets | Panneau du fournisseur, permanent | Console SendGrid/Mailgun |
| Journaux d’accès Nginx | Volume de requêtes POST, répartition des codes de statut | 14 jours | grep access.log sur le serveur |
FAQ — Questions fréquentes
Faut-il vraiment une extension SMTP pour les formulaires WordPress, ou PHP mail() suffit-il ?
Faut-il configurer SPF, DKIM et DMARC, ou SPF seul suffit-il ?
Quel port SMTP choisir : 25, 587 ou 465 ?
Comment vérifier la délivrabilité, et où voir si un e-mail est arrivé en boîte de réception ou en spam ?
L’e-mail ne part pas après l’envoi du formulaire : comment diagnostiquer au plus vite ?
Le quota SMTP gratuit suffit-il, et quand faut-il passer au payant ?
Pour conclure
La livraison des formulaires est le point de fuite le plus négligé d’un site indépendant. La plupart des webmasters surveillent le trafic et le taux de conversion, mais n’ont jamais vérifié si l’e-mail derrière le message « envoi réussi » est bien arrivé chez le client. Configurer un SMTP et trois enregistrements DNS, deux heures de travail, peut réduire de plus de moitié les commandes perdues chaque mois.
Trois étapes concrètes : cette semaine, installez un plugin SMTP et connectez-le à une offre gratuite SendGrid ou Mailgun ; ensuite, ajoutez les trois enregistrements SPF, DKIM et DMARC dans votre panneau DNS et vérifiez qu’ils sont tous au vert avec MXToolbox ; enfin, configurez 4 tentatives avec un délai exponentiel et prélevez 5 e-mails par semaine pour contrôler leur statut de livraison. Une fois ces trois actions faites, la fiabilité de vos formulaires a un socle.
Une phrase à retenir : la coche verte sur un formulaire signifie seulement que « le serveur a reçu », pas que « le client a vu » — entre les deux, il y a le SMTP, le DNS et le dossier spam.