Respuesta breve: por defecto WordPress entrega el correo a la función básica mail() del servidor, sin autenticación detrás. Los proveedores modernos la rechazan cada vez más, así que los mensajes se descartan en silencio o acaban en spam en lugar de rebotar de forma visible.
Por qué el fallo es silencioso
Rara vez hay un error en pantalla. WordPress da el mensaje por enviado porque lo entregó correctamente; lo que ocurrió después le resulta invisible. Por eso aflora de forma indirecta: un cliente nunca recibió su comprobante, o no puedes recibir un restablecimiento cuando estás bloqueado.
Diagnostícalo en minutos
- Instala un plugin de registro de correo, o envía una prueba a dos proveedores distintos (una de Gmail y otra de Outlook). Que llegue a uno y no al otro es un problema de autenticación, no un fallo de WordPress.
- Inspecciona las cabeceras de un mensaje que sí llegó para ver cómo se autenticó (busca
spf=passydkim=pass). - Comprueba la dirección de remitente y la alineación de su dominio.
La solución duradera: SMTP autenticado
Envía a través de un servicio autenticado en lugar de mail(): el SMTP de tu proveedor o un servicio transaccional dedicado. Configura host, puerto (587 con TLS, o 465 con SSL), usuario y contraseña, y usa una dirección de remitente en un dominio que controles. Después publica y alinea los registros DNS SPF y DKIM de ese dominio, y un registro DMARC. Es mucho más fiable que ajustar opciones de WordPress mientras falta la autenticación de fondo.
Verifica lo que depende del negocio
Prueba los mensajes que importan —restablecimiento, confirmación de pedido, aviso de formulario y alertas de administración— y confirma que cada uno llega a la bandeja de entrada y no a spam. Comprueba que la dirección de respuesta va a algún sitio donde la lea una persona.
CRITERIO DE INCIDENTE WP REPAIR
Cómo acotar el fallo sin adivinar
WordPress puede entregar correctamente un mensaje a la función local y que el destinatario nunca lo reciba. Hay que separar generación, transporte, autenticación y entrega final.
Registra el mensaje generado, remitente, reply-to y destinatario.
Envía pruebas controladas a más de un proveedor de correo.
Inspecciona cabeceras por alineación SPF, DKIM y DMARC.
Usa un proveedor transaccional autenticado y vigila rebotes o supresiones.
Qué debe quedar verificado
- Se generan mensajes de restablecimiento, formulario y pedido.
- La autenticación pasa para el dominio remitente.
- Llegan a varios proveedores y los rebotes son observables.
Fuentes técnicas oficiales
Esta guía explica el diagnóstico. Si la web está afectada ahora, la intervención debe preservar una vía de vuelta y verificar el recorrido real del negocio.
Ver el servicio de reparación urgente →