Una migració pot canviar el servidor que envia correu de l’aplicació sense moure les bústies. WordPress pot informar d’èxit mentre el nou allotjament bloqueja connexions, utilitza una IP no autoritzada o conserva l’SMTP de staging. Separa els missatges generats pel web de la recepció del correu.
Defineix què ha deixat de funcionar
Prova una ruta concreta: restabliment, formulari o avís administratiu. Registra hora, destinatari, remitent, resultat i message ID. Pregunta si el correu normal entre bústies també falla.
Si només fallen notificacions de WordPress, no canviïs els MX. Els MX controlen la recepció, no configuren l’enviament de l’aplicació.
Dibuixa l’arquitectura prevista
Documenta qui allotja les bústies i com ha d’enviar WordPress: SMTP extern autenticat, bústia del hosting, proveïdor transaccional o servidor local. Anota host, port, xifratge, usuari i domini From sense copiar contrasenyes al tiquet.
La migració ha de tractar el DNS entrant i l’enviament de l’aplicació com a treballs separats.
Revisa la configuració activa
Inspecciona el connector SMTP, constants i variables d’entorn. Una còpia pot conservar un remitent de staging, l’enviament desactivat o credencials xifrades per a un altre servidor.
Envia una prova instrumentada i llegeix l’error:
Connection timed out -> xarxa, tallafoc o port
Authentication failed -> credencials o política
Sender rejected -> identitat From no autoritzada
Accepted amb message ID -> investigar el lliurament posteriorNo publiquis transcripcions SMTP completes: poden incloure autenticació.
Verifica la connectivitat sortint
Alguns hostings compartits bloquegen el port 25 o SMTP extern excepte relays aprovats. Prova el hostname i port des del servidor nou, inclosos DNS i negociació TLS. El més habitual és 587 amb STARTTLS o 465 amb TLS implícit, segons el proveïdor.
No desactivis la validació del certificat. Corregeix el nom, cadena de confiança o hora del sistema.
Torna a autoritzar l’entorn
El proveïdor pot restringir per IP, regió, contrasenya d’aplicació, redirect OAuth o política. Actualitza allowlists i retira la IP antiga després del període de rollback.
El From visible ha d’estar permès pel compte autenticat. Utilitza Reply-To per al visitant; suplantar-lo al From perjudica SPF, DKIM i DMARC.
Audita el DNS sense danyar la recepció
Revisa SPF, DKIM i DMARC autoritatius per al servei que envia. Hi ha d’haver un únic SPF consolidat, no diversos TXT competidors. Activa DKIM des del proveïdor que signa.
Conserva els MX i verificacions del proveïdor de bústies tret que el servei de correu també es migri.
Segueix el missatge després de WordPress
«Accepted» només significa que el servidor següent n’ha assumit la responsabilitat, no que hagi arribat a la safata. Cerca el message ID al proveïdor: lliurat, diferit, rebotat, suprimit o rebutjat.
Revisa quarantena i llistes de supressió. En una mostra lliurada, comprova SPF, DKIM i DMARC a les capçaleres.
Comprova també el remitent del sobre o Return-Path: pot diferir del From visible i és qui rep els rebots. Ha de pertànyer a un domini autoritzat i alinear-se amb DMARC quan correspongui.
Prova tots els destinataris operatius
Assaja el domini del propietari i una bústia externa. Valida resets, avisos de formulari, confirmacions d’usuari, seguretat i backups. Retira les proves de l’analítica o cues quan calgui.
Comprova que les cues cron antigues no alliberin duplicats. Els informes programats poden utilitzar una ruta diferent del connector provat.
Evita un altre error silenciós
Desa un esquema no secret del correu amb la documentació de l’allotjament. La monitorització ha d’enviar un missatge controlat, verificar-ne l’acceptació i alertar per autenticació o supressió.
Controla els canvis de domini i DKIM i la caducitat de credencials. El correu fiable es demostra amb un lliurament rastrejable, no amb un avís verd de WordPress.