Cuando el formulario de contacto dice «Gracias» pero no llega ningún correo
Un formulario de contacto puede romperse sin que nadie vea un error: el visitante recibe una amable confirmación y usted no recibe nada. Por qué ocurre y cómo darse cuenta a tiempo.
Imagine una pequeña consulta de fisioterapia. Su sitio web tiene un formulario de contacto, y el formulario funciona, o al menos lo parece. Los visitantes lo rellenan, hacen clic en «Enviar» y ven un amable «Gracias, nos pondremos en contacto con usted en breve». Lo que nadie ve: hace tiempo que los mensajes dejaron de llegar a la bandeja de entrada de la consulta. No hay ningún error, ningún rebote en ninguna bandeja de entrada, ninguna luz roja en ninguna parte. El formulario falla en silencio.
Por qué nadie se da cuenta
La página de «Gracias» de un formulario normalmente solo significa una cosa: el sitio web ha entregado el mensaje. Si un servidor de correo lo acepta, lo clasifica como spam o lo rechaza por el camino ocurre más tarde, fuera de la vista del formulario. La función mail() de PHP, por ejemplo, informa de éxito en cuanto el sistema local acepta el mensaje para su entrega, no cuando llega a alguien. Así que el visitante recibe una confirmación y sigue adelante. El propietario, mientras tanto, ve una bandeja de entrada vacía y supone que simplemente es un mes tranquilo. Tener menos consultas rara vez resulta alarmante por sí solo: las vacaciones, el tiempo, la economía; siempre hay una explicación que suena más plausible que «el formulario está roto».
- Día 0Durante la noche se ejecuta una actualización rutinaria de un plugin. El sitio tiene exactamente el mismo aspecto que antes.
- Día 1Llega el último mensaje. Nadie sabe que es el último.
- Días 2–13Los visitantes siguen enviando el formulario y siguen viendo «Gracias». A la bandeja de entrada no llega nada.
- Día 14Alguien llama y pregunta, algo molesto, por qué nadie ha respondido nunca a su consulta.
- Día 15La causa se encuentra en menos de una hora. Los mensajes de esas dos semanas se han perdido, salvo que el formulario guardara también una copia.
Las causas habituales
- Ha cambiado la contraseña SMTP o el proveedor de correo. El formulario sigue iniciando sesión con las credenciales antiguas y el servidor de correo lo rechaza, en silencio desde el punto de vista del visitante.
- mail() de PHP sin autenticación. El servidor web envía el correo directamente, sin iniciar sesión en un servidor de correo propiamente dicho. Muchos servidores receptores consideran sospechoso ese correo: acaba en spam o se rechaza directamente.
- SPF, DKIM y DMARC no cuadran. Muchos formularios ponen la dirección del visitante en el campo From. El mensaje afirma entonces proceder, por ejemplo, de una dirección de gmail.com, pero lo envía su servidor web: exactamente lo que DMARC está diseñado para impedir.
- La actualización de un plugin o un cambio de tema rompe el formulario o su CAPTCHA. Una plantilla modificada elimina un campo, un script deja de cargarse o el widget del CAPTCHA aparece sin su script, y todos los envíos fallan en la validación.
- El buzón receptor está lleno. El servidor de correo rechaza los mensajes nuevos, y el rebote va a una dirección que nadie lee.
- El banner de cookies bloquea el script del formulario. Si la herramienta de consentimiento clasifica el CAPTCHA o el script del formulario como «marketing», los visitantes que rechazan las cookies pueden encontrarse con un formulario que no puede enviarse, o cuyos envíos se rechazan porque falta un token.
- Un certificado TLS o un dominio caducado. Los visitantes ven una advertencia del navegador y se marchan, o ya no es posible conectarse de forma segura al servidor de correo. Si caduca el dominio del buzón receptor, el correo dirigido a él simplemente deja de llegar.
- Una capa de caché sirve páginas obsoletas. Una caché de página completa puede entregar un formulario con un token de seguridad caducado (un nonce o un token CSRF). El servidor rechaza el envío y, según la configuración, el visitante no ve ningún error claro.
La trampa de la dirección From
La tercera causa merece una mirada más atenta, porque muchas configuraciones de formularios la traen incorporada por defecto. DMARC comprueba si el dominio de la dirección From visible coincide con un dominio avalado por SPF o DKIM. Si el formulario envía un mensaje «desde» la dirección del visitante, su servidor no está autorizado a enviar en nombre de ese dominio, por lo que la comprobación falla. Según la política DMARC del dominio del visitante y según su propio proveedor de correo, el mensaje acaba en spam o se rechaza. La solución es sencilla: envíe desde una dirección de su propio dominio y ponga la dirección del visitante en Reply-To. Al hacer clic en «Responder», la respuesta sigue llegando al visitante.
- From: la dirección del visitante
- Sin Reply-To
- mail() de PHP directamente desde el servidor web
- Sin SPF, DKIM ni DMARC para el dominio remitente
- El mensaje solo existe como correo electrónico
- From: una dirección de su propio dominio, p. ej. formulario@sudominio
- Reply-To: la dirección del visitante
- SMTP con autenticación o un servicio de envío
- SPF, DKIM y DMARC configurados y alineados
- También se guarda una copia en la base de datos
Qué hacer
- 1Envíe periódicamente un mensaje de prueba a través de su propio formulario: al menos una vez al mes y siempre después de actualizaciones, cambios de tema o cambios en la configuración del correo. Márquelo claramente como prueba para que nadie lo responda.
- 2Conozca su ritmo normal. Si el formulario suele traer unos cuantos mensajes a la semana, dos semanas de silencio son motivo para comprobar, no un mes tranquilo.
- 3Envíe mediante SMTP con autenticación (a través de su proveedor de correo o de un servicio de envío específico) en lugar de confiar en mail() de PHP.
- 4Utilice su propio dominio en From y la dirección del visitante en Reply-To. Después configure SPF, DKIM y DMARC para ese dominio para que los mensajes superen las comprobaciones.
- 5Guarde una copia de cada envío en la base de datos. Muchos plugins de formularios lo ofrecen, a veces como complemento. Si falla el correo, las consultas siguen ahí.
- 6Compruebe el formulario después de cada actualización de un plugin, incluido el CAPTCHA, y también con las cookies rechazadas.
Comprobaciones como estas son fáciles de olvidar, por eso merece la pena automatizarlas. Con una cuenta y un dominio verificado, formexposed puede enviar un envío de prueba claramente identificado y comprobar si llega realmente (la comprobación de entrega, solo si usted la activa). También detecta el silencio (un formulario que normalmente recibe mensajes y de repente no recibe ninguno) y comprueba SPF, DKIM y DMARC de los correos de notificación, así como la caducidad del certificado TLS y del dominio. Solo recibe una alerta cuando algo cambia.
Si solo quiere echar un primer vistazo: una comprobación gratuita en formexposed.com no necesita cuenta y no envía nada. Entre otras cosas, muestra si hay un CAPTCHA presente pero roto (un widget sin su script, una clave de prueba pública, errores en el navegador), una de las formas más silenciosas en que un formulario deja de funcionar. Si los mensajes llegan realmente solo puede confirmarlo un mensaje de prueba real, así que envíe uno hoy mismo.