DKIM selector con più record TXT: cause e soluzioni

DKIM selector con più record TXT indica che lo stesso nome DNS, per esempio selector._domainkey.esempio.it, restituisce due o più record TXT compatibili con DKIM. Il destinatario deve trovare una sola chiave pubblica valida per verificare la firma presente nell’header del messaggio. Quando le risposte sono multiple, duplicate o incoerenti, la verifica può terminare con un errore, con un risultato temporaneo oppure con un comportamento diverso tra provider.

Il problema compare spesso dopo una migrazione della posta, un cambio di provider DNS, una rotazione della chiave o l’attivazione contemporanea di due sistemi che usano lo stesso selector. Questa guida mostra come diagnosticare DKIM selector con più record TXT, distinguere un duplicato reale da una risposta frammentata correttamente e ripristinare la configurazione senza interrompere inutilmente l’invio delle email.

Che cosa significa DKIM selector con più record TXT

DKIM, acronimo di DomainKeys Identified Mail, aggiunge al messaggio una firma crittografica. Nell’header DKIM-Signature sono presenti il dominio firmatario nel parametro d= e il selector nel parametro s=. Il server ricevente costruisce quindi il nome DNS s._domainkey.d e interroga il record TXT corrispondente.

Una configurazione normale restituisce una sola chiave DKIM, tipicamente con una stringa che inizia con v=DKIM1; e contiene p= seguito dalla chiave pubblica. Il DNS può suddividere una stringa lunga in più segmenti tra virgolette: questa suddivisione non equivale a più record, perché i segmenti appartengono alla stessa risposta TXT e vengono concatenati dal resolver.

Con DKIM selector con più record TXT, invece, il nome pubblica più record TXT distinti. Possono essere due chiavi complete, una chiave vecchia e una nuova, un record valido insieme a una voce vuota oppure duplicati creati in zone DNS differenti. Il verificatore non può sapere quale chiave usare in modo affidabile e può classificare la firma come permerror, temperror o fail.

Come riconoscere un duplicato reale

La prima difficoltà consiste nel leggere correttamente l’output degli strumenti DNS. Una chiave RSA lunga viene spesso mostrata come due o più stringhe racchiuse tra virgolette sulla stessa riga logica. Questo è consentito dal formato TXT e non rappresenta un errore. Il resolver concatena automaticamente i segmenti prima di consegnarli al verificatore DKIM.

Un duplicato reale presenta invece più risposte indipendenti per lo stesso nome. Per esempio, il comando può mostrare due righe, ciascuna con v=DKIM1; e una diversa chiave p=. Anche due record identici restano una configurazione ambigua: non bisogna conservarli pensando che la duplicazione aumenti la ridondanza.

Sintomi associati a DKIM selector con più record TXT

• I report di autenticazione mostrano dkim=permerror, multiple records o key syntax error.
• Un provider accetta la firma mentre un altro la considera non valida.
• I test DKIM alternano risultati corretti e falliti senza modifiche apparenti.
• La posta arriva nello spam dopo una migrazione o una rotazione delle chiavi.
• I report DMARC indicano mancato allineamento perché DKIM non supera la verifica.
• Il pannello del servizio email segnala che il record DKIM non è verificabile.
• Interrogando nameserver diversi si ottengono chiavi pubbliche differenti.

Questi sintomi non dimostrano da soli la presenza di DKIM selector con più record TXT. Errori simili possono dipendere da selector errato, chiave troncata, firma modificata durante il transito, canonicalization incompatibile o record pubblicato sotto un nome sbagliato. Serve quindi una verifica diretta dei nameserver autorevoli.

Cause comuni di DKIM selector con più record TXT

1. Migrazione tra provider email

Il vecchio servizio e il nuovo servizio pubblicano entrambi una chiave con lo stesso selector. Se il record precedente non viene rimosso, il DNS espone due chiavi per lo stesso nome. Quando analizzi DKIM selector con più record TXT, annota quale piattaforma ha creato il record e chi è autorizzato a modificarlo, così eviti che la voce eliminata venga ripristinata automaticamente.

2. Rotazione della chiave eseguita sullo stesso selector

