Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Dns Y Entregabilidad

Los emails de WordPress llegan a spam después de migrar el dominio

Recupera la entrega tras migrar alineando remitente, SPF, DKIM, DMARC, contenido, DNS y reputación.

Una migración puede cambiar simultáneamente From, proveedor, DNS, IP y reputación. El mensaje puede ser aceptado pero filtrado porque la identidad nueva no está autenticada o todavía resulta desconocida.

Utiliza las cabeceras de una prueba recibida en spam para localizar la señal fallida, no pidas autorizar todo indiscriminadamente.

Define qué cambió

Anota dominios From anterior y nuevo, proveedor SMTP, IP, proveedor DNS y fecha de migración. Determina si WordPress usa hosting local, buzón autenticado o servicio transaccional.

Envía una prueba sintética con referencia única a un buzón empresarial controlado. Conserva las cabeceras en privado; no publiques direcciones, routing interno o contenido.

Compara con una cabecera correcta anterior si existe.

Lee los resultados de autenticación

Busca SPF, DKIM y DMARC. SPF evalúa la infraestructura autorizada para el envelope sender; DKIM valida firma y selector; DMARC comprueba alineación con el From visible.

Un mensaje puede pasar SPF y fallar DMARC porque autenticó un dominio del proveedor que no alinea con From. Registra los dominios exactos, no solo “pass” o “fail”.

El candado HTTPS del sitio no demuestra autenticación de email.

Corrige el remitente de WordPress

Configura From con una dirección estable del dominio verificado. Pon el email del visitante en Reply-To. Enviar como el visitante crea problemas de suplantación y autenticación.

Revisa cada formulario, WooCommerce, restablecimiento y llamada propia a wp_mail() por sobrescrituras del dominio antiguo. La prueba SMTP puede usar el remitente nuevo mientras el formulario real conserva el anterior.

Mantén un Return-Path monitorizado para rebotes.

Publica en el DNS autoritativo

Confirma qué nameservers están activos. Los registros que queden en el panel anterior no se aplican si DNS migró a Cloudflare u otro servicio.

Publica un único SPF con el remitente real y el selector DKIM exacto. Ajusta DMARC después de inventariar fuentes y entender la alineación.

Evita SPF duplicados, claves DKIM privadas y políticas DMARC restrictivas repentinas antes de probar.

Comprueba la reputación por separado

Un dominio o IP nuevo apenas tiene historial. Envía únicamente mensajes transaccionales legítimos, mantén bajos rebotes y quejas y evita ráfagas de pruebas o colas liberadas.

Separa la reputación del dominio, la IP y el flujo concreto. Un proveedor compartido puede tener una IP correcta mientras el dominio nuevo carece de historial; una IP dedicada recién estrenada también necesita volumen gradual. Consulta los eventos del proveedor antes de atribuir todo al contenido.

Si el hosting comparte IP con emisores desconocidos, un proveedor transaccional establecido ofrece mejor trazabilidad. Cambiar de proveedor no corrige autenticación incorrecta ni formularios comprometidos.

Revisa supresiones y hard bounces antes de reenviar.

Revisa la construcción del mensaje

La migración puede dejar enlaces HTTP, dominios staging, imágenes rotas o marca incoherente. Actualiza todo al dominio HTTPS canónico y mantén el aviso claro.

Evita acortadores, adjuntos innecesarios y lenguaje comercial excesivo en notificaciones operativas. Incluye una alternativa de texto cuando el mailer lo admita.

El contenido no compensa una autenticación fallida, pero elimina señales evitables.

Pide evidencia al sistema destinatario

Si el proveedor aceptó el mensaje, pide al administrador buscar por message ID y hora. Revisa razón de cuarentena, reglas de transporte y protección contra suplantación.

No dependas solo de la carpeta Spam de una persona ni de una prueba Gmail. Los dominios aplican políticas diferentes.

Autoriza únicamente una regla estrecha después de corregir la identidad.

Demuestra una recuperación estable

Después de reparar la señal, envía otra prueba. Confirma aceptación, ubicación final, Reply-To y resultados SPF/DKIM/DMARC.

No declares resuelto el incidente con un solo mensaje. Comprueba que varias notificaciones legítimas, espaciadas y dirigidas a los dominios realmente usados por el negocio mantienen la misma autenticación y colocación, sin aumentar artificialmente el volumen.

Monitoriza varios avisos reales de bajo volumen en distintos dominios y revisa rebotes. Reconcilia las entradas del periodo de migración.

Solicita reparación urgente si no está clara la autoridad DNS, DMARC varía o la IP compartida tiene mala reputación. Comparte cabeceras redactadas e ID, nunca contraseñas o consultas.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia