Nome di dominio con o senza accento: cosa cambia per le tue email

⚡TL;DR

• Mantieni l'accento per identificare il dominio: café.fr e cafe.fr sono due nomi distinti, con configurazioni indipendenti.
• Associa café.fr a xn--caf-dma.fr: sono due rappresentazioni dello stesso nome, senza una seconda registrazione da acquistare.
• Per un'email, annota il dominio dell'envelope SPF, il dominio d= di DKIM e quello dell'indirizzo From prima di confrontare i risultati.
• Verifica il nome interrogato nel DNS: vedere xn-- in un report DMARC non dimostra un problema di allineamento.

Hai configurato un dominio con accento. Qualche giorno dopo, un report email mostra un nome che inizia con xn--. Cerchi quindi un dominio sconosciuto nel tuo account, oppure togli l'accento per ritrovare una grafia più familiare. Queste due reazioni portano a errori diversi.

Nel primo caso, separi due rappresentazioni dello stesso nome. Nel secondo, sostituisci il nome con un altro. Per DNS ed email, una é non è una decorazione che puoi cancellare. café.fr corrisponde a xn--caf-dma.fr; il nome cafe.fr, senza accento, ha un'altra identità.

Questa distinzione determina in quale zona cercare le impostazioni e quali domini autenticano i destinatari. Spiega anche perché un'interfaccia leggibile e un log tecnico possono sembrare in contraddizione. I nomi citati servono soltanto a confrontare le grafie: questo articolo non descrive i loro titolari, i loro servizi o i loro record reali.

Togliere l'accento cambia il nome di dominio

café.fr e xn--caf-dma.fr indicano lo stesso nome; cafe.fr è un altro dominio. La prima coppia collega una forma Unicode, leggibile con il suo accento, alla rappresentazione ASCII. Il secondo confronto cambia la grafia. Nessun meccanismo DNS collega automaticamente le configurazioni dei nomi con e senza accento.

Due rappresentazioni dello stesso nome, ma due nomi se l'accento scompare

La forma ASCII tecnica conserva l'identità del nome accentato. Non è quindi il risultato della rimozione degli accenti. Le lettere, le cifre e i trattini di xn--caf-dma.fr rappresentano quel nome preciso, e il prefisso fa parte della grafia da mantenere. Copiare soltanto la parte finale della stringa non ha senso per ritrovare il dominio.

Durante la registrazione, questa distinzione evita di contare due volte lo stesso acquisto. Un'interfaccia può mostrarti il nome accentato durante l'ordine e poi la sua forma xn-- nel riepilogo. Le due etichette possono indicare un solo dominio registrato. Possedere il nome senza accento non ti assegna automaticamente quello con accento, né viceversa. Se vuoi usare entrambi i nomi, registrazione e configurazione vanno gestite separatamente.

Lo stesso ragionamento vale per i servizi. Un'organizzazione che controlla due nomi può scegliere lo stesso hosting DNS e lo stesso provider email. Può anche fare in modo che gli indirizzi corrispondenti consegnino i messaggi in un'unica casella di posta. Sono scelte di configurazione esplicite. La rimozione di un accento non crea quella casella, né un alias email, né una copia dei record.

Immagina due domini della tua organizzazione, uno accentato e l'altro no. Il secondo riceve già email, mentre il primo è appena stato registrato. Aggiungere un indirizzo accentato ai documenti commerciali non ne configura la ricezione. Il provider email deve conoscere questo dominio, e le impostazioni DNS devono corrispondere all'uso previsto. Il servizio esistente sull'altro nome non colma questa mancanza.

Lo schema rappresenta quindi due zone illustrative indipendenti. Questo non impone due provider né due server fisici: la stessa infrastruttura può ospitare più zone. L'indipendenza riguarda i nomi e i loro dati. Una modifica applicata a uno non si propaga all'altro per somiglianza ortografica.

Il nome che trovi nella zona DNS e nei log

La forma xn-- offre un riferimento comune per collegare una zona DNS, un log e un'interfaccia che mostra l'accento. Identifica il nome internazionalizzato senza cambiarne il dominio.

