Record TXT DNS: verifiche, email e servizi esterni

Questa guida approfondisce record TXT DNS con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.

Che cosa significa

Il provider fornisce normalmente nome host e valore. Inserire il dominio completo in un pannello che lo aggiunge automaticamente può creare un nome duplicato.

Alcune interfacce mostrano virgolette o dividono valori lunghi in più stringhe; il resolver può comunque restituirli come un unico contenuto logico.

Come riconoscere il problema

• La verifica dominio fallisce.
• Il TXT appare sul nome sbagliato.
• SPF restituisce permerror.
• DKIM non viene trovato.
• Due record contengono policy incompatibili.

Cause più frequenti

1. Nome host errato

Il pannello aggiunge nuovamente il dominio. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

2. Zona non autoritativa

Il record viene creato nel provider sbagliato. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

3. Valore copiato male

Spazi, virgolette o caratteri mancanti alterano il token. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

4. Record SPF multipli

Più TXT che iniziano con v=spf1 rendono SPF non valido. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

5. Selector DKIM errato

Il nome non corrisponde alla firma. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

6. Cache DNS

Il servizio vede ancora il valore precedente. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

Diagnosi passo per passo

1. Identifica la zona autoritativa. Controlla i nameserver. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
2. Copia nome e valore separatamente. Non adattarli senza comprendere il pannello. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
3. Interroga il nome esatto. Usa `dig nome TXT +short`. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
4. Controlla duplicati. In particolare SPF e DMARC. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
5. Verifica TTL. Stima quando il vecchio valore scadrà. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
6. Confronta resolver. Controlla risposta pubblica. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
7. Usa il test del provider. Solo dopo che il DNS restituisce il valore corretto. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.

Metodo sicuro di intervento

Prima di modificare la configurazione, registra lo stato iniziale: indirizzo o funzione coinvolta, messaggio completo, data e ora, ultima modifica nota e risultato da un secondo dispositivo, rete o strumento. Una diagnosi ripetibile è più utile di molti tentativi eseguiti contemporaneamente.

Applica una sola correzione alla volta e conserva una copia dei file, dei record o dei valori precedenti. Dopo ogni intervento ripeti esattamente il test originale e controlla i log relativi allo stesso intervallo temporale. Se il risultato cambia, annota quale modifica lo ha prodotto.

Evita disattivazioni globali di firewall, WAF, TLS, cache o sistemi di sicurezza. Quando serve una eccezione, deve essere limitata all’URL, al parametro, al processo o al servizio realmente interessato.

Procedura di risoluzione

1. Crea il TXT nel pannello autoritativo. Usa il nome richiesto. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
2. Rimuovi duplicazioni. Unisci autorizzazioni SPF nell’unico record. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
3. Correggi selector e prefissi. DKIM e DMARC usano nomi specifici. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
4. Conserva il valore esatto. Non aggiungere virgolette se il pannello le gestisce. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
5. Attendi il TTL. Non ripetere la verifica mentre il vecchio record è ancora in cache. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
6. Rimuovi token obsoleti. Dopo aver confermato che il servizio non li usa. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
7. Documenta lo scopo. Evita che record sconosciuti vengano eliminati in futuro. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.

Controlli finali

• TXT pubblico corretto.
• Provider conferma verifica.
• Un solo SPF.
• DKIM e DMARC sui nomi corretti.
• Nessun token obsoleto necessario.

Prevenzione

• Documenta ogni TXT.
• Controlla nameserver.
• Non duplicare SPF.
• Conserva selector.
• Rimuovi verifiche dismesse con cautela.

Errori da evitare

• Non creare record nel pannello sbagliato.
• Non aggiungere dominio due volte.
• Non dividere manualmente valori senza necessità.
• Non eliminare TXT sconosciuti senza analisi.
• Non pubblicare token privati diversi da quelli previsti per DNS.

Come documentare la verifica

Conserva una breve nota con configurazione iniziale, risultato di ogni controllo e modifica applicata. Inserisci sempre data e ora, perché cache, log, code, rate limit e processi pianificati possono cambiare nel tempo. Questa documentazione facilita il rollback e permette all’assistenza di evitare verifiche già eseguite.

Quando confronti due test, usa le stesse condizioni: stesso URL o destinatario, stesso file, stesso client e stessa rete quando possibile. Se cambi più variabili, il risultato non permette di individuare con certezza la causa.

Controllo incrociato

Dopo la correzione esegui almeno un controllo indipendente. Per un sito confronta browser, risposta HTTP e log; per DNS interroga autoritativo e resolver pubblico; per la posta confronta Webmail, intestazioni e Track Delivery; per PHP verifica il valore effettivamente applicato al dominio. Un solo indicatore può essere influenzato da cache o configurazioni locali.

Se il problema ricompare, evita ulteriori modifiche e raccogli nuovamente i dati. La ricorrenza può indicare un processo pianificato, un limite raggiunto, una dipendenza esterna o una configurazione che viene rigenerata automaticamente.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:

• nome host
• valore oscurato se sensibile
• nameserver
• output dig
• servizio

Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.

Fonti tecniche ufficiali

• IETF RFC 1035: DNS TXT
• cPanel Zone Editor

Domande frequenti su record TXT DNS