Cuando el formulario de contacto dice «Gracias», pero no llega ningún correo

Imagine un pequeño consultorio de fisioterapia. Su sitio web tiene un formulario de contacto y el formulario funciona, o al menos parece hacerlo. Los visitantes lo llenan, hacen clic en «Enviar» y ven un amable «Gracias, nos comunicaremos con usted pronto». Lo que nadie ve es que los mensajes dejaron de llegar a la bandeja de entrada del consultorio hace algún tiempo. No hay errores, ni mensajes de rebote en la bandeja de nadie, ni ninguna señal de alarma. El formulario falla en silencio.

Por qué nadie lo nota

La página de «Gracias» de un formulario normalmente significa una sola cosa: el sitio web entregó el mensaje al siguiente paso. Que un servidor de correo lo acepte, lo archive como spam o lo rechace en el camino ocurre después, fuera de la vista del formulario. Por ejemplo, la función mail() de PHP informa de éxito en cuanto el sistema local acepta el mensaje para su entrega, no cuando llega a alguien. Así, el visitante recibe una confirmación y continúa. Mientras tanto, el propietario ve una bandeja de entrada vacía y supone que simplemente es un mes tranquilo. Recibir menos consultas rara vez causa alarma por sí solo: las vacaciones, el clima, la economía… siempre hay una explicación que parece más plausible que «el formulario está roto».

Las causas habituales

• Cambió la contraseña SMTP o el proveedor de correo. El formulario sigue iniciando sesión con las credenciales anteriores y el servidor de correo se niega, de forma silenciosa desde el punto de vista del visitante.
• mail() de PHP sin autenticación. El servidor web envía correo directamente, sin iniciar sesión en un servidor de correo adecuado. Muchos servidores receptores consideran sospechosos esos mensajes: terminan en spam o se rechazan por completo.
• SPF, DKIM y DMARC no se alinean. Muchos formularios colocan 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: precisamente lo que DMARC está diseñado para detener.
• Una 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 aparece el widget de CAPTCHA sin su script, y todos los envíos fallan la validación.
• El buzón receptor está lleno. El servidor de correo rechaza mensajes nuevos y el aviso de rebote se envía 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 se puede enviar o cuyos envíos se rechazan porque falta un token.
• Un certificado TLS o un dominio vencido. Los visitantes ven una advertencia del navegador y se van, o ya no se puede acceder de forma segura al servidor de correo. Si vence el dominio del buzón receptor, el correo dirigido a él simplemente deja de llegar.
• Una capa de caché sirve páginas desactualizadas. Una caché de página completa puede entregar un formulario con un token de seguridad vencido, como un nonce o un token CSRF. El servidor rechaza el envío y, según la configuración, el visitante no ve un error claro.

La trampa de la dirección From

La tercera causa merece más atención porque muchas configuraciones de formularios la incluyen de forma predeterminada. DMARC comprueba si el dominio de la dirección From visible coincide con un dominio respaldado por SPF o DKIM. Si el formulario envía un mensaje «desde» la dirección del visitante, su servidor no está autorizado para enviar en nombre de ese dominio y la verificación falla. Según la política DMARC del dominio del visitante y su propio proveedor de correo, el mensaje termina en spam o se rechaza. La solución es sencilla: envíe desde una dirección de su propio dominio y coloque la dirección del visitante en Reply-To. Al hacer clic en «Responder» se sigue llegando al visitante.

Qué hacer

1. 1Envíe regularmente un mensaje de prueba mediante su propio formulario, al menos cada 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.
2. 2Conozca su ritmo habitual. Si el formulario suele traer algunos mensajes por semana, dos semanas de silencio son motivo para revisarlo, no un mes tranquilo.
3. 3Envíe mediante SMTP con autenticación —a través de su proveedor de correo o de un servicio de envío dedicado— en lugar de depender de mail() de PHP.
4. 4Use su propio dominio en From y la dirección del visitante en Reply-To. Después configure SPF, DKIM y DMARC para ese dominio, de modo que los mensajes superen las verificaciones.
5. 5Conserve en la base de datos una copia de cada envío. Muchos plugins de formularios ofrecen esta función, a veces como complemento. Si falla el correo, las consultas siguen ahí.
6. 6Revise el formulario después de cada actualización de un plugin, incluido el CAPTCHA, y también con las cookies rechazadas.

Es fácil olvidar estas verificaciones, por eso vale la pena automatizarlas. Con una cuenta y un dominio verificado, formexposed puede realizar un envío de prueba claramente marcado y comprobar si realmente llega (la verificación de entrega, solo con activación expresa). También detecta el silencio —un formulario que normalmente recibe mensajes y de pronto deja de recibirlos— y verifica SPF, DKIM y DMARC de los correos de notificación, además del vencimiento del certificado TLS y del dominio. Solo recibe alertas cuando algo cambia.

Si solo quiere una primera revisión, una verificación gratuita en formexposed.com no necesita cuenta y no envía nada. Entre otras cosas, muestra si un CAPTCHA está presente pero falla: un widget sin su script, una clave pública de prueba o errores en el navegador, una de las formas más silenciosas en que un formulario deja de funcionar. Que los mensajes realmente lleguen solo puede confirmarse con un mensaje real de prueba, así que envíe uno hoy.