In una console DNS, il titolo della zona può essere visualizzato in Unicode. Un'esportazione o un log delle query può usare la forma ASCII. Prima di cercare un record mancante, confronta i nomi completi. Potresti aver aperto la zona giusta con una presentazione diversa, oppure una zona realmente differente il cui nome ha perso l'accento.

Il nome della zona e quello di un record non vengono sempre visualizzati insieme. Alcune console richiedono un nome relativo e aggiungono la zona corrente. In una zona fittizia example.com, inserire _dmarc può quindi indicare _dmarc.example.com. La breve etichetta _dmarc sembra identica in due console; il nome completo dipende però dalla zona aperta. È quel nome completo a indicare quale policy hai modificato.

Un esempio di documentazione, senza valori ricavati da un dominio di terzi, rende visibile la differenza:

Zona aperta: example.com
Nome relativo: _dmarc
Nome completo: _dmarc.example.com
Tipo richiesto: TXT

Applica questa lettura ai tuoi nomi con accento. Se l'interfaccia mostra la zona in Unicode e il nome completo in ASCII, verifica che corrispondano prima di creare una seconda voce. Aggiungere un record per correggere una semplice differenza di visualizzazione può introdurre un duplicato; pubblicarlo nel dominio senza accento lascerebbe invariata la zona prevista.

Anche il contenuto di un log richiede un po' di contesto. Il nome interrogato, il tipo richiesto e la risposta ricevuta descrivono un'operazione precisa. L'assenza di un TXT non significa automaticamente che il dominio non esista. Un errore di risoluzione non indica che l'accento sia stato rifiutato. Conserva il nome esatto e il risultato: sostituirli con un'approssimazione rende la diagnosi meno affidabile.

Per una richiesta di assistenza, includi la grafia inserita e la forma ASCII corrispondente, poi il nome completo del record interessato. Aggiungi la data dell'osservazione se hai appena modificato la zona. Queste informazioni distinguono una confusione di nomi da una vecchia risposta ancora in cache. Nessuna attesa farà comparire una correzione in una zona che non hai modificato.

Infine, convertire un nome non interroga il DNS. La conversione può produrre una forma ASCII corretta senza dimostrare che il dominio sia registrato, abbia una zona pubblicata o riceva email. Queste domande richiedono controlli distinti. Saper scrivere una destinazione non dimostra che un servizio vi risponda.

SPF, DKIM e DMARC: verificare il dominio giusto per le tue email

I controlli email usano più identità di dominio, la cui grafia dipende dalla fase di elaborazione. La RFC 8616 specifica separatamente le regole per DNS, SPF, DKIM e DMARC. Confondere queste fasi può portarti a cercare una chiave nella zona sbagliata o a modificare un'intestazione che avresti dovuto conservare.

Per seguire il testo della RFC, sono utili due termini. Un U-label è la forma Unicode di una parte internazionalizzata del nome, come café. Il suo A-label è la rappresentazione ASCII corrispondente, qui xn--caf-dma. I punti separano le parti del dominio; fr non cambia. Questi termini descrivono due rappresentazioni, mai due registrazioni di dominio da acquistare.

I nomi interrogati nel DNS

La sezione 3 della RFC 8616 mantiene in ASCII le stringhe memorizzate nei record DNS usati da questi protocolli. Un nome recuperato da un'intestazione viene convertito prima della ricerca DNS se contiene U-labels. Il software che consulta un record non può presumere che la risposta venga letta soltanto da un sistema di posta con intestazioni internazionalizzate.

Questa regola non descrive il formato di tutti i campi di un'email. Delimita i dati pubblicati e la ricerca DNS. Lo stesso messaggio può contenere un indirizzo leggibile in Unicode e attivare una query che usa il nome ASCII corrispondente. In questa fase non cambiano né titolare né destinazione.

Quando leggi una configurazione, separa il nome del record dal suo valore. Il primo risponde a "dove cercare?"; il secondo contiene la policy o la chiave. Un testo SPF perfettamente formato, salvato sotto il nome sbagliato, non sarà quello consultato dal destinatario. Non basta nemmeno avere una chiave DKIM da qualche parte nell'account DNS: la sua posizione deve corrispondere al dominio e al selettore della firma.

Ecco le posizioni di uno scenario interamente fittizio con example.com. La tabella descrive nomi da interrogare senza fornire una configurazione da copiare.

Controllo	Identità dello scenario	Nome DNS associato
SPF	Dominio dell'envelope example.com	example.com, tipo TXT
DKIM	d=example.com, selettore s=septembre	septembre._domainkey.example.com, tipo TXT
DMARC	Indirizzo From sotto example.com	_dmarc.example.com, tipo TXT

Nel tuo sistema di posta, questi domini possono essere diversi. Un provider può gestire il dominio dell'envelope o firmare con il proprio dominio. Inizia quindi annotando le identità effettivamente usate in un messaggio ricevuto. Cercare soltanto il nome visualizzato in cima alla console non risponde necessariamente alla domanda posta da ciascun protocollo.

SPF e il dominio dell'envelope

La sezione 4 impone la conversione di ogni U-label in A-label prima della validazione SPF. Il dominio presentato in EHLO deve già usare A-labels; quello di MAIL FROM può adottare l'una o l'altra forma in uno scambio internazionalizzato. La conversione si applica anche ai nomi usati dalle espansioni delle macro SPF, non soltanto alla prima ricerca.

SPF esamina identità della sessione SMTP. EHLO presenta il server che invia; MAIL FROM contiene l'indirizzo dell'envelope, usato in particolare per i messaggi di errore restituiti al mittente. Questo indirizzo è distinto dall'indirizzo From che il lettore vede nel client di posta. Un dominio configurato per la visualizzazione non diventa quindi automaticamente quello controllato da SPF.

Perché EHLO deve usare la forma ASCII fin dall'inizio? Questo comando precede la risposta che annuncia se il server accetta l'estensione necessaria alla posta internazionalizzata. Il software di invio non dispone ancora di questa informazione. Il formato imposto a questo punto non determina quello possibile nelle fasi successive.

In uno scenario fittizio, una piattaforma invia per example.com con un envelope sotto resi.example.com. Il TXT SPF da esaminare è quello del dominio dell'envelope utilizzato, non un TXT scelto perché compare nella pagina iniziale del sito. Se la piattaforma usa un dominio internazionalizzato, la stessa ricerca adotta la sua forma ASCII dopo la conversione. Il protocollo non prova poi il dominio privato dell'accento come soluzione di ripiego.

Per comprendere un risultato SPF, identifica quindi l'identità verificata prima di leggere i dettagli della policy. Un pass indica che l'indirizzo IP era autorizzato per l'identità valutata. Non certifica che questa identità sia quella dell'indirizzo From, né che l'intero sistema di posta sia configurato correttamente. Il confronto con From spetta a DMARC.

Anche i nomi internazionalizzati citati all'interno di un record SPF devono essere scritti in A-labels. Un'interfaccia di amministrazione che accetta l'accento nel nome della zona non autorizza a inserirlo liberamente nel valore TXT. Il campo in cui si digita il dominio e il contenuto pubblicato svolgono funzioni diverse.

Quando amministri entrambi i nomi, con e senza accento, evita di copiare automaticamente le policy. Gli stessi server possono essere autorizzati per entrambi, ma soltanto se i flussi di posta lo giustificano. Un dominio usato solo per la ricezione non ha necessariamente le stesse esigenze di un dominio di invio. La somiglianza dei nomi non è un inventario dei tuoi mittenti.

DKIM e i valori firmati

La sezione 5 distingue i messaggi tradizionali da quelli con intestazioni internazionalizzate. Per i nomi internazionalizzati di d=, della parte di dominio di i= e di s=, gli A-labels sono obbligatori nei messaggi tradizionali: la RFC usa MUST. Con intestazioni internazionalizzate, gli U-labels sono raccomandati (SHOULD), mentre gli A-labels restano validi.

Questi tag non hanno tutti la stessa funzione. d= indica il dominio firmatario, s= il selettore che individua la chiave e i=, quando presente, un'identità composta da una parte locale e una parte di dominio. Nell'esempio fittizio i=service@example.com, soltanto example.com è il dominio. La regola sulla sua grafia non significa che service sia un nome da convertire nello stesso modo.

