Qué comprobar cuando la web está online pero los formularios no llegan

Una página web puede estar perfectamente accesible, pero si los formularios de contacto, solicitud de presupuesto o registro no envían los datos, la empresa pierde oportunidades reales. Este problema suele pasar desapercibido porque el visitante ve la página cargada y, a veces, recibe un mensaje de “enviado” sin que el correo llegue al buzón. En este artículo revisamos, paso a paso, qué comprobar cuando la web está online pero los formularios no llegan, con casos de uso típicos que cualquier PYME o autónomo puede reconocer.

Tip rápido: Si ya has revisado la configuración del hosting y el dominio, pasa a la siguiente lista de verificación antes de abrir un ticket de soporte.

---

Tabla de verificación rápida

Problema	Causa probable	Revisión	Solución propuesta
No llegan los correos del formulario	MX mal configurado o DNS desactualizado	Verificar registros MX y SPF/DKIM	Corregir DNS y volver a validar
Mensaje “enviado” pero sin entrega	Script PHP con error silencioso	Revisar logs de errores del servidor	Depurar script, habilitar error_reporting
Formulario vacío o campos perdidos	Plugin de caché que sirve una versión antigua	Desactivar caché temporalmente	Excluir la página del formulario de la caché
Correo bloqueado por antispam interno	Falta de SPF/DKIM o IP en blacklist	Consultar herramientas de blacklist	Añadir registros SPF/DKIM y solicitar eliminación
Límite de envío superado (quota)	Hosting con límite de envíos diarios	Revisar panel de control de correo	Solicitar ampliación o usar servicio SMTP externo

Esta tabla sirve como punto de partida; a continuación, cada caso se detalla con ejemplos reales.

---

Caso 1 – Configuración de los registros MX y DNS

Escenario típico

Una pequeña agencia de diseño ha cambiado recientemente de proveedor de hosting. La web sigue funcionando, pero los formularios de contacto dejan de llegar a la bandeja de entrada del responsable de ventas.

Qué hace el agente o sistema

El servidor de correo del nuevo hosting tiene sus propios registros MX. Si el dominio sigue apuntando a los antiguos registros MX, los correos enviados por el formulario se pierden o son devueltos al remitente.

Qué se gana al corregirlo

• Continuidad operativa: los leads llegan sin interrupciones.
• Credibilidad: evita que los clientes reciban mensajes de error o “correo no entregado”.

Pasos de comprobación

1. Accede al panel de gestión DNS del dominio.
2. Verifica que los registros MX apunten al servidor de correo activo.
3. Comprueba que existan registros SPF y DKIM que autoricen al dominio enviar correos desde la IP del hosting.
4. Usa herramientas como MXToolbox para validar la configuración.

Si la migración de dominio o hosting está en marcha, revisa también la guía Cómo migrar web y correo sin perder datos.

---

Caso 2 – Filtros antispam del dominio y del buzón

Escenario típico

Un autónomo que vende servicios de consultoría recibe un mensaje de “formulario enviado” en la web, pero nunca ve el correo en su bandeja de entrada. Al revisar la carpeta de spam, tampoco aparece.

Qué hace el agente o sistema

Los filtros antispam del proveedor de correo analizan el remitente, la IP y los encabezados. Si el dominio no tiene registros SPF/DKIM o la IP está en alguna lista negra, el mensaje se descarta sin notificar al usuario.

Qué se gana al corregirlo

• Tasa de conversión mejorada: cada formulario se traduce en una oportunidad real.
• Reducción de falsos negativos: el filtro no bloquea correos legítimos.

Pasos de comprobación

1. Accede al panel de control del correo profesional (p.ej., cPanel, Plesk o panel propio).
2. Revisa la sección de spam y quarantined messages.
3. Usa un servicio de blacklist (por ejemplo, Spamhaus) para comprobar si la IP del servidor está listada.
4. Añade la dirección de envío a la lista blanca del buzón y, si procede, solicita la eliminación de la IP de la blacklist.

---

Caso 3 – Errores en el script del formulario

Escenario típico

Una tienda online con WordPress utiliza un formulario de contacto creado con un plugin. Los usuarios informan que el formulario muestra el mensaje “¡Gracias! Tu mensaje se ha enviado”, pero el propietario nunca recibe los correos.

Qué hace el agente o sistema

El plugin ejecuta un script PHP que, al fallar, no muestra el error al usuario. El error puede deberse a:

• Falta de la función mail() en la configuración del servidor.
• Problemas de permisos de escritura en el directorio temporal.
• Conflicto con otro plugin que sobrescribe la variable $_POST.

Qué se gana al depurar

• Visibilidad del fallo: los logs indican el origen exacto.
• Estabilidad: se evita que futuros cambios rompan el envío.

Pasos de comprobación

1. Activa la visualización de errores en wp-config.php (define('WP_DEBUG', true);).
2. Revisa el log de errores del servidor (usualmente en /var/log/apache2/error.log o en el panel de hosting).
3. Comprueba que la función mail() está habilitada (phpinfo() → sección mail).
4. Si el script usa un servicio SMTP externo, verifica las credenciales y la conectividad (puerto 587, TLS).

Para evitar conflictos tras actualizaciones, sigue la guía de Actualizar plugins y temas sin romper la web.

---

Caso 4 – Cambios recientes en plugins o tema

Escenario típico

Una PYME ha actualizado recientemente el tema de su sitio y varios plugins de seguridad. Después de la actualización, los formularios dejan de llegar, aunque el resto de la web funciona sin problemas.

Qué hace el agente o sistema

Algunos plugins de seguridad añaden reglas de mod_security o modifican el htaccess para bloquear peticiones POST sospechosas. Otros temas pueden sobrescribir la URL de acción del formulario.

Qué se gana al revisar la configuración post‑actualización

• Seguridad sin sacrificar funcionalidad: se mantiene la protección contra ataques y se garantiza el envío de formularios.
• Mantenimiento preventivo: se detectan incompatibilidades antes de que afecten a los usuarios.

Pasos de comprobación

1. Desactiva temporalmente los plugins de seguridad y verifica si el formulario vuelve a funcionar.
2. Revisa el archivo .htaccess en busca de reglas que bloqueen POST a admin-ajax.php o a la ruta del formulario.
3. Si el problema desaparece, reactiva los plugins uno a uno para identificar el conflictivo.
4. En caso de conflicto, busca una alternativa o configura una excepción en el plugin de seguridad.

---

Caso 5 – Limitaciones del hosting o cuota de envío

Escenario típico

Una startup ha contratado un plan de hosting compartido con un límite de 100 correos enviados al día. Tras una campaña de marketing, los formularios dejan de llegar porque se ha superado la cuota.

Qué hace el agente o sistema

El servidor bloquea cualquier envío adicional y devuelve un código de error 550 al script, que normalmente no lo muestra al usuario.

Qué se gana al monitorizar la cuota

• Prevención de bloqueos inesperados: se planifica el uso de recursos.
• Escalabilidad: se decide cuándo migrar a un plan con mayor capacidad o a un servicio SMTP dedicado.

Pasos de comprobación

1. Accede al panel de hosting y revisa la sección de uso de correo.
2. Busca en los logs del servidor mensajes con código 550 o 554.
3. Si la cuota está agotada, considera:
   • Ampliar el plan de hosting.
   • Configurar un SMTP externo (p.ej., SendGrid, Mailgun) para los formularios.
4. Implementa una alerta automática (por ejemplo, vía cron) que notifique cuando el número de envíos alcance el un porcentaje variable de la cuota.

---

Caso 6 – Problemas de caché y versiones estáticas

Escenario típico

Una empresa usa un CDN y un plugin de caché para acelerar su sitio. Los formularios funcionan en modo incognito, pero no en la versión normal del navegador.

Qué hace el agente o sistema

El plugin de caché sirve una versión estática del HTML que incluye un token CSRF caducado o una URL de acción desactualizada. El navegador envía la petición, pero el servidor la rechaza silenciosamente.

Qué se gana al excluir el formulario de la caché

• Experiencia de usuario coherente: el formulario siempre está actualizado.
• Reducción de tickets de soporte: se elimina una causa frecuente de “el formulario no funciona”.

Pasos de comprobación

1. Accede a la configuración del plugin de caché (p.ej., WP Super Cache, W3 Total Cache).
2. Añade la URL del formulario a la lista de exclusiones o marca la opción “No cachear páginas con formularios”.
3. Purga la caché y prueba nuevamente el envío.
4. Si utilizas un CDN, verifica que la regla de bypass para la ruta del formulario esté activa.

---

Caso 7 – Verificación de la integridad del formulario

Escenario típico

Un profesional independiente ha creado un formulario con campos personalizados (fecha, número de formulario de contacto, archivo adjunto). Los usuarios pueden enviarlo, pero el correo llega sin los datos del archivo adjunto.

Qué hace el agente o sistema

El formulario no gestiona correctamente los multipart/form-data o el límite de tamaño de archivo supera la configuración del servidor (upload_max_filesize y post_max_size).

Qué se gana al ajustar los límites

• Recopilación completa de información: se reciben todos los datos necesarios para cerrar la venta.
• Cumplimiento de normas de seguridad: se evita que archivos demasiado grandes saturen el servidor.

Pasos de comprobación

1. Revisa el código del formulario y confirma que el atributo enctype="multipart/form-data" está presente.
2. En el panel de PHP, verifica upload_max_filesize y post_max_size; aumenta los valores si es necesario.
3. Añade una validación del tamaño del archivo en el lado cliente (JavaScript) para evitar envíos que el servidor rechace.
4. Prueba enviando un archivo de tamaño justo por debajo del límite para confirmar la correcta recepción.

---

Resumen de los pasos clave

1. DNS y MX: asegúrate de que los registros apunten al servidor correcto y tengan SPF/DKIM configurados.
2. Filtros antispam: revisa listas negras y añade remitentes a la lista blanca.
3. Logs y errores del script: habilita WP_DEBUG o revisa los logs del servidor para detectar fallos silenciosos.
4. Compatibilidad de plugins/tema: descarta conflictos tras actual