Un web migrat pot carregar perfectament mentre Plesk gestiona el correu de manera diferent del servidor anterior. La subscripció nova pot tenir el servei desactivat, un límit d’enviament, un altre handler PHP o routing local que entra en conflicte amb el proveïdor real.
Segueix un missatge sintètic per WordPress, Plesk i el servei previst abans d’editar DNS.
Identifica la ruta d’enviament activa
Determina si WordPress utilitza PHP mail local, el servidor de Plesk, SMTP autenticat extern o una API. Anota el plugin, el domini remitent, el destí i l’hora.
No suposis que el plugin SMTP copiat està actiu. Constants, must-use plugins o la imatge de l’allotjament poden sobreescriure els camps visibles.
Comprova si el formulari ha desat l’entrada; si falta, investiga la petició abans del correu.
Revisa els ajustos de la subscripció
A Plesk, confirma que el servei de correu està habilitat per al domini i que la subscripció pot enviar. Les polítiques globals i de subscripció poden ser diferents.
Consulta els controls sortints i els límits del domini, la bústia i la subscripció. Una migració pot heretar una quota baixa o esgotada, especialment després de moltes proves.
No augmentis límits fins a descartar un compte compromès o enviaments de spam.
Inspecciona la cua i els logs
Amb accés autoritzat, busca el destinatari i l’hora a la cua i al mail log. Determina si Plesk ha acceptat, ajornat, rebutjat o no ha rebut mai el missatge.
Desa l’ID de cua i la resposta amb dades ocultes. Un missatge deferred requereix interpretar l’estat remot; un d’absent retorna la investigació a PHP, WordPress o el transport extern.
Conserva l’evidència abans d’esborrar o forçar reintents: pot haver-hi leads reals.
Verifica el routing del domini
Si el correu corporatiu està fora, Plesk no ha d’intentar lliurar a bústies locals inexistents. Compara l’estat del servei local amb el disseny MX autoritzat.
Desactivar el correu local pot ser correcte per a un domini extern, però només després de confirmar que no queden bústies legítimes al servidor.
Un canvi incorrecte trenca correu entrant, àlies i autorespostes; documenta el propietari i la reversió.
Compara handlers PHP i sendmail
La migració pot haver canviat la versió, el handler o sendmail_path. Comprova quina configuració utilitza realment el domini i si permet funcions locals.
Revisa errors PHP i registres per domini a l’hora de l’enviament. Una prova PHP per terminal pot utilitzar una configuració diferent de PHP-FPM i WordPress.
Per a un lliurament observable, prioritza SMTP autenticat o un proveïdor compatible en lloc d’editar rutes del sistema sense evidència.
Prova l’SMTP extern
Si s’utilitza un proveïdor extern, verifica la resolució DNS i la connexió sortint al port documentat. El firewall de Plesk o la infraestructura poden bloquejar SMTP.
Confirma hostname, port, TLS i propietat de la credencial. No desactivis la verificació TLS ni exposis la contrasenya a l’historial o als logs.
Si una política bloqueja la connexió, demana permetre únicament el destí i el port necessaris.
Revisa DNS i identitat
Comprova SPF, DKIM i DMARC del proveïdor real. Plesk pot proposar registres per al seu servei local, però no són correctes si envia un altre sistema.
Mantén una sola política SPF i el selector DKIM exacte. No canviïs MX per fer passar una prova sortint.
Utilitza una adreça autoritzada a From i el visitant a Reply-To.
Demostra el lliurament després de migrar
Després de corregir el traspàs confirmat, envia una vegada el formulari amb una altra referència. Confirma entrada, intent, acceptació de la cua o proveïdor i arribada final.
Prova la bústia empresarial, Reply-To, adjunts i notificacions programades. Revisa les entrades creades durant la migració.
Demana reparació urgent si no és clara la cua, el routing o una restricció global. Facilita domini, hora, ID i estat amb dades ocultes; mai credencials o contingut real.