La verifica DKIM comprende una ricerca della chiave pubblica nel DNS e un calcolo crittografico sul messaggio. Le due operazioni non seguono la stessa regola di trasformazione. Il nome di ricerca deve adottare la forma attesa dal DNS. Per calcolare o verificare l'hash, invece, la RFC richiede di usare il dominio così come è scritto nell'intestazione, con le regole di canonicalizzazione DKIM applicabili.

Questa distinzione esclude una correzione allettante: sostituire ovunque i nomi Unicode con la loro forma ASCII in un'email originale prima di verificarne la firma. Anche se i nomi designano lo stesso dominio, la loro rappresentazione nei dati firmati non è identica. L'equivalenza dei nomi non rende intercambiabili due sequenze di byte per il calcolo crittografico.

Supponiamo che un messaggio con intestazioni internazionalizzate contenga un dominio firmatario in Unicode. Il verificatore trova la chiave con il nome ASCII corrispondente, poi controlla la firma conservando la rappresentazione dell'intestazione. Un'interfaccia può mostrare le due grafie affiancate per aiutare l'amministratore. Questa visualizzazione non autorizza a modificare il messaggio originale.

Per la diagnosi, conserva quindi una copia del messaggio ricevuto nel suo formato originale. Uno screenshot in cui il client ha riformattato gli indirizzi facilita la lettura, ma non riproduce necessariamente i valori usati per la firma. Annota d= e s= nell'intestazione DKIM, poi cerca la chiave nella posizione costruita a partire da quei valori. Una chiave pubblicata per il nome senza accento non diventa quella del dominio accentato.

Il selettore merita la stessa attenzione del dominio. Due invii dallo stesso dominio possono usare selettori diversi; trovare una chiave con uno non convalida la firma effettuata con l'altro. Nello scenario example.com, septembre._domainkey.example.com e archives._domainkey.example.com sono due posizioni. L'errore sarebbe quindi un selettore sbagliato, anche se la grafia del dominio fosse corretta.

DMARC e il dominio visibile in From

La sezione 6 richiede di convertire in A-labels tutti gli U-labels del dominio dell'indirizzo From prima di proseguire l'elaborazione DMARC. Mantiene inoltre indirizzi convenzionali nei tag di report rua e ruf. Quest'ultima regola riguarda le destinazioni dei report, non la grafia consentita in ogni parte del messaggio.

Il punto di partenza è il dominio dell'indirizzo From, dopo la chiocciola. Il nome visualizzato della persona, per esempio "Gruppo commerciale", non viene usato in questo confronto. Un accento può comparire in questa etichetta anche se l'indirizzo non contiene alcun dominio internazionalizzato. Aprire i dettagli del mittente evita di analizzare l'elemento sbagliato.

DMARC cerca un'autenticazione SPF o DKIM riuscita e allineata con questo dominio From. L'allineamento rigoroso confronta i domini esatti; quello rilassato considera il dominio organizzativo. Una differenza di sottodominio può quindi essere ammessa a seconda della modalità scelta. La rimozione di un accento non è una regola di allineamento rilassato: non trasforma due nomi indipendenti in uno solo.

Nel confronto di questo articolo, café.fr e xn--caf-dma.fr possono corrispondere durante l'elaborazione dei nomi. cafe.fr resta distinto. Possedere entrambi i domini, usare lo stesso server o mostrare lo stesso nome aziendale non cambia questa relazione. Se il tuo mittente deve usare il nome accentato ma firma per l'altro, correggi la configurazione del flusso interessato.

Per i report, una destinazione di documentazione come rua=mailto:rapports@example.com mostra il formato di un indirizzo convenzionale. Se il dominio destinatario è internazionalizzato, la parte di dominio usa la forma ASCII; aggiungere un accento alla parte locale non rispetta la regola della sezione 6. L'indirizzo deve anche poter ricevere i report. La sua sintassi non crea una casella.

Considera infine il caso che spesso fa nascere il dubbio: hai configurato il nome accentato, poi un report DMARC o l'intestazione Authentication-Results mostra xn--caf-dma.fr. La corrispondenza con l'interfaccia può essere del tutto corretta. Individua il campo che contiene quel valore, poi leggi il risultato associato: il dominio From, il dominio SPF e il dominio firmatario non sono intercambiabili.