La nuova chiave viene aggiunta senza sostituire quella precedente. La rotazione corretta dovrebbe usare un selector nuovo oppure sostituire in modo controllato il record esistente. Quando analizzi DKIM selector con più record TXT, annota quale piattaforma ha creato il record e chi è autorizzato a modificarlo, così eviti che la voce eliminata venga ripristinata automaticamente.

3. Record duplicato nel pannello DNS

Alcuni pannelli consentono di creare più record TXT con lo stesso host. Un’importazione di zona o un’automazione può aggiungere una seconda copia senza eliminare la prima. Quando analizzi DKIM selector con più record TXT, annota quale piattaforma ha creato il record e chi è autorizzato a modificarlo, così eviti che la voce eliminata venga ripristinata automaticamente.

4. Zona DNS gestita su più provider

Il dominio è delegato a nameserver differenti o la zona secondaria non è sincronizzata. Alcuni resolver ricevono la chiave A, altri la chiave B. Quando analizzi DKIM selector con più record TXT, annota quale piattaforma ha creato il record e chi è autorizzato a modificarlo, così eviti che la voce eliminata venga ripristinata automaticamente.

5. Nome host interpretato in modo differente

Nel pannello viene inserito il nome completo quando il sistema aggiunge automaticamente il dominio, oppure viceversa. Possono nascere record su nomi simili e controlli ingannevoli. Quando analizzi DKIM selector con più record TXT, annota quale piattaforma ha creato il record e chi è autorizzato a modificarlo, così eviti che la voce eliminata venga ripristinata automaticamente.

6. Template o API che ricreano il record

Un sistema di provisioning, cPanel, un servizio email esterno o uno script di deploy ricrea periodicamente il vecchio DKIM dopo la correzione manuale. Quando analizzi DKIM selector con più record TXT, annota quale piattaforma ha creato il record e chi è autorizzato a modificarlo, così eviti che la voce eliminata venga ripristinata automaticamente.

7. CNAME DKIM sovrapposto a record TXT

Un selector delegato tramite CNAME non deve avere nello stesso nome altri dati DNS. La coesistenza è vietata e può produrre risposte non affidabili. Quando analizzi DKIM selector con più record TXT, annota quale piattaforma ha creato il record e chi è autorizzato a modificarlo, così eviti che la voce eliminata venga ripristinata automaticamente.

8. Cache e TTL durante la modifica

Dopo la sostituzione alcuni resolver conservano la risposta precedente. Per un intervallo limitato possono comparire risultati diversi, ma sui nameserver autorevoli deve esistere una sola configurazione. Quando analizzi DKIM selector con più record TXT, annota quale piattaforma ha creato il record e chi è autorizzato a modificarlo, così eviti che la voce eliminata venga ripristinata automaticamente.

Diagnosi passo per passo

1. Recupera dominio e selector dal messaggio

Apri gli header completi di un messaggio inviato dal sistema coinvolto. Cerca la riga DKIM-Signature e annota i valori d= e s=. Non usare un selector ipotizzato dal pannello: la verifica deve partire dalla firma realmente inviata.

DKIM-Signature: v=1; a=rsa-sha256; d=esempio.it; s=mail2026; ...

In questo esempio il nome da interrogare è mail2026._domainkey.esempio.it. Se il messaggio contiene più firme DKIM, esamina ciascuna separatamente.

2. Interroga il record con dig

dig TXT mail2026._domainkey.esempio.it +short

Conta le risposte logiche, non il numero delle stringhe tra virgolette. Per visualizzare maggiori dettagli usa:

dig TXT mail2026._domainkey.esempio.it

Se ottieni due record completi, hai una prova concreta di DKIM selector con più record TXT. Salva l’output prima di modificare la zona.

3. Identifica i nameserver autorevoli

dig NS esempio.it +short

Interroga ogni nameserver direttamente:

dig @ns1.provider.tld TXT mail2026._domainkey.esempio.it +short
dig @ns2.provider.tld TXT mail2026._domainkey.esempio.it +short

Le risposte devono essere coerenti. Se un nameserver mostra una chiave e l’altro due, il problema riguarda la sincronizzazione della zona e non soltanto la cache del resolver locale.

4. Controlla eventuali CNAME

