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.

Separa el emisor, el DNS y el receptor

  1. 01

    WordPress crea el mensaje

    Usa el recorrido del formulario real y su dirección From efectiva.

  2. 02

    El servicio emisor firma

    La firma identifica su dominio d= y su selector s=.

  3. 03

    El receptor comprueba la clave pública

    El receptor consulta el selector en el DNS autoritativo y verifica la firma.

  4. 04

    El receptor registra el resultado

    Lee el Authentication-Results fiable de ese mensaje entregado.

Cuatro etapas del diagnóstico. La consulta DNS sirve al receptor para verificar; el interruptor del panel solo describe el servicio que controla.

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.

Lee el resultado del receptor y comprueba su origen

Usa los resultados añadidos por tu servicio receptor o por otro verificador en el que confíes expresamente. Una línea Authentication-Results copiada sin comprobar su origen puede ser falsa. RFC 8601 explica ese límite de confianza.

From: Website <forms@mail.example.invalid>
Authentication-Results: mx.receiver.example.invalid;
  dkim=fail header.d=mail.example.invalid header.s=forms;
  spf=pass smtp.mailfrom=mail.example.invalid;
  dmarc=pass header.from=mail.example.invalid
Fragmentos de cabecera ficticios para aprender a interpretarlos. No se ha enviado ningún mensaje ni verificado DNS o firmas. Los dominios .invalid no son valores de configuración que debas publicar.

Aquí DKIM falla, pero SPF pasa con el mismo dominio que el From visible y permite que DMARC pase por SPF. Ese resultado no repara DKIM ni demuestra entrega en la bandeja de entrada. El selector indicado se consultaría en forms._domainkey.mail.example.invalid; la cabecera por sí sola no identifica por qué falló la firma.

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

DKIM y DMARC son resultados distintos. Una firma DKIM válida y alineada puede satisfacer DMARC; un SPF válido y alineado también puede hacerlo aunque DKIM falle. Contrasta el resultado y los identificadores del receptor según la especificación actual de DMARC.

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.

Qué enviar para evaluar DKIM y el correo del formulario

Empieza por la URL del formulario, el servicio emisor real, la hora y zona horaria y si la entrega fue directa o reenviada. Describe los resultados DKIM, SPF y DMARC del receptor e indica quién gestiona el DNS. Así se distingue un problema de firma de una consulta de clave o una modificación en tránsito.

Envía primero una descripción. Oculta direcciones personales, cuerpos de mensajes y rutas internas; no pongas cabeceras completas, contraseñas ni claves privadas en la solicitud pública. Si hace falta evidencia detallada, acuerda un canal seguro.

Ver el proceso de evaluación · Solicitar una evaluación de DKIM y correo del formulario

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↗