I punti chiave da prendere in considerazione
- Secondo la specifica RFC 1035, le stringhe DNS standard non possono superare i 255 caratteri.
- Le chiavi pubbliche DKIM sicure a 2048 bit hanno solitamente più di 400 caratteri, il che rende necessario suddividerle in più stringhe per i provider di hosting DNS più rigorosi.
- Un errore comune e grave consiste nel creare due record DNS distinti per i blocchi suddivisi. È invece necessario pubblicare un unico record TXT contenente entrambe le stringhe tra virgolette all'interno dello stesso identico campo di valore.
- Uno strumento gratuito lato client come PowerDMARC DNS Record Splitter esegue i calcoli in modo immediato e sicuro, senza che i tuoi dati escano mai dal browser.
Configurare l'autenticazione delle e-mail è una di quelle operazioni che sembrano richiedere solo cinque minuti, finché non ci si imbatte in un ostacolo. Si genera una chiave DKIM sicura a 2048 bit, si accede al proprio provider DNS, la si incolla nel campo di un nuovo record TXT e si clicca su "Salva".
Invece di un messaggio di conferma, sullo schermo compare un messaggio di errore. AWS Route 53 genera un avviso criptico del tipo "CharacterStringTooLong". Google Cloud DNS ti comunica semplicemente che i "dati del record non sono validi".
Se durante l'aggiunta del record DKIM ti imbatti in un limite di 255 caratteri, non preoccuparti: la tua chiave non è danneggiata e non devi ridurre il livello di sicurezza. Devi semplicemente suddividere il record TXT DKIM in più stringhe nel modo corretto. La suddivisione di un record DKIM è una procedura amministrativa standard e sicura e, una volta pubblicato, i resolver DNS ricomporranno automaticamente i frammenti senza alcuna interruzione.
Vediamo nel dettaglio perché succede e come risolvere il problema passo dopo passo, utilizzando metodi manuali o uno strumento automatico per la suddivisione dei record DNS.
Perché è necessario suddividere i record DKIM
La necessità di suddividere i record DKIM deriva dalle regole fondamentali di Internet. Ai sensi della sezione 3.3.14 della RFC 1035, una singola stringa di caratteri all'interno di un record DNS TXT è limitata a un massimo di 255 caratteri (o ottetti). Questo limite esiste perché la lunghezza di una stringa in un pacchetto DNS standard è memorizzata in un singolo byte, il che significa che non può superare i 255 caratteri.
Questo limite strutturale assume particolare rilevanza a seconda della lunghezza delle chiavi crittografiche:
- Chiavi DKIM a 1024 bit: queste stringhe di chiavi pubbliche sono brevi e solitamente rientrano perfettamente nel limite di 255 caratteri senza bisogno di modifiche.
- Chiavi DKIM a 2048 bit: queste chiavi garantiscono un livello di sicurezza notevolmente superiore, ma generano una stringa di chiave pubblica in formato Base64 che quasi sempre ha una lunghezza compresa tra 350 e oltre 500 caratteri.
Poiché una chiave DKIM a 2048 bit supera intrinsecamente la soglia dei 255 caratteri, non può essere contenuta in un'unica stringa continua.
Il modo in cui viene gestito questo limite dipende interamente dal proprio provider di hosting DNS. A partire dal 2026, le principali piattaforme si dividono ancora in due categorie:
- Fornitori rigorosi: servizi come AWS Route 53, Google Cloud DNS e Azure DNS applicano rigorosamente lo standard RFC 1035 a livello di interfaccia utente. Se si incolla una stringa di 300 caratteri, la rifiutano immediatamente.
- Fornitori automatizzati: piattaforme come Cloudflare, GoDaddy e cPanel spesso gestiscono questa formattazione in modo trasparente, suddividendo il record internamente in modo che non sia necessario farlo manualmente.
Nota importante: la suddivisione di un record non altera né compromette la firma DKIM. Quando un server di posta in entrata ricerca la chiave pubblica DKIM del tuo dominio, il suo resolver DNS ricompone automaticamente (unisce) le stringhe suddivise in un'unica stringa continua prima di elaborare la procedura di autenticazione crittografica.
Come dividere un record DKIM (passo dopo passo)
Per dividere correttamente il record senza compromettere l'integrità dei dati crittografici, è necessario seguire regole di formattazione ben definite.
Ecco un esempio in tempo reale di un record DKIM a 2048 bit non suddiviso e grezzo, ovvero una singola stringa continua che i provider più rigorosi rifiuteranno, seguito dalla stessa chiave correttamente suddivisa:
Prima – una stringa continua (410 caratteri, rifiutata):
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDDj8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB
In seguito – un record TXT, due stringhe racchiuse tra virgolette separate al limite dei 255 caratteri:
“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDD”
“j8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB”
Dividere una chiave DKIM a 2048 bit
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…wIDAQAB
Una stringa continua – 410 caratteri – che viene rifiutata da AWS Route 53 / Google Cloud DNS
↓ interruzione al limite dei 255 caratteri
Un record TXT — due stringhe tra virgolette
“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…”
blocco 1 · 255 caratteri
“…zrIZtoLuCr64CxqlIOdNKhiwIDAQAB”
blocco 2 · resto (≈155)
esattamente uno spazio tra i blocchi, senza spazi all'interno di nessuno dei due blocchi.
Passaggio 1: Individua il tuo record DKIM completo
Puoi accedere alla dashboard del tuo provider di servizi di posta elettronica (come Google Workspace, Microsoft 365, SendGrid o Mailchimp) per individuare la chiave pubblica generata. Il record inizia sempre con tag specifici, seguendo in genere esattamente questo formato:
v=DKIM1; k=rsa; p=[Una stringa Base64 molto lunga]
In alternativa, usa il nostro strumento gratuito per il controllo dei record DKIM per verificare il tuo record in pochi secondi:

