Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Dns I Lliurabilitat

DKIM falla a WordPress encara que el panell diu que està actiu

Rastreja el remitent real, selector, DNS autoritatiu, domini de signatura i modificacions quan DKIM falla.

El panell pot mostrar DKIM actiu per al seu propi servei mentre WordPress envia mitjançant un altre proveïdor. DKIM només passa si l’emissor real signa i la clau pública corresponent és al DNS autoritatiu.

Llegeix una capçalera lliurada per identificar el signant abans de tocar registres.

Separa l’emissor, el DNS i el receptor

  1. 01

    WordPress crea el missatge

    Utilitza el recorregut del formulari real i la seva adreça From efectiva.

  2. 02

    El servei emissor signa

    La signatura identifica el seu domini d= i el seu selector s=.

  3. 03

    El receptor comprova la clau pública

    El receptor consulta el selector al DNS autoritatiu i verifica la signatura.

  4. 04

    El receptor registra el resultat

    Llegeix l’Authentication-Results fiable d’aquell missatge lliurat.

Quatre etapes del diagnòstic. La consulta DNS serveix al receptor per verificar; l’interruptor del panell només descriu el servei que controla.

Confirma si existeix una signatura

Inspecciona DKIM-Signature i Authentication-Results. Anota el domini de signatura (d=), el selector (s=), el resultat i el message ID.

Si no hi ha signatura, DNS no pot afegir-la després: el servei emissor ha de signar. Si existeix però falla, continua amb el selector, la clau i la integritat.

Anota també l’algoritme, la canonicalització (c=), les capçaleres incloses a h= i si hi ha més d’una signatura. Dos proveïdors poden signar el mateix missatge; cada firma s’avalua per separat i una de vàlida pot satisfer DMARC si està alineada.

Protegeix el destinatari i el routing intern quan comparteixis capçaleres.

Llegeix el resultat del receptor i comprova’n l’origen

Utilitza els resultats afegits pel teu servei receptor o per un altre verificador en qui confiïs expressament. Una línia Authentication-Results copiada sense comprovar-ne l’origen pot ser falsa. RFC 8601 explica aquest límit de confiança.

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
Fragments de capçalera ficticis per aprendre a interpretar-los. No s’ha enviat cap missatge ni verificat DNS o signatures. Els dominis .invalid no són valors de configuració que hagis de publicar.

Aquí DKIM falla, però SPF passa amb el mateix domini que el From visible i permet que DMARC passi per SPF. Aquest resultat no repara DKIM ni demostra lliurament a la safata d’entrada. El selector indicat es consultaria a forms._domainkey.mail.example.invalid; la capçalera tota sola no identifica per què ha fallat la signatura.

Identifica el transport real

Determina si WordPress utilitza correu local, SMTP extern o API. L’interruptor DKIM de cPanel o Plesk controla normalment el correu d’aquell servidor, no Microsoft 365, Google Workspace o un altre proveïdor.

Revisa plugins actius, constants i hooks de PHPMailer. L’eina de prova i el formulari poden utilitzar From o transports diferents.

Busca el missatge controlat al log del proveïdor real.

Consulta el selector exacte

La clau pública és a:

selector._domainkey.domini-de-signatura.example

Substitueix el selector i el domini pels valors s= i d= de la capçalera. Consulta el DNS autoritatiu i compara’l amb les instruccions actuals.

No endevinis el selector default només perquè l’utilitza el panell.

Comprova l’autoritat DNS

Revisa els nameservers. Una clau mostrada a l’allotjament no té efecte quan DNS és a Cloudflare o en un altre lloc.

Publica el TXT o CNAME exacte del proveïdor al servei actiu. Alguns panells afegeixen la zona automàticament; verifica el hostname complet resultant.

Consulta directament un nameserver autoritatiu a més d’un resolver recursiu. Així distingeixes un registre mal publicat d’una resposta antiga conservada per TTL o caché negativa.

No publiquis mai la clau privada ni la copiïs entre proveïdors.

Busca claus antigues o rotades

Els serveis roten selectors i claus. L’emissor pot signar amb un de nou mentre DNS conserva només l’anterior, o una migració pot restaurar valors obsolets.

Mantén selectors antics només durant el solapament recomanat i elimina després els que no s’utilitzen. No combinis dues claus en un TXT.

Espera el TTL i la verificació del proveïdor abans de repetir.

Comprova l’alineació del domini

DKIM i DMARC són resultats diferents. Una signatura DKIM vàlida i alineada pot satisfer DMARC; un SPF vàlid i alineat també ho pot fer encara que DKIM falli. Contrasta el resultat i els identificadors del receptor segons l’especificació actual de DMARC.

Utilitza From fix i autenticat, i el visitant a Reply-To. No canviïs dominis From dinàmicament des de camps públics.

Registra per separat DKIM pass i l’alineació DMARC.

Investiga modificacions del missatge

DKIM pot fallar si un gateway, reenviament o plugin canvia capçaleres o cos després de signar. Compara l’evidència del proveïdor amb la versió rebuda després de cada salt.

La canonicalització relaxada tolera certs canvis d’espais, però no una reescriptura arbitrària de l’assumpte, el remitent o el cos. Un peu legal afegit després de signar, una llista que modifica l’assumpte o una recodificació poden invalidar el hash.

Prova el lliurament directe a una bústia controlada abans d’una llista o helpdesk. Evita footers i reescriptures posteriors innecessaris.

Si el lliurament directe passa i el reenviat falla, conserva totes dues capçaleres i localitza el primer salt que altera el missatge. No rotis claus quan la signatura era vàlida abans de l’intermediari.

No debilitis la firma fins a identificar quin sistema modifica.

Verifica la ruta completa

Després de corregir la signatura o DNS, envia el formulari real amb una altra referència. Confirma que el proveïdor signa, el receptor mostra dkim=pass, DMARC s’alinea i arriba a la bústia empresarial.

Prova confirmacions al visitant i altres dominis From per separat. Documenta qui controla el selector per a migracions futures.

Demana reparació urgent si diversos emissors signen diferent, el selector és incert o un reenviament trenca signatures vàlides. Comparteix DNS públic i resultats amb dades ocultes, mai claus privades o credencials.

Què enviar per avaluar DKIM i el correu del formulari

Comença per l’URL del formulari, el servei emissor real, l’hora i la zona horària i si el lliurament ha estat directe o reenviat. Descriu els resultats DKIM, SPF i DMARC del receptor i indica qui gestiona el DNS. Així es distingeix un problema de signatura d’una consulta de clau o una modificació en trànsit.

Envia primer una descripció. Oculta adreces personals, cossos de missatges i rutes internes; no posis capçaleres completes, contrasenyes ni claus privades a la sol·licitud pública. Si cal evidència detallada, acorda un canal segur.

Veure el procés d’avaluació · Sol·licitar una avaluació de DKIM i correu del formulari

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència↗