Un resultado true de wp_mail() significa que WordPress entregó el mensaje a su mailer configurado sin un error inmediato. No significa que el servidor SMTP lo aceptara, el gateway destinatario lo entregara o el usuario lo viera.
Conserva ese resultado como un control y continúa siguiendo el mismo mensaje.
Crea una prueba rastreable
Usa un destinatario sintético bajo tu control, una referencia única en el asunto y ningún dato personal. Anota hora, entorno y ruta de código que llamó a wp_mail().
Prueba la acción real del formulario o aplicación además de la pantalla de test del plugin. Esta puede utilizar cabeceras, destinatario y momento de ejecución distintos.
Evita bucles de pruebas: los límites de envío pueden ocultar el problema original.
Interpreta correctamente el valor
WordPress construye el mensaje con PHPMailer y aplica hooks antes de intentar la entrega. El booleano true indica que no se notificó un fallo síncrono en esa etapa.
Con PHP mail local, el sistema operativo puede aceptar el mensaje en una cola que lo rechace después. Con SMTP, un plugin puede registrar la conexión y respuesta del proveedor.
El valor no describe filtrado antispam, cuarentena ni un rebote posterior.
Captura fallos de forma segura
Durante un diagnóstico breve, un desarrollador puede registrar solo código y mensaje del hook wp_mail_failed. No guardes todos los datos del correo en producción: podrían incluir destinatarios, contenido y adjuntos.
add_action('wp_mail_failed', function (WP_Error $error): void {
error_log(
'WordPress mail failure: ' .
sanitize_text_field($error->get_error_code()) . ' | ' .
sanitize_text_field($error->get_error_message())
);
});Coloca el código temporal en un mecanismo de desarrollo apropiado, conserva una reversión y retíralo al terminar. Mantén los logs fuera del acceso público.
Identifica el transporte activo
Determina si el sitio usa PHP mail, sendmail, relay del hosting, SMTP o una API transaccional. Revisa el plugin activo y la configuración real; instalar un plugin SMTP no garantiza que controle todos los mensajes.
Comprueba From, Return-Path y dominio de envío. Usa un remitente autenticado del dominio y al visitante en Reply-To.
Con correo local, consulta la cola y el registro de entrega de cPanel o Plesk con acceso autorizado.
Busca el mensaje en el proveedor
Localiza la referencia en la actividad SMTP o transaccional. Anota si fue aceptado, aplazado, rebotado, rechazado o suprimido, junto con el message ID.
Si no aparece, no alcanzó ese proveedor pese al resultado de WordPress; inspecciona enrutamiento, colas locales y qué plugin posee el envío.
Si fue rechazado, utiliza el código exacto para reparar credenciales, autorización del remitente, límites o destinatario.
Revisa autenticación y rebotes
Comprueba SPF, DKIM y DMARC para el proveedor y From reales. El registro A del sitio no autoriza email y los MX normalmente controlan el correo entrante.
Monitoriza el Return-Path autenticado para detectar informes de no entrega. Algunos llegan cuando la petición PHP ya terminó y no pueden cambiar el booleano anterior.
No crees un segundo SPF ni publiques claves DKIM privadas.
Sigue el gateway destinatario
Tras la aceptación, pide al administrador autorizado buscar por message ID, hora, remitente y destinatario. Revisa cuarentena, reglas, alias, grupos y cuota.
Probar solo Gmail no basta cuando el receptor real utiliza Microsoft 365, Google Workspace u otro gateway corporativo.
Inspecciona las cabeceras completas de una copia entregada sin publicar direcciones personales.
Verifica la entrega completa
Después de reparar el traspaso identificado, ejecuta la acción real una vez con una referencia nueva. Confirma resultado de wp_mail(), aceptación local o externa, autenticación y llegada final.
Prueba Reply-To, adjuntos y destinatarios condicionales. Mantén un log protegido o alertas del proveedor proporcionales al volumen.
Solicita reparación urgente cuando discrepen logs locales y externos, no estén claros los rebotes o los leads sean críticos. Comparte horas y códigos redactados; nunca credenciales o cuerpos.