dig CNAME mail2026._domainkey.esempio.it +short

Molti servizi cloud delegano il selector verso un nome gestito dal provider. Se esiste un CNAME, non deve coesistere un record TXT sullo stesso host. Segui la destinazione e controlla anche il record finale.

5. Confronta resolver pubblici e autorevoli

Interroga un resolver pubblico soltanto dopo aver verificato l’origine:

dig @1.1.1.1 TXT mail2026._domainkey.esempio.it +short
dig @8.8.8.8 TXT mail2026._domainkey.esempio.it +short

Se gli autorevoli sono corretti ma i resolver pubblici mostrano ancora la vecchia risposta, attendi il TTL. Se anche gli autorevoli pubblicano più chiavi, l’attesa non risolverà il problema.

6. Verifica la zona nel pannello corretto

Apri il DNS effettivamente autorevole per il dominio. In cPanel usa Zone Editor soltanto se i nameserver del dominio puntano a quella infrastruttura. Se il DNS è gestito da Cloudflare, dal registrar o da un servizio esterno, una modifica nella zona locale del server non avrà effetto pubblico.

Come correggere DKIM selector con più record TXT

Soluzione 1: mantenere una sola chiave per selector

Individua quale servizio firma attualmente i messaggi e conserva esclusivamente la relativa chiave pubblica. Rimuovi il record vecchio, duplicato o incompleto. Prima della cancellazione salva una copia della zona o almeno del record interessato.

Soluzione 2: usare selector differenti durante una migrazione

Il metodo più sicuro consiste nell’assegnare al nuovo servizio un selector diverso, per esempio mail2026 invece di default. Pubblica la nuova chiave, verifica che sia visibile, attiva la firma sul nuovo sistema e conserva temporaneamente il vecchio selector per i messaggi ancora firmati dal precedente provider.

Due selector differenti possono convivere senza conflitto perché corrispondono a nomi DNS distinti. Il problema nasce soltanto quando due chiavi vengono pubblicate sotto lo stesso selector.

Soluzione 3: correggere la delegazione DNS

Se i nameserver non restituiscono la stessa zona, verifica configurazione primaria/secondaria, seriale SOA, trasferimenti AXFR/IXFR e stato del cluster DNS. Non modificare casualmente i record su tutti i nodi: identifica la sorgente autorevole e ripristina la sincronizzazione.

Soluzione 4: rimuovere la sovrapposizione CNAME/TXT

Quando il provider richiede un CNAME, elimina qualsiasi TXT sul medesimo host e lascia che la chiave venga risolta tramite la destinazione indicata. Quando richiede un TXT, non aggiungere anche un CNAME. Copia esattamente host e valore forniti dal servizio.

Soluzione 5: disattivare automazioni che ricreano il duplicato

Controlla moduli di provisioning, sincronizzazioni DNS, template di zona, plugin, API del registrar e funzioni automatiche del servizio email. Dopo la correzione verifica nuovamente il record a distanza di alcune ore e dopo ogni deploy.

Soluzione 6: attendere soltanto il TTL necessario

Dopo aver corretto i nameserver autorevoli, i resolver possono conservare la risposta precedente fino alla scadenza del TTL. Non continuare a modificare il record durante questo periodo. Confronta sempre la risposta autorevole con quella in cache per capire se l’intervento è già effettivo all’origine.

Procedura sicura durante una rotazione DKIM

1. Genera una nuova coppia di chiavi sul servizio che firmerà i messaggi.
2. Scegli un selector nuovo e riconoscibile, evitando di riutilizzare subito quello precedente.
3. Pubblica il nuovo record TXT o CNAME nella zona autorevole.
4. Interroga direttamente tutti i nameserver e verifica che restituiscano la stessa chiave.
5. Attiva la firma con il nuovo selector e invia un messaggio di prova.
6. Controlla gli header ricevuti e il risultato DKIM presso più destinatari.
7. Mantieni il vecchio selector per un periodo compatibile con le code di posta e con i messaggi già inviati.
8. Rimuovi la vecchia chiave quando non è più necessaria, senza sovrascriverla con una seconda chiave sullo stesso nome.

