El missatge d’èxit només demostra que el navegador ha rebut una resposta positiva de l’aplicació. No prova que WordPress hagi generat la notificació, que SMTP l’hagi acceptat ni que la bústia destinatària l’hagi lliurat.
Conserva una prova i segueix cada traspàs sense canviar alhora el formulari i el DNS.
Crea una prova controlada
Utilitza un nom clarament marcat, un assumpte o referència únics i un text no sensible. Anota l’hora amb zona, URL, destinatari i navegador.
No enviïs repetidament una consulta real: pot duplicar entrades i confondre l’equip comercial. Prova com a visitant sense sessió en una finestra privada i comprova si es desa una entrada.
Confirma que WordPress ha rebut el formulari
Revisa Entries o Submissions del connector. Si no existeix cap entrada, l’èxit es pot mostrar abans de desar o provenir de la memòria cau o JavaScript.
Si apareixen tots els camps, el recorregut navegador-WordPress ha funcionat. Passa a la generació de la notificació. Consulta els logs per l’hora exacta sense emmagatzemar el contingut personal complet.
Revisa les regles de notificació
Confirma que la notificació estigui habilitada, que el destinatari sigui correcte i que la lògica condicional s’executi amb aquelles respostes.
Comprova les etiquetes dinàmiques de To, From, Reply-To i assumpte. Un token mal escrit pot crear una capçalera buida encara que l’entrada es desi.
No utilitzis el correu arbitrari del visitant com a From. Envia des d’una adreça del domini i posa el visitant a Reply-To.
Captura l’esdeveniment de correu
Utilitza temporalment un registre fiable per desar hora, destinatari, assumpte, capçaleres i resultat. Redacta el cos i els adjunts quan el comparteixis.
wp_mail() pot indicar èxit quan el transport local accepta el missatge, sense garantir-ne el lliurament. Si no apareix cap esdeveniment, inspecciona el hook del formulari; si n’apareix un, segueix l’evidència SMTP.
Comprova l’acceptació SMTP
Consulta el connector o proveïdor cercant autenticació, connexió, message ID i codi. Distingeix:
WordPress no ha cridat el correu
ha fallat la connexió o autenticació
el proveïdor ha acceptat
ha rebutjat remitent, destinatari o límit
ha acceptat i després ha generat un rebotNo publiquis usuaris SMTP, tokens ni capçaleres completes.
Segueix el costat del destinatari
Si el proveïdor ha acceptat, cerca a spam, quarantena, regles i àlies. L’administrador de correu empresarial ha de rastrejar per message ID, remitent i hora.
Provar només un Gmail personal no demostra el lliurament al domini corporatiu. Revisa també els rebots al Return-Path autenticat.
Verifica l’autenticació del remitent
En un missatge lliurat, revisa SPF, DKIM i DMARC per al proveïdor real i el domini From.
No creïs un segon SPF. Integra els remitents autoritzats en una única política vàlida seguint el proveïdor. Els MX controlen la recepció; no autoritzen automàticament l’enviament web.
Repara només el traspàs fallit
Corregeix la notificació, credencial SMTP, alineació, límit o regla de bústia identificats. Desa el rollback del connector i DNS.
Després envia una sola prova marcada i demostra l’entrada, log, acceptació i bústia final. Comprova Reply-To i qualsevol automatització comercial.
Protegeix els leads durant el diagnòstic
Si es desen entrades, revisa-les o exporta-les de manera segura perquè no s’oblidin consultes. Restringeix l’accés perquè contenen dades personals. No les enganxis en tiquets públics.
Si no es desen, publica temporalment un correu o telèfon monitoritzat. Explica la limitació en lloc de mostrar un èxit no fiable. Elimina després les dades de prova segons la retenció.
Quan cal demanar una reparació urgent
Demana ajuda si es perden leads, els registres discrepen o el lliurament varia segons el destinatari. Facilita URL, hora, connector i error no sensible, mai contrasenyes.
Una reparació fiable demostra que el missatge ha arribat a la bústia prevista, no que ha aparegut un avís verd.