Per verificare se è davvero necessario suddividere il testo, copia l'intero valore e incollalo in un semplice editor di testo per controllarne la lunghezza totale. Se il numero di caratteri supera i 255, devi suddividerlo.
Fase 2: Suddividere il valore della chiave in blocchi di 255 caratteri
Hai due possibilità per suddividere il tuo record: calcolare manualmente o utilizzare uno strumento automatizzato.
Il metodo manuale
Apri il tuo editor di testo e conta esattamente 255 caratteri dall'inizio del tuo record (compreso il prefisso v=DKIM1; k=rsa; p=). Taglia la stringa esattamente in corrispondenza di quel limite di 255 caratteri.
È necessario racchiudere ogni singolo blocco tra una coppia di virgolette doppie (“”). È fondamentale assicurarsi che non vi siano spazi all'interno dei blocchi, ma che vi sia esattamente un solo spazio a separare la virgoletta chiusa del primo blocco dalla virgoletta aperta del secondo blocco.
Il metodo automatico (consigliato)
Per evitare errori umani, evita il conteggio manuale dei caratteri e utilizza lo strumento gratuito DNS Record Splitter di PowerDMARC.
- Vai alla pagina degli strumenti.

- Incolla il tuo record TXT DKIM completo, senza frazioni, nell'area di inserimento.

- Seleziona il formato "Quoted" (richiesto da provider rigorosi come AWS e Google).

- Fai clic su " Dividi record " per generare immediatamente stringhe formattate correttamente.

- Ecco come dovrebbe apparire il risultato:

