Una migración puede cambiar el servidor que envía correo de la aplicación sin mover los buzones. WordPress puede informar éxito mientras el nuevo hosting bloquea conexiones, usa una IP no autorizada o conserva SMTP de staging. Separa los mensajes generados por la web de la recepción del correo.
Define qué ha dejado de funcionar
Prueba una ruta concreta: restablecimiento, formulario o aviso administrativo. Registra hora, destinatario, remitente, resultado y message ID. Pregunta si el correo normal entre buzones también falla.
Si solo fallan notificaciones de WordPress, no cambies MX. Los MX controlan la recepción, no configuran el envío de la aplicación.
Dibuja la arquitectura prevista
Documenta quién aloja los buzones y cómo debe enviar WordPress: SMTP externo autenticado, buzón del hosting, proveedor transaccional o servidor local. Anota host, puerto, cifrado, usuario y dominio From sin copiar contraseñas al ticket.
La migración debe tratar DNS entrante y envío de aplicación como trabajos separados.
Revisa la configuración activa
Inspecciona el plugin SMTP, constantes y variables de entorno. Una copia puede conservar remitente de staging, envío deshabilitado o credenciales cifradas para otro servidor.
Envía una prueba instrumentada y lee el error:
Connection timed out -> red, firewall o puerto
Authentication failed -> credenciales o política
Sender rejected -> identidad From no autorizada
Accepted con message ID -> investigar entrega posteriorNo publiques transcripciones SMTP completas: pueden incluir autenticación.
Verifica la conectividad saliente
Algunos hostings compartidos bloquean el puerto 25 o SMTP externo salvo relays aprobados. Prueba el hostname y puerto desde el servidor nuevo, incluida resolución DNS y negociación TLS. Lo habitual es 587 con STARTTLS o 465 con TLS implícito, según el proveedor.
No desactives la validación del certificado. Corrige nombre, cadena de confianza u hora del sistema.
Vuelve a autorizar el entorno
El proveedor puede restringir por IP, región, contraseña de aplicación, redirect OAuth o política. Actualiza allowlists y retira la IP antigua después del periodo de rollback.
El From visible debe estar permitido por la cuenta autenticada. Usa Reply-To para el visitante; suplantarlo en From perjudica SPF, DKIM y DMARC.
Audita DNS sin dañar la recepción
Revisa SPF, DKIM y DMARC autoritativos para el servicio que realmente envía. Debe existir un único SPF consolidado, no varios TXT competidores. Activa DKIM desde el proveedor que firma.
Conserva MX y verificaciones del proveedor de buzones salvo que el servicio de correo también se esté migrando.
Sigue el mensaje después de WordPress
«Accepted» solo significa que el siguiente servidor asumió la responsabilidad, no que llegó a la bandeja. Busca el message ID en el proveedor: entregado, diferido, rebotado, suprimido o rechazado.
Revisa cuarentena y listas de supresión. En una muestra entregada, comprueba resultados SPF, DKIM y DMARC en las cabeceras.
Comprueba además el remitente del sobre o Return-Path: puede diferir del From visible y es el que recibe los rebotes. Debe pertenecer a un dominio autorizado por el proveedor y alinearse con la política DMARC cuando corresponda.
Prueba todos los destinatarios operativos
Ensaya el dominio del propietario y un buzón externo. Valida resets, avisos de formulario, confirmaciones de usuario, seguridad y backups. Retira pruebas de analítica o colas cuando proceda.
Comprueba que colas cron antiguas no liberen duplicados. Informes programados pueden usar otra ruta distinta del plugin probado.
Evita otro fallo silencioso
Guarda un esquema no secreto del correo junto a la documentación del hosting. La monitorización debe enviar un mensaje controlado, verificar aceptación y alertar por autenticación o supresión.
Controla cambios de dominio y DKIM y caducidad de credenciales. El correo fiable se demuestra con una entrega rastreable, no con un aviso verde de WordPress.