Una web migrada puede cargar perfectamente mientras Plesk gestiona el correo de forma distinta al servidor anterior. La suscripción nueva puede tener el servicio desactivado, un límite de envío, otro handler PHP o routing local que entra en conflicto con el proveedor real.
Sigue un mensaje sintético por WordPress, Plesk y el servicio previsto antes de editar DNS.
Identifica la ruta de envío activa
Determina si WordPress utiliza PHP mail local, el servidor de Plesk, SMTP autenticado externo o una API. Anota plugin, dominio remitente, destino y hora.
No supongas que el plugin SMTP copiado está activo. Constantes, must-use plugins o la imagen del hosting pueden sobrescribir sus campos visibles.
Comprueba si el formulario guardó la entrada; si falta, investiga la petición antes del correo.
Revisa los ajustes de la suscripción
En Plesk, confirma que el servicio de correo está habilitado para el dominio y que la suscripción puede enviar. Las políticas globales y de suscripción pueden ser diferentes.
Consulta controles salientes y límites del dominio, buzón y suscripción. Una migración puede heredar una cuota baja o agotada, especialmente tras muchas pruebas.
No aumentes límites hasta descartar una cuenta comprometida o spam.
Inspecciona cola y logs
Con acceso autorizado, busca destinatario y hora en la cola y el mail log. Determina si Plesk aceptó, aplazó, rechazó o nunca recibió el mensaje.
Guarda el ID de cola y la respuesta redactada. Un mensaje deferred requiere interpretar el estado remoto; uno ausente devuelve la investigación a PHP, WordPress o transporte externo.
Conserva la evidencia antes de borrar o forzar reintentos: puede haber leads reales.
Verifica el routing del dominio
Si el correo corporativo está fuera, Plesk no debe intentar entregar a buzones locales inexistentes. Compara el estado del servicio local con el diseño MX autorizado.
Desactivar correo local puede ser correcto para un dominio externo, pero únicamente después de confirmar que no quedan buzones legítimos en el servidor.
Un cambio incorrecto rompe correo entrante, alias y autorespuestas; documenta propietario y reversión.
Compara handlers PHP y sendmail
La migración puede haber cambiado versión, handler o sendmail_path. Comprueba qué configuración usa realmente el dominio y si permite funciones locales.
Revisa errores PHP y logs por dominio a la hora de envío. Una prueba PHP por terminal puede utilizar otra configuración que PHP-FPM y WordPress.
Para una entrega observable, prioriza SMTP autenticado o un proveedor compatible en vez de editar rutas del sistema sin evidencia.
Prueba el SMTP externo
Si se usa un proveedor externo, verifica resolución DNS y conexión saliente al puerto documentado. El firewall de Plesk o la infraestructura pueden bloquear SMTP.
Confirma hostname, puerto, TLS y propiedad de la credencial. No desactives la verificación TLS ni expongas la contraseña en historial o logs.
Si una política bloquea la conexión, solicita permitir únicamente destino y puerto necesarios.
Revisa DNS e identidad
Comprueba SPF, DKIM y DMARC del proveedor real. Plesk puede proponer registros para su servicio local, pero no son correctos si envía otro sistema.
Mantén una sola política SPF y el selector DKIM exacto. No cambies MX para hacer pasar una prueba saliente.
Usa una dirección autorizada en From y al visitante en Reply-To.
Demuestra la entrega tras migrar
Después de corregir el traspaso confirmado, envía una vez el formulario con otra referencia. Confirma entrada, intento, aceptación de cola o proveedor y llegada final.
Prueba el buzón empresarial, Reply-To, adjuntos y notificaciones programadas. Revisa las entradas creadas durante la migración.
Solicita reparación urgente si no está clara la cola, el routing o una restricción global. Facilita dominio, hora, ID y estado redactado; nunca credenciales o contenido real.