WordPress no envía formularios de Contact Form 7

Por qué Contact Form 7 deja de enviar en WordPress

Cuando Contact Form 7 no envía, el problema no suele estar solo en el formulario visible. El envío depende de varias capas: validación del propio plugin, función de correo de WordPress, configuración del servidor, autenticación del dominio, reputación del remitente y filtros del buzón receptor. Si una sola pieza falla, el mensaje puede no salir, quedarse en cola, rebotar o entregarse en spam.

En WordPress este tipo de incidencia encaja sobre todo en la deliverability de correo y en la integración entre plugin, hosting y DNS. En un entorno general, incluido el ámbito de España, es muy habitual que la web funcione bien y que el fallo solo aparezca al usar un remitente mal configurado, un servidor con restricciones para enviar correo o un registro SPF, DKIM o DMARC que no acompaña la configuración real.

• El formulario puede mostrar mensaje de éxito y aun así no llegar ningún correo.
• Un cambio de hosting, DNS o plugin de caché puede romper el envío sin afectar al resto de la web.
• La función nativa de correo del servidor puede estar limitada o no ser fiable para correo transaccional.
• Usar como remitente una dirección del visitante suele provocar rechazos o problemas de autenticación.
• La falta de pruebas guardadas complica identificar si el fallo es de WordPress, del servidor o del receptor.

Diagnóstico inicial y señales útiles

Antes de modificar nada conviene confirmar el síntoma exacto. No es lo mismo que Contact Form 7 muestre un borde rojo con error de configuración, que el formulario parezca enviarse y no llegue nada, o que solo fallen ciertos destinatarios. También importa saber si el problema empezó tras una actualización, una migración, un cambio de DNS, la activación de un plugin de seguridad o un ajuste en la versión de PHP.

Las comprobaciones iniciales deben ser prudentes para no empeorar la incidencia. Lo recomendable es hacer pruebas controladas, tomar capturas, anotar hora exacta de cada intento y revisar avisos del hosting, logs de correo y comportamiento por destinatario. Si hay picos de CPU, errores 500, alertas del proveedor, caídas intermitentes o mensajes de Search Console relacionados con malware o spam, pueden existir factores paralelos que afecten al envío.

• Comprobar si aparece un mensaje concreto de Contact Form 7, como error de configuración o fallo al intentar enviar.
• Realizar una prueba con un formulario sencillo y anotar fecha, hora, IP si es posible y destinatario usado.
• Revisar si el problema coincide con cambios recientes de plugins, tema, PHP, DNS o certificados SSL.
• Consultar avisos del hosting sobre límites de recursos, bloqueo de correo saliente o cuentas suspendidas.
• Evitar instalar varios plugins de SMTP, caché o seguridad a la vez durante el diagnóstico inicial.

Causas habituales y cómo confirmarlas

La causa más repetida es una configuración incorrecta del correo en la pestaña Mail de Contact Form 7. Destaca el uso del campo From con una dirección que no pertenece al dominio de la web o que no coincide con el servicio autorizado para enviar correo. También son frecuentes los problemas con la función wp_mail, restricciones del servidor, buzones mal configurados, registros DNS incompletos o filtros antispam del destinatario.

Para confirmar la causa hay que separar envío y entrega. Si WordPress no logra invocar el sistema de correo, el problema está en la salida. Si el mensaje sale pero no llega a la bandeja principal, la incidencia suele estar en autenticación, reputación o filtrado. Las pruebas útiles incluyen revisar cabeceras de mensajes recibidos, rebotes, logs del servidor y la coherencia entre dominio web, dirección remitente y servicio SMTP usado.

• El remitente del formulario no pertenece al dominio o no está autorizado por SPF y DKIM.
• La función wp_mail depende del servidor y este no permite enviar o lo hace con baja fiabilidad.
• El buzón destinatario existe, pero clasifica los mensajes en spam o los rechaza silenciosamente.
• Hay errores de sintaxis o campos mal mapeados en la configuración del formulario y del correo.
• Una migración o cambio de DNS dejó registros desactualizados, especialmente MX, SPF o DKIM.

Seguridad, malware y spam en formularios

No todos los fallos de envío tienen origen técnico limpio. A veces el formulario se usa para spam masivo, hay automatizaciones abusivas o incluso código inyectado que altera envíos, destinatarios o contenido. También puede ocurrir que credenciales filtradas de correo o de administrador desencadenen bloqueos por parte del proveedor, porque detecta actividad sospechosa desde la cuenta o desde la web.

Conviene abordar esta parte sin alarmismo, pero con método. Si aparecen usuarios desconocidos, redirecciones extrañas, alertas del navegador, envíos desde cuentas no previstas o formularios que generan volúmenes anómalos, hay que hacer copia, revisar usuarios, cambiar contraseñas, auditar plugins y comprobar permisos de archivos. El hardening básico y la limitación de superficie de ataque ayudan a que el problema no reaparezca.

