Un formulari és una cadena, no una funció aïllada. El navegador envia una petició, WordPress valida i desa les dades, una regla construeix la notificació, el transport la lliura a un proveïdor i el sistema destinatari la filtra fins a una bústia.
Seguir una prova identificada per tots aquests traspassos revela qui controla el punt trencat i evita canvis especulatius.
Prepara un enviament controlat
Utilitza un nom sintètic, una referència única a l’assumpte o al missatge i cap dada personal. Anota l’URL, l’hora exacta amb zona horària, el navegador, l’ID del formulari i el destinatari previst.
No modifiquis la configuració mentre fas el rastreig. Una referència i una hora noves per a cada repetició eviten confondre missatges antics o pàgines en memòria cau.
Si hi ha leads reals en risc, habilita temporalment una via de contacte alternativa i supervisada.
Etapa 1: inspecciona la petició del navegador
Obre les eines del navegador, envia una vegada i localitza la petició POST, AJAX o REST. Registra’n URL, estat i resposta. Un 403 apunta a seguretat, nonce o CAPTCHA; un 500 requereix cercar l’error PHP o del servidor d’aquell moment; un timeout pot implicar PHP, SMTP o límits de xarxa.
El missatge visual d’èxit ha de correspondre a una resposta realment correcta. Un error JavaScript o un recurs bloquejat pot impedir la petició encara que el botó sembli funcionar.
Oculta els valors personals i tokens abans de compartir captures.
Etapa 2: confirma el processament de WordPress
Busca l’entrada sintètica al plugin. Que existeixi confirma bona part de la ruta de petició, però no la generació del correu. Si no hi és, revisa validació, registres del plugin, PHP, esdeveniments de seguretat i errors de base de dades al mateix minut.
Confirma que pertany al formulari actual i al web de producció. Els duplicats i les còpies de staging acostumen a tenir ID o notificacions diferents.
No activis la visualització pública d’errors en producció.
Etapa 3: identifica la notificació
Determina quina regla s’havia d’executar amb els valors enviats. Revisa si està activa, els tokens del destinatari, les condicions, From i Reply-To.
Utilitza una adreça autenticada del domini com a From i la del visitant a Reply-To. Registra l’ID de notificació i el destinatari previst conservant el mínim contingut possible.
Si no es crea cap notificació, l’error continua a la lògica del formulari o del plugin, no a la bústia receptora.
Etapa 4: rastreja el correu a WordPress
Localitza l’intent de wp_mail() o la tasca de cua corresponent. Un resultat fals o una excepció PHP exigeix l’error local exacte. Un resultat correcte només indica que WordPress ha lliurat el missatge al transport configurat.
Si hi ha una cua, anota creació, hora prevista, intents i estat final. Comprova WP-Cron o el planificador real del servidor en comptes d’esborrar tasques pendents.
Protegeix els registres i elimina les dades de diagnòstic quan deixin de ser necessàries.
Etapa 5: consulta el proveïdor SMTP
Cerca per destinatari, hora i referència. Registra si el proveïdor ha acceptat, ajornat, rebotat, bloquejat o suprimit l’adreça, juntament amb el message ID i el codi amb dades ocultes.
Revisa credencials, xifratge i límits només si l’evidència apunta a aquesta etapa. Repetir proves sense control pot empitjorar una limitació.
L’acceptació del proveïdor encara no acredita que el destinatari hagi vist el missatge.
Etapa 6: segueix el sistema destinatari
Demana a l’administrador autoritzat que cerqui al gateway per message ID, remitent, destinatari i hora. Revisa quarantena, regles de transport, àlies, grups i restriccions de bústies compartides.
En una còpia lliurada, comprova l’alineació SPF, DKIM i DMARC. Dos dominis poden aplicar la mateixa autenticació de manera diferent.
Consulta els rebots al Return-Path i no canviïs els registres MX per reparar correu sortint.
Crea un registre de rastreig útil
Resumeix etapa, hora, identificador, resultat i responsable en una taula. Exclou contrasenyes, claus API i contingut real. La primera etapa absent o fallida determina la investigació següent.
Després de reparar, recorre tota la cadena amb una referència nova. Confirma un èxit al navegador, una entrada, la notificació correcta, un missatge acceptat i la bústia final.
Demana una reparació urgent si intervenen diversos proveïdors, les evidències es contradiuen o els enviaments són comercialment crítics. Una bona resolució demostra el traspàs que ha fallat i el resultat final.