Una migración puede dejar todas las páginas correctas mientras las notificaciones fallan silenciosamente. La web, DNS, PHP y la ruta de correo son sistemas distintos; una migración visualmente correcta no demuestra que el email se trasladara.
Empieza con un envío controlado y localiza el primer salto diferente del servidor anterior.
Confirma que el formulario procesa la entrada
Envía datos no sensibles y etiquetados. Anota hora, página y destinatario. Comprueba si el plugin guarda una entrada. Si no, inspecciona la petición y el log PHP nuevo antes de investigar la entrega.
Si existe entrada, el recorrido navegador-WordPress probablemente funcionó. Continúa por generación, wp_mail, SMTP y buzón. Cambia una sola variable por prueba.
Compara la ruta antigua y la nueva
Determina cómo enviaba la instalación anterior: PHP mail local, plugin SMTP, relay del hosting o proveedor transaccional. Registra el método activo nuevo sin asumir que se copió.
Confirma que el plugin sigue activo y sus ajustes sobrevivieron al search-replace. Contraseñas o API keys cifradas con valores del entorno anterior pueden tener que introducirse de nuevo.
Prueba el email propio del plugin y también el formulario real, porque la prueba genérica puede saltarse condiciones y cabeceras.
Comprueba remitentes y credenciales
Usa un From autorizado por el proveedor y deja el email del visitante en Reply-To. Un proveedor moderno puede rechazar la suplantación de un dominio externo.
Verifica hostname, puerto, cifrado, usuario y credencial. Confirma que el servidor nuevo conecta al puerto; algunos hostings bloquean SMTP externo o exigen su relay.
No desactives certificados ni publiques secretos.
Resuelve el hostname SMTP desde el propio servidor y comprueba IPv4 e IPv6. Una ruta AAAA rota o un DNS distinto en el hosting puede causar timeouts aunque el mismo nombre funcione desde tu ordenador.
Audita DNS sin romper el correo entrante
El A web y los registros de correo pueden apuntar a servicios distintos. Revisa SPF, DKIM y DMARC para el proveedor saliente real. El SPF del hosting anterior quizá ya no autoriza.
Mantén un único SPF y añade solo remitentes documentados. Comprueba el selector DKIM exacto.
No cambies MX porque WordPress no envíe: los MX dirigen la recepción y un cambio descuidado puede detener el correo corporativo.
Inspecciona el entorno nuevo
Compara versión PHP, extensiones, memoria y logs. Revisa en cPanel o Plesk el mail routing si los buzones se alojan fuera. Un servidor marcado como exchanger local puede retener mensajes que debería enviar al proveedor externo.
Consulta ModSecurity, firewall y recursos a la hora del test. Si el plugin usa WP-Cron, confirma que las tareas programadas se ejecutan.
Cambia únicamente la regla o conexión demostrada.
Verifica el recorrido completo
Después de corregir, realiza un envío único. Demuestra una entrada, una notificación generada, una aceptación del proveedor y un mensaje entregado.
Revisa las cabeceras recibidas para SPF, DKIM y DMARC. Prueba el destinatario empresarial y uno externo porque filtran distinto.
Comprueba Reply-To, adjuntos, destinatarios condicionales y cualquier CRM enlazado.
Protege los leads durante la reparación
Revisa las entradas guardadas desde la migración y entrégalas a personal autorizado. Si no se retienen, muestra un contacto alternativo monitorizado hasta demostrar la entrega.
Documenta la hora de corte y compara consultas con emails o CRM para detectar pérdidas. No reenvíes automáticamente todas las entradas sin verificar consentimiento, destinatario y duplicados.
Cuándo solicitar ayuda urgente
Pide reparación si falla SMTP, el routing es incierto o ya pueden faltar leads. Facilita hora de migración, URL, hora del test y error redactado, nunca contraseñas o contenido personal.
El cierre exige demostrar el recorrido completo desde el navegador hasta la bandeja, no solo recuperar un aviso de éxito.