• Revisar si existen plugins vulnerables, abandonados o innecesarios con acceso al correo o a formularios.
• Rotar contraseñas de WordPress, panel de hosting, bases de datos y cuentas de correo relacionadas.
• Comprobar usuarios administradores, tareas programadas y archivos modificados recientemente.
• Verificar permisos de archivos y evitar escrituras inseguras en carpetas sensibles del sitio.
• Aplicar medidas razonables como reCAPTCHA, honeypot, límites de envío y auditorías periódicas.

Rendimiento y estabilidad del envío

El correo de formularios también depende de la estabilidad general de WordPress. Si el servidor va justo de recursos, si PHP agota memoria, si hay procesos lentos o si una caché agresiva interfiere con scripts y validaciones, el formulario puede fallar de forma intermitente. En esos casos no siempre aparece un error claro para el visitante, lo que hace pensar que el problema es solo del plugin.

Cuando el fallo es aleatorio hay que revisar consumo de CPU, memoria, tiempos de respuesta y registros de errores. En formularios con archivos adjuntos, límites de tamaño, timeouts y restricciones del servidor toman más peso. Una web lenta o inestable tiende a perder trazabilidad: un envío puede caducar, no completar el proceso o registrarse de forma incompleta en el servidor.

• Revisar errores PHP, límites de memoria y tiempos máximos de ejecución en momentos de prueba.
• Comprobar si hay picos de CPU o saturación del plan de hosting cuando se envían formularios.
• Desactivar temporalmente optimizaciones agresivas que minifican o retrasan scripts del formulario.
• Verificar tamaño de adjuntos, restricciones de subida y comportamiento de la cola de correo.
• Monitorizar si el fallo es continuo o solo aparece en horas punta, tras caché o bajo carga.

Plugins, temas y actualizaciones

Los conflictos entre plugins son una causa clásica en WordPress y Contact Form 7 no es una excepción. Un plugin SMTP mal configurado, una optimización de JavaScript, un firewall de aplicaciones o funciones añadidas al tema pueden alterar validaciones, envío o respuesta del formulario. También puede influir una actualización de Contact Form 7, de WordPress core, de PHP o de un plugin que interactúa con el correo.

La buena práctica es probar cambios en staging, documentar versiones y mantener control de cambios. Si el fallo apareció tras actualizar, lo prudente es comparar versiones, revisar el changelog, aislar el conflicto desactivando de forma ordenada y validar después en un entorno seguro. Hacer cambios directos en producción sin copia previa aumenta el riesgo de dejar el sitio sin formulario y sin una referencia clara de qué rompió el envío.

• Usar un entorno de staging para probar actualizaciones de WordPress, Contact Form 7 y SMTP.
• Registrar qué plugin o ajuste se tocó, en qué fecha y con qué resultado visible.
• Desactivar conflictos de forma escalonada, no en bloque, para identificar la causa real.
• Evitar personalizaciones en functions.php sin trazabilidad ni copia reciente del sitio.
• Comprobar compatibilidades con la versión de PHP y con extensiones usadas por el hosting.

Hosting, dominio y correo en España

En España y en cualquier entorno similar, el comportamiento del correo depende mucho del proveedor y de la arquitectura contratada. Hay alojamientos donde el correo sale desde el propio servidor web y otros donde se exige un servicio SMTP externo o autenticado. También es frecuente que el dominio esté gestionado en un proveedor, el DNS en otro y el correo en un tercero, lo que aumenta los puntos donde una configuración incorrecta puede bloquear el envío.

En esta revisión deben entrar DNS, SSL, versión de PHP, límites de recursos, cachés de servidor y correo transaccional. Si el dominio no resuelve bien, si el certificado está mal instalado, si el servidor aplica restricciones a puertos de salida o si los registros SPF, DKIM y DMARC no reflejan el servicio real, los formularios pueden dejar de funcionar o perder entregabilidad. Como estas condiciones varían por proveedor, conviene validar cada ajuste con datos del entorno concreto.

• Comprobar que los registros DNS del dominio están propagados y alineados con el servicio de correo usado.
• Revisar SSL, redirecciones y posibles bloqueos de firewall que afecten a conexiones SMTP seguras.
• Validar la versión de PHP, módulos necesarios y límites de recursos del plan contratado.
• Confirmar si el hosting permite correo saliente local o exige SMTP autenticado para mejor entrega.
• Revisar caches de servidor, CDN y reglas de seguridad que puedan interferir con peticiones del formulario.

Pruebas, accesos y documentación técnica

Una incidencia de formularios se resuelve mejor cuando se reúnen accesos y evidencias antes de intervenir. No hace falta tocar todos los sistemas, pero sí saber qué se puede consultar: WordPress, panel del hosting, DNS, cuenta de correo, registros de errores y copia de seguridad reciente. La trazabilidad permite entender si el fallo es estructural o si comenzó en un momento muy concreto.

