Por qué no te llegan los mensajes del formulario de tu web
Cuando un cliente te escribe por la web y ese mensaje no aparece en tu bandeja, casi nunca es que «el formulario esté roto»: en la mayoría de los casos el formulario funciona y guarda el envío, pero el correo de aviso se pierde porque el remitente no está autorizado para enviar en nombre de tu dominio. Es un problema de correo, no de web, y se arregla en un rato si sabes dónde mirar. Aquí tienes el orden exacto en el que conviene comprobarlo, de lo más probable a lo más raro.
Primero: comprueba si el mensaje se ha guardado
Antes de tocar nada de correo, averigua si el envío llegó a tu web. Casi cualquier gestor de formularios decente guarda una copia de cada envío en la base de datos. En una web hecha con Drupal, por ejemplo, el módulo Webform lista todos los envíos recibidos aunque ninguna notificación haya salido.
Este paso separa dos mundos muy distintos:
- Hay envíos guardados y no hay correos. El formulario funciona; el problema está en el envío o la entrega del aviso. Sigue leyendo: es el caso habitual.
- No hay ningún envío guardado. Entonces sí hay algo que falla antes: un error de JavaScript, un captcha que bloquea, un campo obligatorio invisible o una caché que sirve una versión antigua de la página.
Haz una prueba tú mismo desde el móvil, con datos reales, y mira si aparece en la lista de envíos. Cinco minutos que te ahorran horas de búsqueda en el sitio equivocado.
La causa número uno: tu web envía correo sin permiso
Este es el fallo que explica la mayoría de los casos. Tu web intenta enviar un correo que parece venir de info@tudominio.es, pero lo hace desde el servidor de hosting, que no es el servidor de correo de tu dominio. Para el buzón que lo recibe, eso tiene toda la pinta de una suplantación, así que lo tira a spam o lo rechaza directamente.
Tres registros en tu dominio deciden si ese correo se cree o no:
- SPF: la lista de servidores autorizados a enviar correo en nombre de tu dominio. Si el servidor de tu web no está en esa lista, malo.
- DKIM: una firma criptográfica que demuestra que el mensaje salió de quien dice y no se ha modificado por el camino.
- DMARC: la política que le dices al mundo sobre qué hacer con los correos que no pasan SPF ni DKIM: ignorarlo, marcarlo o rechazarlo.
Esto ya no es opcional. Google y Yahoo endurecieron en 2024 sus requisitos para quien envía correo a sus usuarios y exigen autenticación con SPF o DKIM y registros coherentes. Si tus avisos van a un Gmail y no están autenticados, tienen todas las papeletas de desaparecer.
La solución que funciona: enviar por SMTP autenticado
La forma robusta de arreglarlo es dejar de enviar correo «desde la web» y hacer que la web use un servidor de correo de verdad, con usuario y contraseña. Es lo que se llama envío por SMTP autenticado, y puede ser tu propio correo corporativo o un servicio especializado en correo transaccional.
El plan, por orden:
- Elige por dónde va a salir el correo: el buzón de tu dominio o un servicio de envío transaccional.
- Configura la web para usar ese servidor con credenciales propias. En Drupal se hace con módulos como SMTP o Symfony Mailer; en otras plataformas hay equivalentes.
- Publica los registros SPF y DKIM que te indique ese proveedor en las DNS de tu dominio.
- Añade DMARC, empezando por una política de observación para ver informes antes de endurecerla.
- Usa un remitente coherente: que el «de» sea una dirección real de tu dominio, no noreply@localhost ni el correo del cliente que rellenó el formulario.
Ese último punto es sutil y muy común: si configuras el formulario para que el remitente sea el correo del visitante, estás enviando en nombre de un dominio ajeno y romperás la autenticación casi siempre. Pon tu dirección como remitente y la del visitante en el campo de respuesta.
Otras causas frecuentes, en orden de probabilidad
| Síntoma | Causa probable | Cómo comprobarlo |
|---|---|---|
| Llegaban y de pronto dejaron de llegar | Cambio de hosting, de DNS o caducidad de una clave DKIM | Mira qué cambió en la web o el dominio la semana anterior |
| Llegan a una dirección pero no a otra | Filtro o regla en el buzón que no recibe | Revisa spam, reglas, carpetas y filtros del buzón |
| Llegan con retraso de horas | Cola de envío del servidor o del cron de la web | Comprueba si la web envía en diferido con una cola |
| Llegan vacíos o sin algunos campos | Plantilla del aviso mal configurada tras un cambio en el formulario | Compara los campos del formulario con los de la plantilla |
| No llega nada y tampoco hay envíos guardados | Captcha, validación o caché bloqueando el envío | Prueba con el captcha desactivado un momento |
| Solo fallan los formularios con adjuntos | Límite de tamaño del servidor de correo | Prueba el mismo envío sin fichero |
Cómo montar un sistema que te avise cuando esto vuelva a pasar
El problema de fondo del correo de formularios es que su fallo es silencioso: no te enteras hasta que un cliente te llama enfadado porque «te escribí hace dos semanas». Merece la pena montar tres salvaguardas:
- Guarda siempre los envíos en la web, no solo los mandes por correo. Así el mensaje existe aunque el aviso se pierda.
- Manda copia a dos destinos distintos, por ejemplo tu correo corporativo y el CRM. Si falla uno, queda el otro.
- Haz una prueba periódica. Una vez al mes, alguien rellena el formulario y confirma que el aviso llega. Ponlo en el calendario junto al resto del mantenimiento de la web.
Y si trabajas con volumen de consultas, lo lógico es que el formulario cree directamente una ficha en tu CRM o una tarea asignada a alguien. El correo es un aviso; el registro del cliente no debería vivir en una bandeja de entrada.
Qué decirle a quien mantiene tu web
Para que la conversación sea corta y productiva, pide estas cinco cosas concretas:
- Que confirme si los envíos se están guardando en la base de datos y desde cuándo.
- Que la web envíe por SMTP autenticado y no con el envío por defecto del servidor.
- Que el remitente de los avisos sea una dirección de tu dominio y el correo del visitante vaya en «responder a».
- Que revise y te enseñe los registros SPF, DKIM y DMARC del dominio.
- Que active un registro de los correos que la web intenta enviar, para ver los fallos en lugar de suponerlos.
Si además cambiaste de proveedor de web hace poco, pregunta expresamente quién gestiona ahora las DNS del dominio: es habitual que los registros de correo se queden atrás en una mudanza.
En resumen: el formulario suele estar bien
Lo que falla casi siempre es la entrega del aviso, no el formulario. Empieza comprobando si los envíos se guardan, sigue por el remitente y por SPF, DKIM y DMARC, pasa el envío a SMTP autenticado y deja montado un sistema que guarde cada consulta en la web y avise a dos sitios. Con eso dejas de perder clientes por un correo que nunca salió, que es la forma más absurda de perder una venta.
Si llevas tiempo sospechando que se te escapan consultas y no sabes por dónde empezar, escríbenos y revisamos el formulario y el correo de tu web para que cada mensaje llegue a quien tiene que atenderlo.