Si WordPress acepta el formulario pero el correo no llega, sigue todo el recorrido: evento de la aplicación, llamada a wp_mail(), transporte configurado, proveedor de envío y servidor del destinatario. El mensaje de éxito del formulario no confirma la recepción en el buzón. Empieza con una prueba controlada y localiza la primera etapa sin confirmación antes de cambiar plugins o registros DNS.
Cómo saber qué correos de WordPress no se envían
Anota el proceso afectado, destinatario de prueba, hora con zona horaria y última entrega correcta conocida. Un formulario, el restablecimiento de contraseña y la confirmación de pedido pueden tener ajustes diferentes en la misma instalación. Si solo falla un correo de WooCommerce, cambiar el SMTP global puede perjudicar otros mensajes sin reparar el evento de pedido que no llegó a ejecutarse.
Comprueba primero que la aplicación intenta enviar. Un formulario puede validar y guardar datos con la acción de notificación desactivada. El aviso del proveedor de pagos puede llegar después de cerrar el navegador. Un pedido puede permanecer en un estado que no activa la plantilla esperada. Compara el registro del proceso con sus ajustes antes de interpretar la ausencia de correo como un problema de autenticación de dominio.
Contrasta la prueba del transporte con la acción real. El botón de prueba del plugin suele usar un mensaje sencillo que no pasa por todos los campos, estados de pedido y hooks personalizados. Si esa prueba llega pero el formulario no genera notificación, investiga la aplicación. Si ambos fallan con el mismo error de conexión, el siguiente paso está en el transporte, no en el diseño del formulario.
La referencia de wp_mail() distingue el resultado de la función de la recepción del destinatario. Una devolución positiva no garantiza que el correo haya llegado. Registra creación, aceptación por el proveedor y recepción como observaciones diferentes. Un estado verde de la aplicación puede preceder a un rechazo posterior en el servidor de destino.
Usa un buzón controlado por el equipo y una referencia reconocible en el asunto. No envíes pedidos de prueba a clientes ni incluyas datos personales reales en muestras. En staging, comprueba primero las reglas de destinatarios. Una copia de la base de producción puede contener direcciones que no deben recibir ninguna notificación del entorno de pruebas, aunque el contenido parezca inofensivo.
Qué plugin SMTP y servicio de correo elegir para WordPress
FluentSMTP y WP Mail SMTP son ejemplos de plugins que conectan WordPress con un servicio de correo. El plugin no es un buzón ni proporciona por sí mismo una cuota mensual de mensajes. La cuenta del proveedor determina límites, dominios autorizados y retención. Verifica la integración disponible en la versión instalada y el método de autenticación que exige el servicio. Una comparativa antigua de planes no describe necesariamente la cuenta actual.
Mantén un único componente responsable del transporte. Dos plugins pueden modificar PHPMailer o interceptar wp_mail() y sobrescribir remitentes o credenciales. Revisa también plugins obligatorios, código del tema y ajustes del alojamiento. Antes de desactivar una integración, documenta sus valores y los procesos que dependen de ella. Un cambio global necesita una forma conocida de recuperar la configuración anterior.
SMTP autenticado puede servir para mensajes transaccionales. Una API HTTP puede facilitar respuestas estructuradas e identificadores de eventos. Ninguna opción garantiza la bandeja de entrada, y una API tampoco es automáticamente instantánea ni ajena a las cuotas. Compara autenticación, registros de entrega, rotación de credenciales y tratamiento de errores. El equipo debe poder rastrear un mensaje concreto, además de ver un resultado general de envío.
Cómo configurar el puerto SMTP, TLS y las credenciales en WordPress
Obtén del proveedor el servidor, puerto, cifrado y método de autenticación. El puerto 465 suele usar TLS desde el inicio; el 587 suele utilizar STARTTLS. Sigue la combinación indicada para ese servicio. No mezcles opciones hasta conseguir una prueba verde por casualidad. Un error de certificado requiere corregir el nombre del servidor o la cadena de confianza, no desactivar la verificación TLS.
Crea credenciales para la tarea de envío del sitio cuando el proveedor permita limitar permisos. Evita compartir la contraseña cotidiana de una persona entre producción, staging y desarrollo local. Si el plugin permite guardar secretos fuera de la base de datos, utiliza su mecanismo documentado. Una constante de PHP copiada de otra integración no empieza a funcionar porque su nombre resulte convincente.
Las copias de base de datos, exportaciones y paquetes de soporte pueden contener credenciales y cuerpos de mensajes. Limita el acceso administrativo, elimina secretos de capturas y comprueba qué valores se ocultan al exportar. Rota una clave que haya aparecido en un repositorio o una incidencia compartida. Borrar el texto visible no revoca el acceso de quien ya lo copió.
Staging necesita una política de envío propia. Usa otra cuenta o un servicio que capture mensajes y bloquee los destinatarios de producción. Tras publicar cambios, confirma la fuente de las credenciales y del remitente. Importar una base de pruebas sobre producción puede sustituir la cuenta de envío aunque el dominio y sus registros DNS permanezcan intactos.
Qué diferencia hay entre el remitente, el Return-Path y la firma DKIM
La dirección de From, el remitente del sobre utilizado para devoluciones y el dominio de firma DKIM son identidades diferentes. SPF evalúa la infraestructura autorizada para el dominio del sobre. DKIM verifica una firma para su dominio firmante. DMARC comprueba la alineación con el dominio visible. Un resultado válido y alineado de SPF o DKIM puede cumplir DMARC; el fallo de uno no implica por sí solo el fallo de DMARC.
Usa una dirección de un dominio que controle la organización y que el proveedor haya verificado. Pon la dirección validada del visitante en Reply-To. El sitio no controla las políticas de los dominios de sus visitantes y no puede enviar legítimamente como cualquiera de ellos. Utilizar al visitante en From hace que cada formulario dependa de una política externa diferente.
En Contact Form 7, revisa que las etiquetas de correo correspondan a los campos reales según la documentación de configuración. Comprueba que responder envía al visitante y que el remitente de la organización permanece estable. La notificación interna y la confirmación al visitante son dos mensajes distintos. Prueba ambos: una etiqueta ausente puede estropear solo uno de ellos.
Cómo configurar SPF, DKIM y DMARC para WordPress
Antes de modificar SPF, enumera el sitio, los buzones del equipo, la plataforma de facturación y el servicio de campañas. Publica un único registro SPF por nombre de dominio pertinente y combina mecanismos siguiendo las instrucciones de los proveedores. Añadir otro registro v=spf1 junto al existente no combina correctamente autorizaciones. Puede invalidar la evaluación y afectar correos que antes se entregaban.
La especificación SPF limita también la evaluación que depende de consultas DNS. Añadir includes indefinidamente puede producir errores aunque cada servicio sea legítimo. Retira emisores antiguos y pide al responsable del dominio que revise la composición completa. No copies un ejemplo que autorice un alojamiento ajeno o use una dirección de informes que la organización no controla.
Copia los nombres y valores DKIM del proveedor. Puede solicitar registros TXT o CNAME hacia claves administradas. El selector no tiene que llamarse default. Algunos paneles añaden automáticamente el dominio y otros esperan el nombre completo. Verifica el nombre publicado tras guardar. Un sufijo duplicado puede parecer correcto en la interfaz y, aun así, impedir que el destinatario encuentre la clave.
Empieza DMARC con observación cuando todavía no conoces todos los emisores legítimos. Lee informes agregados y confirma alineación antes de aplicar cuarentena o rechazo. Una política estricta afecta también facturas y correos del equipo. La especificación DMARC explica autenticación, alineación y política. Los paneles ayudan a interpretar informes, pero no sustituyen la consulta de los registros publicados.
Si SPF y DKIM muestran pass y DMARC falla de todos modos, las comprobaciones se han superado para dominios distintos del remitente visible. Abre el código fuente de un mensaje recibido (en Gmail: Mostrar original) y compara los dominios de la cabecera Authentication-Results: smtp.mailfrom para SPF, header.i o header.d para DKIM y header.from para la dirección que ve el destinatario. Si ninguno de los dos primeros comparte el dominio organizativo de header.from, DMARC no tiene ningún resultado alineado que aceptar. La guía de Mailfully SPF, DKIM and DMARC setup, step by step, de octubre de 2026, añade dos comprobaciones que conviene hacer a la vez. En Cloudflare, deja los registros CNAME de DKIM en DNS only (nube gris): la documentación de Cloudflare sobre el estado del proxy incluye los registros de correo entre los que su proxy HTTP no admite. Un subdominio de envío sin registro _dmarc propio recurre al registro del dominio organizativo, que puede fijar una política para subdominios con sp= (RFC 7489, sección 6.6.3). Comprueba qué hereda ya el subdominio antes de publicar en él un p=none más débil.
Guarda el valor anterior, el nuevo, la persona responsable y el resultado de verificación. Los caches DNS hacen que una actualización en el panel no pruebe visibilidad inmediata en todos los resolvers. Consulta respuestas autoritativas y repite la prueba tras la propagación. Si necesitas revertir, podrás restaurar un estado documentado en lugar de reconstruirlo de memoria.
Qué significan los errores SMTP en WordPress y dónde buscar la causa
| Observación | Primera comprobación |
|---|---|
| No existe evento de envío | Acción del formulario, estado de pedido, plantilla y hooks |
| La conexión agota el tiempo | Firewall de salida, servidor, puerto y disponibilidad |
| Autenticación rechazada | Credencial, método permitido y estado de cuenta |
| Aceptación sin recepción | Entrega, devolución, supresión y filtros del buzón |
| Recepción con contenido incorrecto | Plantilla, codificación, enlaces y adjuntos |
Un timeout sucede antes del filtro antispam del destinatario. Prueba desde el entorno que ejecuta WordPress. Que un portátil conecte no demuestra que el alojamiento permita el mismo puerto. Registra código de error y duración sin almacenar el intercambio de autenticación. Si la red es la primera capa que falla, consulta con el operador las reglas de conexión saliente.
Un rechazo de autenticación requiere revisar la cuenta del proveedor. La clave puede haberse rotado, la política puede exigir OAuth o la cuenta puede estar restringida. Repetir intentos con la misma credencial inválida añade ruido. Corrige la causa, haz una prueba controlada y vuelve al proceso original. No cambies DNS, contraseña y plantilla simultáneamente sin un diagnóstico que justifique cada acción.
Si el proveedor aceptó, busca eventos posteriores con hora, destinatario e identificador. El correo todavía puede aplazarse, rechazarse o quedar suprimido. Un evento de entrega suele indicar aceptación por el servidor del destinatario, no lectura por una persona. Cuando encuentres el mensaje, examina los encabezados recibidos y sus resultados de autenticación, además del resumen del panel.
Cómo reenviar correos fallidos sin duplicar pedidos
Distingue errores temporales y permanentes mediante los códigos documentados del servicio. Una indisponibilidad temporal puede justificar reintentos limitados. Una dirección inválida o una supresión tras devolución permanente requiere corregir la causa. Define el máximo de intentos y una alerta al agotarlos. Una cola que insiste indefinidamente con el mismo destinatario inexistente no recupera la comunicación.
Un timeout puede dejar un estado incierto: el proveedor aceptó la solicitud antes de que WordPress perdiera la respuesta. Reenviar inmediatamente puede duplicar mensajes. Relaciona cada intento con el evento de negocio, conserva el identificador del servicio y comprueba si la API ofrece idempotencia. Cambiar de plugin no elimina automáticamente mensajes pendientes en la cola anterior.
En WooCommerce, el pedido sigue siendo la referencia para preparar la venta. La falta de correo no debe borrar el pedido, y repetir una notificación no debe cobrar otra vez. Comprueba estado, destinatario y tipo de mensaje antes de reenviar manualmente. Acuerda quién recupera los avisos críticos. Así puedes reparar la comunicación sin alterar accidentalmente el pago o la preparación del envío.
Si el transporte utiliza tareas de fondo, monitoriza la cola como componente separado. Una conexión SMTP funcional no ayuda a un trabajo que nunca se ejecuta. Revisa el programador, tareas bloqueadas y proceso responsable. Antes de reemplazar envío síncrono por una cola propia, define reintentos, retención y observabilidad. La cola introduce otra dependencia operativa que también necesita diagnóstico.
Qué guardar en los registros de correo y quién debe recibir las alertas
Guarda proceso, identificador de operación, hora, identificador del proveedor y estado. El cuerpo completo rara vez es necesario para demostrar entrega. Enlaces de restablecimiento, direcciones y detalles de pedido necesitan acceso y retención más restrictivos que una línea de estado. Comprueba que el borrado también cubre copias de seguridad. Vaciar el registro del plugin no elimina una exportación adjunta a una incidencia.
Configura alertas para patrones que requieren actuación, como fallos repetidos de autenticación o un flujo crítico detenido. Una prueba sintética periódica detecta problemas de transporte, pero no todos los estados de pedido. Añade pruebas del flujo real y asigna una persona responsable. El canal de alerta debe ser independiente del transporte examinado para que la avería no bloquee su propia notificación.
Cuando Gmail sea un destino importante, consulta sus directrices para remitentes. Los requisitos cambian entre emisores comunes y emisores en volumen; las comunicaciones promocionales tienen condiciones adicionales. Una confirmación transaccional no es automáticamente un boletín. Autenticar el dominio tampoco obliga al destinatario a aceptar contenido que no desea recibir.
Por qué no llegan las consultas del formulario aunque el correo se envía
La configuración SMTP puede estar perfecta y, aun así, las consultas se pierden. En julio de 2026, un desarrollador web contó en el foro r/Wordpress cómo perdió un cliente por las notificaciones de un formulario. Tras la llamada de una persona cuyo mensaje no había llegado, revisó los envíos guardados, el registro del formulario, el registro del plugin SMTP y el panel del servicio de envío: todo se había enviado y entregado. La causa era otra:
Ahí descubro que el empleado que recibía esos correos se había ido hace tres meses.
(traducción propia, r/Wordpress, hilo del 24 de julio de 2026)
En el mismo hilo añadió que ninguna protección en el DNS habría servido aquí, porque las consultas llegaban, solo que a un buzón que ya no existía (traducción propia, r/Wordpress).
A qué dirección deben llegar los mensajes del formulario de contacto
El consejo más repetido en el hilo es una dirección de la empresa y no de una persona, por ejemplo un grupo o un alias con al menos dos destinatarios que gestione el propio cliente (traducción propia, r/Wordpress). Otra agencia añade una segunda notificación a un buzón compartido al que acceden varias personas, como reserva para los cambios en el equipo (traducción propia, r/Wordpress). En WordPress, eso significa dos direcciones en los ajustes de notificación del formulario en lugar de una.
Cómo comprobar si funciona el formulario de contacto de WordPress
El registro del plugin SMTP solo confirma que el mensaje salió del servidor. El recorrido completo se comprueba con un envío de prueba por el formulario a intervalos fijos, por ejemplo una vez a la semana, aunque, como señala el autor del consejo, esa prueba no dice si alguien leyó la consulta real (traducción propia, r/Wordpress). El segundo método del hilo es un resumen mensual de todos los envíos del formulario, comparado con el mes anterior y enviado al cliente (traducción propia, r/Wordpress). El resumen muestra consultas que entraron, pero que nadie respondió.
Bastan SPF, DKIM y DMARC para que lleguen los correos del formulario
No. Los registros DNS descritos arriba deciden si el buzón del destinatario acepta el mensaje, pero no saben si alguien lee ese buzón. Los participantes del hilo mencionan las dos causas juntas: filtros antispam cada vez más estrictos y cambios, por parte del cliente, en quién debe recibir los correos (traducción propia, r/Wordpress).
Qué hacer cuando se va el empleado que recibía las consultas
Añade la dirección que recibe las notificaciones a la lista de comprobación para la salida de un empleado, junto a cuentas, contraseñas y accesos. En el traspaso del sitio conviene anotar quién recibe los envíos, quién es el suplente y quién debe avisar al responsable del sitio cuando alguna de esas personas se va (traducción propia, r/Wordpress). Si el formulario guarda los envíos en la base de datos, revisa después de ese cambio si hay consultas sin atender de las últimas semanas esperando en el panel.
Cómo comprobar el envío de correo de WordPress tras la reparación
Prueba el transporte, envía el formulario, solicita un restablecimiento desde una cuenta de pruebas y crea un pedido autorizado si hay comercio electrónico. Incluye el dominio que fallaba y otro destino independiente. Registra creación, aceptación y recepción para cada mensaje. Comprueba además respuesta, presentación móvil, enlaces, adjuntos y resultados de autenticación en la copia recibida.
En una tienda que atiende España y otros países, prueba también los caracteres y textos de cada plantilla activa. Un asunto con tildes o un nombre de producto traducido puede mostrar un problema de codificación que no aparece en la prueba genérica. Verifica que el enlace del correo conserva el idioma y el dominio de producción. La recepción correcta no basta si dirige al comprador hacia una página de staging.
Retira instrumentación temporal, revoca claves de diagnóstico y conserva un procedimiento con responsables del servicio y del DNS. Repite la revisión tras migrar alojamiento, cambiar remitente o rotar credenciales. Para desarrollo y mantenimiento de WordPress, envía por escrito el proceso afectado, la hora aproximada y el error sin credenciales ni información personal de clientes.
