WordPress no envía correos: cómo encontrar el fallo

«WordPress no envía correos» puede significar dos cosas distintas: la web no generó el mensaje o el servidor lo aceptó pero no llegó al destinatario. Averigua en qué tramo se pierde antes de instalar otro plugin SMTP, cambiar DNS o reenviar avisos de pedido que podrían duplicarse.

Si el fallo afecta solo a avisos de compra, empieza por el diagnóstico de correos de pedidos de WooCommerce: primero hay que confirmar el estado y evento del pedido. Si el mensaje salió pero va a spam, revisa entregabilidad y cabeceras, no solo el plugin.

Localiza el primer fallo

1. Elige un evento de prueba sin datos de clientes, como un formulario propio, y anota hora, destinatario y tipo de mensaje. Comprueba que el formulario realmente terminó y que su configuración apunta al buzón correcto.
2. Revisa los registros de WordPress, del plugin de correo si existe y del proveedor de envío. La función wp_mail() puede devolver éxito sin demostrar entrega; un correo registrado como procesado aún puede ser rechazado después.
3. Prueba el transporte autorizado: credenciales, puerto, cifrado y remitente permitido por tu proveedor. No publiques claves en una captura ni cambies a SMTP sin saber si la web usa una API de correo transaccional.
4. Si el proveedor indica entrega, revisa rebotes, cuarentena y carpeta de spam del destino. Valida con quien administra DNS la alineación del dominio remitente y sus registros SPF, DKIM y, cuando corresponda, DMARC.

Distingue correo normal y avisos de tienda

Una prueba SMTP correcta no demuestra que el aviso de pedido se haya creado. En WooCommerce verifica el estado del pedido, la configuración del correo concreto y las acciones programadas relevantes. Si hay una cola atrasada, averigua por qué antes de ejecutarla en masa: podría enviar notificaciones tardías o duplicadas. Nunca crees pedidos reales solo para probar la entrega; usa staging y el entorno de pruebas del proveedor de pagos.

Ejemplo: los correos de recuperación de contraseña llegan, pero los de compra no. Eso orienta hacia el evento o plantilla de WooCommerce, no hacia un fallo general de DNS. En el caso contrario, todos los eventos quedan registrados pero el proveedor rechaza el remitente: revisa autenticación y política de envío con ese proveedor.

Cómo cerrar la incidencia

Envía pruebas a dos dominios controlados, inspecciona sus cabeceras y registra resultado y hora. Comprueba el formulario y un flujo de compra de prueba si tu tienda lo permite. Mantén un registro mínimo sin conservar contenido sensible más tiempo del necesario. La guía antigua sobre configurar WP Mail SMTP sirve para conocer esa herramienta, pero no sustituye este diagnóstico por etapas. Si además has cambiado de proveedor, consulta cómo preservar el correo durante la migración. Al solicitar soporte indica qué evento falla y qué registró cada capa, sin compartir contraseñas.

Si solo falla la notificación de un formulario

Envía una prueba con datos ficticios y comprueba primero si el formulario guarda la entrada. Si no la guarda, el problema puede estar en validación, JavaScript, captcha, permisos o una petición bloqueada, antes de llegar al correo. Si guarda la entrada pero no genera mensaje, revisa la acción de notificación, destinatario, condiciones y errores del plugin. Si el mensaje se genera pero el proveedor no lo acepta, examina remitente, transporte, autenticación y límites. Evita poner la dirección del visitante en «De» cuando no controlas ese dominio; usa un remitente autorizado y, si corresponde, su dirección como respuesta.

Ejemplo: tras cambiar una regla antispam, el formulario muestra «enviado» pero no hay entrada ni petición de correo. Cambiar el MX no arreglaría esa validación. Otro caso: la entrada se guarda, el proveedor acepta el mensaje y el destinatario lo encuentra en cuarentena; ya no es un fallo del formulario. Comprueba dos receptores, registra los tres pasos y solo después modifica la capa concreta. Para separar el servicio web del buzón de empleados, consulta la arquitectura de correo.