Se i nomi corrispondono dopo la conversione, prosegui con le cause indicate dai risultati: IP non autorizzato, chiave non trovata, firma non valida o identità autenticata realmente diversa dal dominio From. Non riscrivere la policy a causa del solo prefisso. Vedere xn-- al posto dell'accento non è di per sé un errore di allineamento.

Cosa verificano gli strumenti quando inserisci café.fr

La ricerca DNS e il controllo DMARC di CaptainDNS accettano café.fr e interrogano la sua forma ASCII. Per DMARC, il nome di ricerca è _dmarc.xn--caf-dma.fr. La ricerca DNS mostra l'Unicode accanto a questa forma. Il controllo DMARC mostra il nome interrogato in ASCII. Questi nomi illustrano l'elaborazione dell'input, senza presentare risultati reali su questo dominio di terzi.

La ricerca risponde a una domanda sulla pubblicazione DNS: quali record vengono restituiti per il nome e il tipo richiesti? Il controllo DMARC si concentra sulla policy pubblicata e sulla sua sintassi. Aiutano a verificare la zona giusta, ma un TXT DMARC valido non dimostra che ogni piattaforma di invio firmi i tuoi messaggi con il dominio corretto.

Questo limite conta quando cambi provider. Puoi aver pubblicato esattamente il valore richiesto e continuare a ricevere esiti negativi per alcune email. La piattaforma che le invia potrebbe ancora usare una vecchia identità. Confronta allora la pubblicazione DNS e le intestazioni di un messaggio inviato da quella piattaforma. Il controllo del dominio e la verifica del messaggio si completano; non osservano la stessa cosa.

Anche un risultato vuoto va letto insieme al nome richiesto. Se hai inserito il dominio senza accento, lo strumento ha esaminato quel nome distinto. Se hai inserito il dominio corretto, l'assenza di un record richiede di esaminarne la pubblicazione. In entrambi i casi, la prima verifica resta l'identità della zona, prima di modificare qualsiasi valore.

Per confrontare soltanto le rappresentazioni del nome, il Convertitore Punycode / IDN fornisce le due forme senza consultare il DNS. Per conoscere i dati pubblicati dal registro, puoi consultare la registrazione del dominio con RDAP. RDAP non convalida né SPF né DMARC: una scheda di registrazione descrive il dominio registrato, non il corretto funzionamento delle sue email.

Una tabella di caratteri latini sotto .fr

La politica di denominazione Afnic ammette una tabella di caratteri latini, comprese le lettere accentate, ma non il cirillico sotto .fr. In questo confronto tra un nome accentato e la sua grafia senza accento, l'unico nome simile considerato è quello ASCII privo di accento, che resta distinto; questo confronto non protegge da altre somiglianze visive. Per nomi ingannevoli e link sospetti al di fuori di questo caso, consulta i nostri articoli per riconoscere un'email di phishing ed esaminare reindirizzamenti e link sospetti.

Un accento prima della chiocciola è un altro argomento

Nell'esempio fittizio élise@example.com, l'accento appartiene alla parte locale che identifica la casella; non si converte come un dominio. L'internazionalizzazione degli indirizzi email (EAI) distingue lo scambio con un indirizzo internazionalizzato dalla creazione di quella casella presso un provider. Gmail consente l'invio verso questi indirizzi e la ricezione da essi, ma le sue regole per creare nomi utente escludono lettere accentate. Per Microsoft 365, Exchange Online annuncia questi scambi con indirizzi internazionalizzati, mentre le regole di creazione degli utenti escludono accenti nell'indirizzo. La possibilità di transito non autorizza quindi a creare una casella accentata presso questi provider e non garantisce la compatibilità di ogni intermediario.

Anche il certificato usa la forma ASCII del dominio

Il campo dNSName dell'estensione SAN di un certificato contiene la forma ASCII del dominio internazionalizzato. La RFC 5280, sezione 7.2, impone questo formato per memorizzare il nome. Vedere xn-- nei dettagli di un certificato può quindi corrispondere al dominio che il browser mostra con il suo accento.

Un certificato che copre il nome accentato non copre automaticamente il nome senza accento. Se un servizio deve presentare entrambe le identità, i nomi coperti devono soddisfare questa esigenza. Il principio è lo stesso delle email: una somiglianza ortografica non sostituisce una configurazione esplicita.

