DKIM selector not found significa che il destinatario non riesce a recuperare la chiave pubblica al nome costruito con il selector `s=` e il dominio `d=` presenti nella firma. Il record atteso è normalmente `selector._domainkey.dominio`.
Questa guida approfondisce DKIM selector not found con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
Il selector non è necessariamente `default`: ogni servizio può utilizzare nomi differenti e ruotarli nel tempo. Bisogna leggere l’header DKIM-Signature del messaggio reale.
Il record può essere TXT con la chiave oppure CNAME verso il provider. Crearlo nella zona DNS non autoritativa non produce alcun effetto.
Come riconoscere il problema
- Authentication-Results mostra dkim=fail key not found.
- Il test non trova selector._domainkey.
- Un servizio nuovo firma ma non verifica.
- Dopo cambio DNS il DKIM scompare.
- Il messaggio usa un selector diverso da quello configurato.
Cause più frequenti
1. Selector errato
Il record pubblicato non corrisponde a `s=`. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. Dominio d= differente
La firma usa un sottodominio o dominio del provider. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Zona non autoritativa
Il record è stato creato nel pannello sbagliato. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Record troncato o malformato
La chiave TXT non è restituita correttamente. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. CNAME mancante
Il provider richiede delega invece di una chiave diretta. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Rotazione incompleta
Il servizio ha iniziato a usare un nuovo selector prima della pubblicazione. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
Diagnosi passo per passo
- Apri DKIM-Signature. Copia i valori `d=` e `s=`. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Costruisci il nome. Interroga `s._domainkey.d`. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla TXT e CNAME. Usa dig sul tipo appropriato. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Verifica nameserver. Assicurati di modificare la zona autoritativa. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Confronta il valore del provider. Copia la chiave o destinazione esatta. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla TTL e resolver. Verifica risposta autoritativa e pubblica. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Invia un nuovo messaggio. Le email vecchie mantengono la firma precedente. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
Metodo sicuro di diagnosi
Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.
Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.
Procedura di risoluzione
- Pubblica il record corretto. Usa selector e dominio effettivi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi il nome nel pannello. Evita di aggiungere il dominio due volte. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Usa CNAME quando richiesto. Non convertire arbitrariamente in TXT. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Mantieni selector vecchio durante la rotazione. Rimuovilo solo dopo la scadenza dei messaggi e indicazioni del provider. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi la chiave. Preserva l’intero valore e la sintassi `v=DKIM1; p=`. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Attendi il TTL. Ripeti il test quando i resolver vedono il record. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Verifica allineamento DMARC. Il dominio `d=` deve essere coerente con il From secondo la policy. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Verifica della stabilità dopo l’intervento
Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.
Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.
Controlli finali
- Il nome restituisce TXT o CNAME.
- DKIM passa su un nuovo messaggio.
- La chiave non è troncata.
- Il selector attivo è documentato.
- DMARC valuta l’allineamento previsto.
Prevenzione
- Documenta selector.
- Pianifica rotazioni.
- Controlla DNS autoritativo.
- Mantieni record vecchi nel periodo di transizione.
- Testa messaggi reali.
Errori da evitare
- Non assumere selector default.
- Non pubblicare nella zona sbagliata.
- Non rimuovere subito il selector vecchio.
- Non creare più record incompatibili sullo stesso nome.
- Non modificare la chiave manualmente.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:
- header DKIM-Signature
- dominio e selector
- output TXT/CNAME
- nameserver
- servizio mittente
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Verifica prolungata dopo la correzione
Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.
Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.
Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.
Domande frequenti su DKIM selector not found
Il selector è sempre default?
No. Ogni provider può usare e ruotare selector differenti.
Dove trovo il selector usato?
Nel parametro `s=` dell’header DKIM-Signature.
Il dominio da interrogare è il From?
Devi usare il parametro `d=` della firma; l’allineamento col From è un controllo DMARC separato.
Posso usare un CNAME?
Sì, quando il provider richiede la delega del selector.
Perché il test passa ma una vecchia email fallisce?
Il messaggio vecchio può essere firmato con un selector precedente o prima della propagazione.