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

Dns Y Entregabilidad

DKIM falla en WordPress aunque el panel del hosting dice que está activo

Rastrea el remitente real, selector, DNS autoritativo, dominio de firma y modificaciones cuando DKIM falla.

El panel puede mostrar DKIM activo para su propio servicio mientras WordPress envía mediante otro proveedor. DKIM solo pasa si el emisor real firma y la clave pública correspondiente está en el DNS autoritativo.

Lee una cabecera entregada para identificar al firmante antes de tocar registros.

Confirma si existe una firma

Inspecciona DKIM-Signature y Authentication-Results. Anota dominio de firma (d=), selector (s=), resultado y message ID.

Si no hay firma, DNS no puede añadirla después: el servicio emisor debe firmar. Si existe pero falla, continúa con selector, clave e integridad.

Anota también el algoritmo, la canonicalización (c=), las cabeceras incluidas en h= y si aparece más de una firma. Dos proveedores pueden firmar el mismo mensaje; cada firma se evalúa por separado y una válida puede ser suficiente para DMARC si está alineada.

Protege destinatario y routing interno al compartir cabeceras.

Identifica el transporte real

Determina si WordPress usa correo local, SMTP externo o API. El interruptor DKIM de cPanel o Plesk controla normalmente el correo de ese servidor, no Microsoft 365, Google Workspace u otro proveedor.

Revisa plugins activos, constantes y hooks de PHPMailer. La herramienta de prueba y el formulario pueden usar From o transportes diferentes.

Busca el mensaje controlado en el log del proveedor real.

Consulta el selector exacto

La clave pública está en:

selector._domainkey.dominio-de-firma.example

Sustituye selector y dominio por s= y d= de la cabecera. Consulta DNS autoritativo y compara con las instrucciones actuales.

No adivines el selector default solo porque lo use el panel.

Comprueba la autoridad DNS

Revisa los nameservers. Una clave mostrada en el hosting no tiene efecto cuando DNS está en Cloudflare u otro lugar.

Publica TXT o CNAME exacto del proveedor en el servicio activo. Algunos paneles añaden la zona automáticamente; verifica el hostname completo resultante.

Consulta directamente un nameserver autoritativo además de un resolver recursivo. Así distingues un registro mal publicado de una respuesta antigua conservada por TTL o caché negativa tras haber preguntado antes de crear el selector.

Nunca publiques la clave privada ni la copies entre proveedores.

Busca claves antiguas o rotadas

Los servicios rotan selectores y claves. El emisor puede firmar con uno nuevo mientras DNS conserva solo el anterior, o una migración puede restaurar valores obsoletos.

Mantén selectores antiguos únicamente durante el solapamiento recomendado y elimina después los que no se usan. No combines dos claves en un TXT.

Espera TTL y verificación del proveedor antes de repetir.

Comprueba la alineación del dominio

Una firma puede pasar DKIM y fallar DMARC si d= no alinea con From. Configura un dominio de envío personalizado verificado cuando el proveedor lo permita.

Usa From fijo y autenticado, y al visitante en Reply-To. No cambies dominios From dinámicamente desde campos públicos.

Registra por separado DKIM pass y alineación DMARC.

Investiga modificaciones del mensaje

DKIM puede fallar si un gateway, reenvío o plugin cambia cabeceras o cuerpo después de firmar. Compara la evidencia del proveedor con la versión recibida tras cada salto.

La canonicalización relajada tolera ciertos cambios de espacios, pero no una reescritura arbitraria del asunto, remitente o cuerpo. Un pie legal añadido después de firmar, una lista que modifica el asunto o un sistema que recodifica el contenido puede invalidar el hash.

Prueba entrega directa a un buzón controlado antes de una lista o helpdesk. Evita footers y reescrituras posteriores innecesarios.

Si la entrega directa pasa y la reenviada falla, conserva ambas cabeceras y localiza el primer salto que altera el mensaje. No sustituyas el selector ni rotes claves cuando la firma era válida antes de ese intermediario.

No debilites la firma hasta identificar qué sistema modifica.

Verifica la ruta completa

Tras corregir firma o DNS, envía el formulario real con otra referencia. Confirma que el proveedor firma, el receptor muestra dkim=pass, DMARC alinea y llega al buzón empresarial.

Prueba confirmaciones al visitante y otros dominios From por separado. Documenta quién controla el selector para futuras migraciones.

Solicita reparación urgente si varios emisores firman distinto, el selector es incierto o un reenvío rompe firmas válidas. Comparte DNS público y resultados redactados, nunca claves privadas o credenciales.

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