En un enfoque profesional conviene documentar tanto lo que falla como lo que sí funciona. Por ejemplo, si solo fallan ciertos formularios, ciertos dominios de destino o ciertos adjuntos, eso acota mucho el análisis. Además, guardar una exportación de ajustes y una cronología de cambios evita perder tiempo repitiendo pruebas o corrigiendo síntomas en lugar de la causa.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins activos, changelog interno y fecha de la última modificación relevante.
• Evidencias técnicas: logs PHP y del servidor, capturas de errores, URLs afectadas y hora exacta de cada prueba.
• Copias de seguridad disponibles, export de base de datos y posibilidad de restauración en staging antes de intervenir.
• Acceso a DNS, panel de hosting, buzón destinatario o rebotes para revisar autenticación y entrega.
• Informes de seguridad, lista de usuarios administradores y revisión de tareas programadas vinculadas al sitio.

Plan de acción ordenado

La forma más segura de resolver esta incidencia es seguir un orden que reduzca el impacto en producción. Primero se contiene el riesgo, después se preserva una copia, luego se diagnostica y solo entonces se corrige. Este enfoque evita cambios impulsivos que pueden ocultar la causa, romper otras funciones o dejar el sitio sin capacidad de volver atrás.

En formularios de contacto la prioridad suele ser recuperar un canal fiable de recepción sin comprometer la trazabilidad. Si el negocio depende del contacto web, puede habilitarse una solución temporal controlada, pero sin abandonar el análisis del origen. Tras corregir, se debe verificar por escenarios, registrar el resultado y mantener monitorización durante los días siguientes.

• Contener el problema y evitar cambios simultáneos en varios plugins o servicios de correo.
• Crear copia de archivos y base de datos antes de modificar ajustes de formulario, SMTP o DNS.
• Diagnosticar el punto de fallo: configuración del formulario, envío desde WordPress, servidor o entrega final.
• Aplicar la corrección mínima necesaria y probar con distintos destinatarios y casos reales de uso.
• Monitorizar resultados, guardar evidencia de éxito o fallo y programar revisión posterior del entorno.

Si ya se ha tocado algo o hay urgencia

Es habitual llegar a esta incidencia cuando ya se han hecho varios intentos: instalar un plugin de seguridad, restaurar una copia parcial, cambiar de hosting, editar functions.php, borrar un plugin crítico o probar una limpieza improvisada. En ese punto conviene frenar y reconstruir la secuencia de hechos, porque un arreglo apresurado puede haber eliminado pistas importantes o generado un segundo problema adicional.

Si hay urgencia comercial, lo razonable es habilitar una medida provisional controlada, pero preservando evidencia técnica. No conviene sobrescribir logs, reinstalar todo sin análisis o restaurar copias a ciegas en producción. Si ya se tocó correo, DNS o código, debe anotarse exactamente qué cambió, qué se esperaba conseguir y qué resultado produjo, para no seguir amplificando el tiempo de caída.

• Si se instaló un plugin de seguridad, revisar si está bloqueando envíos, scripts o conexiones SMTP legítimas.
• Si se restauró una copia parcial, comprobar desajustes entre archivos, base de datos, DNS y credenciales actuales.
• Si se cambió de hosting, validar que correo, certificados, DNS y versión de PHP quedaron alineados.
• Si se editó functions.php o se borró un plugin crítico, revisar errores fatales y dependencias rotas antes de seguir.
• Si se intentó limpiar malware sin copia, preservar el estado actual y recopilar evidencia antes de sobrescribirlo todo.

Preguntas frecuentes

Estas dudas suelen repetirse cuando Contact Form 7 deja de enviar y no hay un error evidente. La clave es separar configuración del formulario, salida del correo y entrega final.

P: Si el formulario muestra mensaje de enviado, ¿significa que el correo ha llegado?

R: No necesariamente. Puede haberse completado la acción en WordPress y aun así fallar la salida del correo o su entrega al destinatario.

P: ¿Es buena idea usar como remitente el correo que escribe el visitante?

R: En general no. Lo más estable es usar una dirección del propio dominio como remitente y dejar el correo del visitante en Reply-To.

P: ¿Necesito SMTP para que Contact Form 7 funcione?

R: No siempre, pero suele mejorar la fiabilidad y la trazabilidad frente al envío nativo del servidor, según el entorno concreto.

P: ¿Puedo probar en producción sin riesgo?

R: Sí, si las pruebas son controladas, con copia previa, pocos cambios y registro de hora, destinatario y resultado. Para cambios mayores, es preferible staging.

P: ¿Un problema de DNS puede afectar aunque la web cargue bien?

R: Sí. La web puede resolver correctamente y, al mismo tiempo, el correo estar mal autenticado o dirigido a un servicio distinto por registros DNS incompletos o desactualizados.