Questa procedura evita sia interruzioni sia configurazioni con più record. La rotazione tramite selector distinti è più semplice da verificare e permette un rollback rapido.

Controlli dopo la correzione

Considera risolto DKIM selector con più record TXT soltanto quando tutti i livelli concordano. Esegui i seguenti controlli:

• Ogni nameserver autorevole restituisce una sola risposta DKIM per il selector.
• La chiave pubblica corrisponde alla chiave privata usata dal sistema di invio.
• Il messaggio di prova contiene i valori d= e s= attesi.
• Gli header del destinatario mostrano dkim=pass.
• DMARC supera l’allineamento con il dominio From, quando previsto dalla policy.
• I resolver pubblici convergono dopo il TTL.
• Il duplicato non ricompare dopo provisioning, aggiornamenti o sincronizzazioni.

Invia test a più provider perché le implementazioni possono segnalare l’ambiguità in modo diverso. Non usare soltanto un verificatore web: il risultato decisivo è la verifica effettuata sui messaggi realmente firmati.

Errori da evitare

• Non pubblicare due chiavi sotto lo stesso selector pensando di ottenere alta disponibilità.
• Non eliminare tutti i record DKIM senza sapere quale sistema sta firmando la posta.
• Non confondere i segmenti di una singola stringa TXT con record multipli.
• Non modificare una zona DNS che non è autorevole per il dominio.
• Non ridurre il TTL dopo la modifica aspettandosi che cancelli le cache già esistenti.
• Non copiare virgolette, spazi o nome del dominio in modo incompatibile con il pannello.
• Non riutilizzare immediatamente lo stesso selector durante una rotazione complessa.
• Non condividere chiavi private DKIM nei ticket o negli strumenti di controllo.

La chiave privata deve restare esclusivamente sul sistema di firma. Nel DNS va pubblicata soltanto la chiave pubblica contenuta nel parametro p=.

Prevenzione e monitoraggio

Per prevenire un nuovo caso di DKIM selector con più record TXT, documenta provider DNS, provider email, selector attivi e data di creazione delle chiavi. Usa selector che includano un riferimento temporale o al servizio, come xlogic2026 o newsletter1, invece di riutilizzare sempre default.

• Esporta la zona DNS prima delle migrazioni.
• Assegna un responsabile alle modifiche di autenticazione email.
• Controlla periodicamente SPF, DKIM e DMARC da resolver differenti.
• Monitora i report aggregati DMARC per aumenti di dkim=fail o permerror.
• Rimuovi selector obsoleti solo dopo aver verificato che non firmino più messaggi.
• Evita che più automazioni gestiscano lo stesso record senza una sorgente di verità.
• Registra ogni rotazione con data, selector precedente, selector nuovo e procedura di rollback.

Dati da inviare al supporto

Quando non riesci a risolvere DKIM selector con più record TXT, prepara una segnalazione con:

• dominio e selector coinvolti;
• header completo DKIM-Signature oscurando indirizzi o identificativi sensibili;
• output di dig NS e delle interrogazioni TXT verso ogni nameserver;
• provider DNS e provider che firma la posta;
• data e ora dell’ultima modifica con fuso orario;
• TTL del record;
• risultato DKIM e DMARC mostrato dal destinatario;
• descrizione di migrazioni, rotazioni o automazioni recenti.

Non allegare la chiave privata DKIM, password del pannello, token API o credenziali email. L’assistenza Xlogic opera tramite ticket o email e può verificare più rapidamente il problema quando riceve il selector esatto e le risposte dei nameserver autorevoli.

Domande frequenti

Conclusione

DKIM selector con più record TXT non si risolve aggiungendo altre chiavi o attendendo indefinitamente la propagazione. Parti dalla firma reale, individua dominio e selector, interroga direttamente i nameserver autorevoli e distingui una stringa TXT segmentata da più record indipendenti. Mantieni una sola chiave per selector, usa nomi nuovi durante le rotazioni e verifica il risultato su messaggi realmente ricevuti.

Una configurazione documentata di SPF, DKIM e DMARC riduce gli errori durante migrazioni e cambi di provider. Dopo la correzione controlla che DKIM risulti pass, che DMARC sia allineato e che nessuna automazione ricrei il record duplicato.