La CSR, o richiesta di firma del certificato, serve a esaminare i nomi richiesti prima dell'emissione. Non dimostra quali nomi compaiano poi nel certificato installato. Durante una diagnosi, distingui quanto richiesto da ciò che il server presenta davvero: a una CSR corretta può aver fatto seguito l'installazione di un altro certificato.

Il parser CaptainDNS segnala come non valida una forma Unicode non convertita in un SAN dNSName e mostra l'Unicode accanto a una forma xn-- corretta. Puoi esaminare i nomi del certificato nella CSR per verificare questa grafia. Il controllo riguarda la richiesta e non consente conclusioni sulle impostazioni SPF o DMARC del dominio.

Cosa non tratta questo articolo

Questo articolo aiuta a identificare il dominio a cui appartengono le tue impostazioni DNS ed email. Non sviluppa un tutorial di conversione, una guida ai link ingannevoli o una procedura di configurazione HTTP. Le pagine collegate trattano queste esigenze separatamente.

L'internazionalizzazione completa delle caselle di posta richiede anche verifiche diverse da quelle sul dominio. Qui il risultato cercato resta concreto: sapere se due rappresentazioni indicano lo stesso nome, trovarne la zona e poi confrontare le identità effettivamente utilizzate dal mittente. Conserva le intestazioni originali quando il problema riguarda una firma.

FAQ

Un nome di dominio con accento è lo stesso di quello senza accento?

No. Togliere l'accento cambia il dominio: café.fr e cafe.fr sono distinti. Invece, café.fr e xn--caf-dma.fr sono due rappresentazioni dello stesso nome.

Devo registrare separatamente il dominio con accento e quello senza accento?

Sì, se vuoi possedere entrambi i nomi e sono disponibili per la registrazione. Acquistarne uno non assegna automaticamente l'altro. Le forme Unicode e xn-- dello stesso dominio corrispondono invece a una sola registrazione.

Perché il mio report DMARC mostra xn-- anche se ho configurato il nome con accento?

Il report può mostrare la rappresentazione ASCII del dominio internazionalizzato configurato. Confronta i nomi dopo la conversione, poi leggi i risultati SPF, DKIM e il loro allineamento con From. Il prefisso da solo non indica un errore.

Le impostazioni SPF, DKIM e DMARC del dominio senza accento coprono anche quello accentato?

No, questi nomi hanno configurazioni indipendenti. Puoi configurare gli stessi servizi per entrambi, ma le pubblicazioni DNS e le identità di invio devono corrispondere a ciascun dominio. Togliere l'accento non crea alcuna condivisione automatica.

Posso inserire il mio dominio con accento in uno strumento di verifica DNS o DMARC?

Sì, nella ricerca DNS e nel controllo DMARC di CaptainDNS: accettano questa digitazione e interrogano la forma ASCII corrispondente. Verifica il nome completo visualizzato nel risultato. Un controllo DNS riuscito non sostituisce l'analisi di un messaggio inviato.

Un accento nel dominio di un indirizzo email equivale a un accento prima della chiocciola?

No. Dopo la chiocciola, l'accento appartiene al dominio, che ha una rappresentazione ASCII. Prima della chiocciola, appartiene alla parte locale della casella e dipende da EAI e dalle capacità del provider email.

Quale forma del dominio va usata nel certificato?

Il SAN dNSName usa la forma ASCII del dominio internazionalizzato. Un software può mostrare l'Unicode accanto per facilitarne la lettura. Verifica separatamente i nomi richiesti nella CSR e quelli del certificato installato.

Fonti

• RFC 8616 - regole DNS, SPF, DKIM e DMARC per la posta internazionalizzata, sezioni da 3 a 6.
• Afnic - politica di denominazione del 6 luglio 2026, articolo 2.2, caratteri ammessi.
• RFC 5280 - nomi internazionalizzati nel campo dNSName dei certificati, sezione 7.2.
• Guida di Gmail - caratteri consentiti nella creazione di un nome utente.
• RFC 9989 - domini autenticati e allineamento DMARC, sezione 4.4.