En canviar els nameservers, la zona de Cloudflare esdevé autoritativa. Els registres que només romanen a l’allotjament anterior deixen de veure’s, i la importació automàtica pot ser incompleta o aplicar proxy on no correspon.
Separa el correu entrant de l’autenticació sortint de WordPress abans de corregir res.
Conserva l’evidència
Anota l’hora del canvi, el proveïdor DNS anterior, el proveïdor de correu i el primer error. Exporta o captura totes dues zones abans d’editar.
Envia un formulari sintètic i comprova si WordPress l’ha generat, el proveïdor l’ha acceptat i el gateway l’ha vist. Prova el correu empresarial entrant per separat.
No canviïs MX, SPF i SMTP simultàniament: no sabràs quina capa s’ha reparat.
Confirma que Cloudflare és autoritatiu
Consulta els NS públics i compara’ls amb els assignats al compte. Verifica la delegació al registrador, inclosos l’ortografia i l’estat DNSSEC.
Si DNSSEC estava actiu abans, un DS antic pot causar errors de validació. Coordina’n la retirada o substitució seguint el registrador i Cloudflare.
Revisa també CAA si el canvi coincideix amb certificats nous per a hostnames de correu. CAA no configura SMTP, però una política incompleta pot impedir que el proveïdor renovi el certificat esperat i provocar errors TLS.
No suposis que el dashboard és en producció fins a confirmar la delegació pública.
Restaura els MX exactament
Compara els hosts MX, les prioritats i els noms finals amb la configuració oficial del proveïdor. Els destins han de resoldre i no apuntar a una adreça web amb proxy.
Crea els A/CNAME de correu com a DNS-only quan siguin necessaris. El proxy HTTP normal de Cloudflare no transporta SMTP arbitrari.
Conserva MX antics només si formen part del servei actiu documentat.
Reconstrueix l’autenticació
Publica una única política SPF amb els emissors legítims. Afegeix els selectors DKIM o CNAME dels proveïdors reals i el DMARC previst sota _dmarc.
Verifica el hostname final després que la interfície afegeixi la zona. Duplicar SPF o escriure dues vegades el domini al selector són errors freqüents.
No copiïs claus privades ni autoritzis un proveïdor retirat.
Revisa l’estat del proxy
Els hostnames utilitzats per IMAP, POP o SMTP normalment han d’estar en DNS-only tret que hi hagi suport exprés. Un núvol taronja pot conduir el client o WordPress a la xarxa equivocada.
Els registres web poden continuar amb proxy; correu i web no necessiten el mateix estat.
Documenta el propietari i la finalitat de cada registre abans de canviar-lo.
Comprova el hostname SMTP de WordPress
WordPress ha d’utilitzar l’endpoint oficial del proveïdor. Si usa mail.elteudomini.example, confirma que resol directament al servidor correcte i que el certificat TLS cobreix el nom.
Revisa el port, el mode TLS i les restriccions sortints. El canvi de DNS pot revelar un hostname local antic que abans es resolia diferent dins de l’allotjament.
No desactivis TLS per tolerar un nom incorrecte.
Respecta la propagació
Compara les respostes de resolvers públics amb el TTL anterior. Durant un temps, alguns emissors veuran la zona antiga i d’altres Cloudflare.
No esborris i recreïs registres repetidament. Utilitza referències úniques i registra quin resolver o receptor ha produït cada resultat.
El TTL es redueix abans d’una migració planificada, no després que les memòries cau ja existeixin.
Desa una taula amb hostname, tipus, resposta antiga, resposta nova i hora observada. Així distingeixes propagació normal d’un registre realment absent.
Verifica entrada i sortida per separat
Per a l’entrada, envia a una bústia empresarial i confirma que el proveïdor ho rep. Per a la sortida, executa el formulari i segueix generació, acceptació SMTP i lliurament.
Inspecciona SPF, DKIM i DMARC del missatge web. Confirma que Reply-To apunta al visitant sintètic i que cap bústia local de l’allotjament l’ha capturat.
Demana reparació urgent si no existeix la zona anterior, falla DNSSEC o el routing empresarial és incert. Comparteix DNS públic i estats amb dades ocultes, mai credencials del registrador, Cloudflare o bústia.