Passaggio 3: Aggiungi il record split al tuo DNS
Un errore molto comune tra gli amministratori è quello di cercare di creare due record TXT distinti nel proprio pannello DNS, uno per ogni blocco. Non farlo: comprometterebbe completamente l'autenticazione.
È necessario aggiungere un unico record TXT. Nell'interfaccia di gestione del DNS, incolla entrambe le stringhe tra virgolette nell'unico campo "Valore" o "Dati". Per la maggior parte dei provider standard, separale con un singolo spazio:
“v=DKIM1; k=rsa; p=CHUNK1” “CHUNK2”
(Nota: se utilizzi AWS Route 53, ignora il formato con spazi su una sola riga e segui il metodo di interruzione di riga specifico per la piattaforma indicato nella sezione relativa al provider qui sotto.)
Passaggio 4: Verifica del record DKIM
Una volta salvate le modifiche, attendi il tempo necessario affinché il DNS si propaghi in rete. Sebbene l'aggiornamento avvenga spesso entro 5-30 minuti, in alcuni casi può richiedere fino a 48 ore, a seconda delle impostazioni TTL (Time to Live) della tua zona.
Per assicurarti che tutto funzioni alla perfezione, usa lo strumento gratuito DKIM Lookup di PowerDMARC per verificare che il tuo record sia pubblicato e che la risoluzione avvenga correttamente.
Consiglio dell'esperto: se vuoi ricontrollare il tuo lavoro prima di attendere la propagazione del DNS, copia la stringa finale che hai creato e incollala nuovamente nello strumento di suddivisione dei record DKIM per verificare che nessuno dei segmenti superi il limite di 255 caratteri.
Se il test ha esito positivo, verrà restituita la chiave crittografica completa e unificata con stato "verde". In caso di esito negativo, verificare la presenza di problemi quali troncamenti (dati mancanti), la mancanza di un blocco secondario o errori di sintassi dovuti a virgolette non chiuse.
Suddivisione dei record DKIM in base al provider DNS
I diversi pannelli di controllo DNS gestiscono gli input TXT con più stringhe in modi diversi. Ecco come procedere alla configurazione sulle quattro piattaforme più diffuse:
AWS Route 53
Amazon Route 53 applica rigorosamente i limiti previsti e genera un errore CharacterStringTooLong se una singola stringa è priva di virgolette o supera i 255 caratteri. Poiché i resolver DNS concatenano le stringhe consecutive senza lasciare alcuno spazio tra di esse, l'inserimento di uno spazio letterale tra le virgolette su una singola riga può danneggiare accidentalmente la chiave crittografica.
- Metodo da console: nella casella "Value" della console di Route 53, inserisci ogni blocco come stringa separata racchiusa tra virgolette su una riga a sé stante. Non lasciare spazi alla fine della riga. Route 53 considera automaticamente le righe consecutive all'interno di un unico campo di testo come stringhe distinte all'interno di un unico record TXT e le unisce durante la ricerca.
- Metodo API/JSON: se si distribuisce l'infrastruttura tramite codice o l'API AWS, strutturare l'input del record come un array JSON in cui ogni blocco separato costituisce un elemento indipendente dell'array: [“v=DKIM1…”, “…CHUNK2”].
Google Cloud DNS
Google Cloud DNS visualizzerà un avviso generico relativo a "dati di record non validi" se si tenta di inviare una stringa lunga non formattata. Per risolvere il problema dall'interfaccia utente della Google Cloud Console, non incollare il testo su un'unica riga. Racchiudere invece ogni blocco tra virgolette doppie e utilizzare il pulsante "Aggiungi elemento " per generare più campi di dati sequenziali all'interno dello stesso set di record di risorse.
Cloudflare
Cloudflare dispone di un backend intelligente che analizza automaticamente le stringhe TXT di grandi dimensioni al momento del salvataggio, suddividendole in segmenti conformi alle specifiche RFC senza alcun intervento da parte dell'utente. Tuttavia, affidarsi all'analisi automatica può talvolta portare a casi limite con chiavi complesse. La pratica di implementazione consigliata rimane quella di incollare manualmente le stringhe già suddivise e racchiuse tra virgolette direttamente nella dashboard di Cloudflare.
cPanel / WHM
Le versioni precedenti dell'Editor di zone cPanel impongono un limite massimo di 255 caratteri nei campi di immissione testo standard. Se l'interfaccia principale non accetta la lunghezza della chiave, passa all'Editor di zone DNS avanzato. Questa modalità estesa offre la flessibilità strutturale necessaria per inserire senza problemi campi di dati TXT suddivisi in più parti.
Errori comuni nella suddivisione dei record DKIM
Se hai implementato il tuo record split ma i sistemi di autenticazione segnalano il tuo dominio, verifica la presenza di questi tre errori di configurazione più comuni:
1. La firma DKIM non viene generata correttamente dopo la suddivisione
- La causa: è stato inserito per errore uno spazio all'interno di uno dei tuoi blocchi crittografici base64, anziché rigorosamente tra le virgolette di apertura e chiusura.
- Soluzione: copia la chiave grezza in un file vuoto, elimina completamente tutti gli spazi interni dalla stringa del valore p= ed esegui nuovamente il processo di suddivisione.
2. Il DNS mostra solo una chiave parziale
- Il motivo: la seconda parte è stata salvata come record TXT secondario completamente separato sul server del tuo dominio, anziché essere integrata nel primo record.
- Soluzione: elimina completamente il record secondario. Modifica il tuo record TXT DKIM principale in modo che entrambe le stringhe tra virgolette siano inserite insieme all'interno del campo del valore singolo.
3. Il record supera i 255 caratteri dopo la suddivisione
- La causa: il punto di divisione è stato calcolato in modo errato, il che ha fatto sì che uno dei due blocchi superasse leggermente il limite di 255 caratteri (spesso a causa di un conteggio errato del prefisso v=DKIM1;).
- La soluzione: suddividi nuovamente il record esattamente al carattere 255, oppure lascia che sia uno strumento automatico di suddivisione dei record DNS a occuparsi del conteggio al posto tuo.
In che modo la suddivisione del DKIM influisce sul DMARC
Una preoccupazione comune tra i responsabili IT è se la suddivisione di una chiave pubblica influisca sul modo in cui il sistema DMARC gestisce i messaggi in arrivo.
Quando un record DKIM viene suddiviso correttamente, si comporta esattamente come un record non suddiviso. Poiché i server di posta in arrivo ricompongono i segmenti in un'unica stringa durante la verifica, le firme DKIM risultano valide senza problemi, senza influiresull'allineamento DMARC.
Tuttavia, se il record di suddivisione è difettoso o formattato in modo errato, le conseguenze sono immediate:
- Il server di posta in arrivo non sarà in grado di ricostruire la tua chiave pubblica.
- L'autenticazione DKIM non andrà a buon fine.
- DMARC sarà costretto a fare affidamento esclusivamente sull'allineamento SPF (Sender Policy Framework).
- Se anche l'allineamento SPF non va a buon fine (o se la tua politica DMARC richiede l'allineamento di entrambi i protocolli), le tue e-mail aziendali legittime verranno indirizzate alle cartelle dello spam o potrebbero essere respinte del tutto.
Prima di affidarti completamente all'applicazione della tua politica DMARC, devi verificare le tue chiavi DKIM pubbliche dopo aver apportato eventuali modifiche al DNS.
Riassunto
La suddivisione di un record DKIM è un'operazione amministrativa necessaria quando si gestiscono chiavi sicure a 2048 bit su provider DNS con requisiti rigorosi come AWS Route 53 o Google Cloud DNS. Si tratta di una procedura sicura e standard, facile da eseguire una volta apprese le regole di formattazione di base.
Ogni volta che aggiorni i tuoi dati, ricorda le regole fondamentali:
- Dividi la stringa al limite dei 255 caratteri.
- Racchiudi ogni porzione tra virgolette doppie.
- Inserisci tutte le informazioni in un unico record TXT (separate da uno spazio per i provider standard, oppure su righe separate per interfacce più rigide come AWS Route 53).
Non tirare a indovinare il numero di caratteri e non rischiare di compromettere il funzionamento della tua posta elettronica. Evita i calcoli manuali e imposta il tuo record in un attimo utilizzando lo strumento gratuito PowerDMARC DNS Record Splitter, senza bisogno di registrarti.
Domande frequenti
Che cos'è uno splitter di record DNS?
Uno splitter di record DNS è un'utilità progettata per suddividere un lungo record DNS TXT in singoli segmenti di 255 caratteri. Questa operazione di formattazione è necessaria affinché i record possano essere salvati correttamente presso provider di hosting DNS particolarmente rigorosi che non eseguono automaticamente la suddivisione interna delle stringhe. Il valore assoluto del record rimane del tutto invariato; viene semplicemente formattato in blocchi strutturati e più brevi che i sistemi riceventi ricompongono immediatamente al momento della ricerca.
Quali provider DNS richiedono la suddivisione manuale dei record?
Diversi importanti fornitori di soluzioni aziendali applicano rigorosamente il limite di 255 caratteri a livello di interfaccia, il che richiede di preformattare i valori di testo lunghi prima di salvarli:
- AWS Route 53: genera un messaggio di errore "CharacterStringTooLong" a meno che le stringhe lunghe non vengano suddivise in blocchi separati racchiusi tra virgolette.
- Google Cloud DNS: rifiuta completamente le stringhe lunghe e continue, generando un avviso di "dati del record non validi".
- Azure DNS: richiede la suddivisione manuale dei campi di testo quando si inseriscono stringhe direttamente tramite la dashboard di Azure Portal o Azure CLI.
- DigitalOcean: nel suo pannello di controllo web standard non suddivide automaticamente i flussi di voci TXT di grandi dimensioni.
Perché devo dividere il mio record DKIM?
Il fattore principale che determina la suddivisione di un record TXT è l'implementazione di una chiave pubblica DKIM a 2048 bit altamente sicura. Mentre le chiavi a 1024 bit sono abbastanza corte da stare all'interno di una singola stringa, una chiave a 2048 bit contiene intrinsecamente da 350 a oltre 500 caratteri di dati crittografici base64. Poiché la sezione 3.3.14 della RFC 1035 limita una singola stringa continua esattamente a 255 ottetti, queste chiavi lunghe devono essere suddivise in segmenti distinti per adattarsi all'architettura di archiviazione DNS standard.
La suddivisione del mio record potrebbe alterarne i dati o compromettere la convalida delle e-mail?
No. La suddivisione di un record TXT lungo non ne compromette né altera il valore crittografico. Quando un server di posta in entrata richiede le impostazioni di autenticazione del tuo dominio, il suo resolver DNS legge automaticamente i segmenti suddivisi e li ricompone (unisce) in un unico valore continuo senza delimitatori. La suddivisione è puramente una questione di archiviazione interna; il contenuto effettivo rimane identico.
Qual è la differenza tra i formati di output "Quoted" e "Plain"?
- Formato tra virgolette (consigliato): racchiude ogni singolo segmento di 255 caratteri tra una coppia di virgolette doppie (“chunk1” “chunk2”), separati da uno spazio su una singola riga oppure inseriti in campi/righe di dati sequenziali. Questo esatto layout è richiesto da interfacce rigorose come AWS Route 53 e Google Cloud DNS per evitare il danneggiamento delle chiavi.
- Formato semplice: suddivide le righe lunghe in blocchi separati senza aggiungere virgolette doppie o spazi o segni di punteggiatura aggiuntivi. Questo layout è pensato per i pannelli di controllo moderni che accettano flussi di stringhe multiriga non formattate o per ambienti di sistema BIND (Berkeley Internet Name Domain) in esecuzione locale.
È sicuro utilizzare questo strumento con chiavi sensibili o dati riservati?
Sì. Il PowerDMARC DNS Record Splitter funziona interamente all'interno del tuo browser web locale utilizzando script lato client. Le stringhe di testo inserite non lasciano mai il tuo dispositivo, nessun dato viene inviato via Internet a server di elaborazione esterni e non sono richiesti registri di tracciamento o registrazioni obbligatorie. Inoltre, è importante notare che lo strumento è progettato esclusivamente per configurazioni pubbliche, come chiavi DKIM pubbliche, inclusioni SPF, politiche DMARC o record di verifica del dominio, che sono già accessibili pubblicamente sul web. Le chiavi di firma private non dovrebbero mai essere incollate in nessuno strumento online.
- Come dividere un record DKIM - 5 giugno 2026
- compauth=fail: Spiegazione dell'autenticazione composita di Microsoft - 1 giugno 2026
- Windows Defender è sufficiente per la sicurezza delle piccole imprese? - 14 maggio 2026


