Nome de domínio com ou sem acento: o que muda nos seus emails

⚡TL;DR

• Mantenha o acento para identificar o domínio: café.fr e cafe.fr são dois nomes distintos, com definições independentes.
• Relacione café.fr com xn--caf-dma.fr: são duas representações do mesmo nome, sem um segundo registo a comprar.
• Num email, anote o domínio do envelope SPF, o domínio d= de DKIM e o da linha From antes de comparar os resultados.
• Verifique o nome consultado no DNS: ver xn-- num relatório DMARC não comprova um problema de alinhamento.

Configurou um domínio com acento. Alguns dias depois, um relatório de email apresenta um nome que começa por xn--. Procura então um domínio desconhecido na sua conta, ou retira o acento para encontrar uma escrita mais familiar. Estas duas reações conduzem a erros diferentes.

No primeiro caso, separa duas representações do mesmo nome. No segundo, substitui o nome por outro. Para o DNS e o email, um é não é um adorno que se possa apagar. café.fr corresponde a xn--caf-dma.fr; o nome cafe.fr, sem acento, tem outra identidade.

Esta distinção determina a zona onde deve procurar as suas definições e os domínios que os destinatários autenticam. Também explica por que motivo uma interface legível e um registo técnico podem parecer contraditórios. Os nomes acima servem apenas para comparar escritas: este artigo não descreve os seus titulares, os seus serviços nem os seus registos reais.

Retirar o acento muda o nome de domínio

café.fr e xn--caf-dma.fr designam o mesmo nome; cafe.fr é outro domínio. O primeiro par associa uma forma Unicode, legível com o seu acento, à representação ASCII correspondente. A segunda comparação altera a grafia. Nenhum mecanismo DNS liga automaticamente as definições dos nomes com e sem acento.

Duas representações do mesmo nome, mas dois nomes se o acento desaparecer

A forma ASCII técnica conserva a identidade do nome acentuado. Não resulta, por isso, da remoção dos acentos. As letras, os algarismos e os hífenes de xn--caf-dma.fr representam esse nome preciso, e o prefixo faz parte da escrita a conservar. Copiar apenas o final desta sequência não faz sentido para encontrar o domínio.

No momento do registo, esta distinção evita contar duas vezes a mesma compra. Uma interface pode apresentar o nome acentuado durante a encomenda e depois a forma xn-- no resumo. As duas indicações podem designar um único domínio registado. Deter o nome sem acento não atribui automaticamente o nome com acento, nem o inverso. Se pretende utilizar ambos os nomes, o registo e a configuração são tratados separadamente.

O mesmo raciocínio aplica-se aos serviços. Uma organização que controla dois nomes pode escolher o mesmo fornecedor de alojamento DNS e o mesmo fornecedor de email. Pode até fazer com que os endereços correspondentes entreguem as mensagens numa única caixa de correio. São escolhas de configuração explícitas. Retirar um acento não cria essa caixa, nem um alias de email, nem uma cópia dos registos.

Imagine dois domínios da sua organização, um acentuado e outro não. O segundo já recebe emails, enquanto o primeiro acaba de ser registado. Acrescentar um endereço acentuado aos seus documentos comerciais não configura a sua receção. O fornecedor de email tem de conhecer esse domínio, e as definições DNS devem corresponder à utilização prevista. A existência do serviço no outro nome não preenche esta lacuna.

O esquema representa, por isso, duas zonas ilustrativas independentes. Isto não exige dois fornecedores nem dois servidores físicos: a mesma infraestrutura pode alojar várias zonas. A independência diz respeito aos nomes e aos respetivos dados. Uma alteração aplicada a um não se propaga ao outro por semelhança ortográfica.

O nome que encontra na zona DNS e nos registos de atividade

A forma xn-- fornece uma referência comum para relacionar uma zona DNS, um registo de atividade e uma interface que apresenta o acento. Identifica o nome internacionalizado sem alterar o seu domínio.

Numa consola DNS, o título da zona pode ser apresentado em Unicode. Uma exportação ou um registo de consultas pode utilizar a forma ASCII. Antes de procurar um registo em falta, compare os nomes completos. Pode ter aberto a zona certa com uma apresentação diferente, ou uma zona realmente distinta cujo nome perdeu o acento.

O nome da zona e o nome de um registo nem sempre aparecem juntos. Algumas consolas esperam um nome relativo e acrescentam a zona atual. Numa zona fictícia example.com, introduzir _dmarc pode, assim, designar _dmarc.example.com. A pequena etiqueta _dmarc parece idêntica em duas consolas; no entanto, o nome completo depende da zona aberta. É esse nome completo que permite saber qual foi a política alterada.

Um exemplo de documentação, sem valores provenientes de um domínio de terceiros, torna a diferença visível:

Zona aberta: example.com
Nome relativo: _dmarc
Nome completo: _dmarc.example.com
Tipo procurado: TXT

Aplique esta leitura aos seus próprios nomes com acento. Se a interface apresentar a zona em Unicode e o nome completo em ASCII, verifique a correspondência antes de criar uma segunda entrada. Acrescentar um registo para corrigir uma simples diferença de apresentação pode introduzir um duplicado; publicar no domínio sem acento deixaria a zona pretendida inalterada.

O conteúdo de um registo de atividade também exige algum contexto. O nome consultado, o tipo pedido e a resposta recebida descrevem uma operação concreta. A ausência de TXT não significa automaticamente que o domínio não existe. Um erro de resolução não indica que o acento tenha sido rejeitado. Conserve o nome exato e o resultado: substituí-los por uma aproximação torna o diagnóstico menos fiável.

Num pedido de apoio, inclua a escrita introduzida e a forma ASCII correspondente, seguidas do nome completo do registo em causa. Acrescente a data da observação se acabou de alterar a zona. Estes dados distinguem uma confusão de nomes de uma resposta antiga ainda em cache. Nenhum tempo de espera fará aparecer uma correção numa zona que não foi alterada.

Por fim, converter um nome não consulta o DNS. A conversão pode produzir uma forma ASCII correta sem demonstrar que o domínio está registado, possui uma zona publicada ou recebe emails. Estas questões exigem verificações distintas. Saber escrever um destino não prova que um serviço responda nesse local.

SPF, DKIM e DMARC: verificar o domínio certo para os seus emails

As verificações de email utilizam várias identidades de domínio, cuja escrita depende da etapa de processamento. A RFC 8616 especifica separadamente as regras do DNS, SPF, DKIM e DMARC. Confundir estas etapas pode levar a procurar uma chave na zona errada ou a alterar um cabeçalho que devia ser conservado.

Para acompanhar o texto da RFC, são úteis dois termos. Um U-label é a forma Unicode de uma parte internacionalizada do nome, como café. O respetivo A-label é a representação ASCII correspondente, aqui xn--caf-dma. Os pontos separam as partes do domínio; fr não muda. Este vocabulário descreve duas representações, nunca dois registos de domínio a contratar.

Os nomes consultados no DNS

A secção 3 da RFC 8616 mantém em ASCII as sequências de caracteres guardadas nos registos DNS utilizados por estes protocolos. Um nome obtido num cabeçalho é convertido antes da consulta DNS se contiver U-labels. O software que consulta um registo não pode presumir que a resposta será lida apenas por um sistema de email com cabeçalhos internacionalizados.

Esta regra não descreve o formato de todos os campos de um email. Delimita os dados publicados e a consulta DNS. A mesma mensagem pode conter um endereço legível em Unicode e desencadear uma consulta com o nome ASCII correspondente. Nesta etapa, não há mudança de titular nem de destino.

Ao ler uma configuração, separe o nome do registo do seu valor. O primeiro responde a "onde procurar?"; o segundo contém a política ou a chave. Um texto SPF perfeitamente formado, guardado sob o nome errado, não será aquele que o destinatário irá consultar. Também não basta haver uma chave DKIM algures na sua conta DNS: a posição deve corresponder ao domínio e ao seletor da assinatura.

Seguem-se as localizações de um cenário inteiramente fictício com example.com. Esta tabela descreve nomes a consultar, sem fornecer uma configuração para copiar.

Verificação	Identidade do cenário	Nome DNS associado
SPF	Domínio do envelope example.com	example.com, tipo TXT
DKIM	d=example.com, seletor s=septembre	septembre._domainkey.example.com, tipo TXT
DMARC	Endereço From em example.com	_dmarc.example.com, tipo TXT

No seu sistema de email, estes domínios podem ser diferentes. Um prestador pode gerir o domínio do envelope ou assinar com o seu próprio domínio. Comece, por isso, por anotar as identidades efetivamente utilizadas numa mensagem recebida. Procurar apenas o nome apresentado no topo da consola nem sempre responde à questão colocada por cada protocolo.

SPF e o domínio do envelope

A secção 4 impõe a conversão de todos os U-labels em A-labels antes da validação SPF. O domínio apresentado em EHLO já deve estar em A-labels; o de MAIL FROM pode utilizar qualquer uma das formas numa troca internacionalizada. A conversão também se aplica aos nomes utilizados pelas expansões de macros SPF, não apenas à primeira consulta.

SPF examina identidades da sessão SMTP. EHLO apresenta o servidor que envia; MAIL FROM contém o endereço do envelope, utilizado nomeadamente para devoluções por erro. Este último é distinto do endereço From que o leitor vê no seu programa de email. Um domínio configurado para apresentação não passa, portanto, a ser automaticamente o domínio verificado por SPF.

Por que razão tem EHLO de usar a forma ASCII desde o início? Este comando precede a resposta que anuncia se o servidor aceita a extensão necessária ao correio internacionalizado. O software de envio ainda não dispõe dessa informação. O formato imposto nessa fase não determina o formato possível nas etapas seguintes.

Num cenário fictício, uma plataforma envia por example.com com um envelope em devolucoes.example.com. O TXT SPF a examinar é o do domínio do envelope utilizado, e não um TXT escolhido por aparecer na página inicial do site. Se a plataforma utilizar um domínio internacionalizado, a mesma consulta assume a sua forma ASCII após a conversão. O protocolo não tenta depois o domínio sem acento como alternativa de recurso.

Para compreender um resultado SPF, identifique primeiro a identidade testada e só depois leia os pormenores da política. Um pass indica que o endereço IP foi autorizado para a identidade avaliada. Não certifica que essa identidade seja a do endereço From, nem que todo o sistema de email esteja corretamente configurado. A comparação com From cabe a DMARC.

Os nomes internacionalizados mencionados dentro de um registo SPF também têm de ser escritos em A-labels. Uma interface de administração que aceita o acento no nome da zona não autoriza a sua introdução livre no valor TXT. O campo de introdução do domínio e o conteúdo publicado têm funções distintas.

Quando administra ambos os nomes, com e sem acento, evite copiar automaticamente as políticas. Os mesmos servidores podem estar autorizados para os dois, mas apenas se os fluxos o justificarem. Um domínio utilizado só para receção não tem necessariamente as mesmas necessidades que um domínio de envio. A semelhança dos nomes não constitui um inventário dos seus remetentes.

DKIM e os valores assinados

A secção 5 distingue as mensagens convencionais das mensagens com cabeçalhos internacionalizados. Para os nomes internacionalizados de d=, da parte de domínio de i= e de s=, os A-labels são obrigatórios em mensagens convencionais: a RFC utiliza MUST. Com cabeçalhos internacionalizados, os U-labels são recomendados (SHOULD), enquanto os A-labels continuam válidos.

Estas etiquetas não têm todas a mesma função. d= indica o domínio que assina, s= o seletor que permite encontrar a chave e i=, quando presente, uma identidade composta por uma parte local e uma parte de domínio. No exemplo fictício i=service@example.com, apenas example.com é o domínio. A regra sobre a sua escrita não significa que service seja um nome a converter da mesma maneira.

A verificação DKIM inclui uma consulta da chave pública no DNS e um cálculo criptográfico sobre a mensagem. As duas operações não seguem a mesma regra de transformação. O nome da consulta deve assumir a forma esperada pelo DNS. Para calcular ou verificar o hash, a RFC exige, pelo contrário, o domínio tal como está escrito no cabeçalho, com as regras de canonicalização DKIM aplicáveis.

Esta distinção impede uma correção tentadora: substituir todos os nomes Unicode pela forma ASCII num email em bruto antes de verificar a assinatura. Mesmo que os nomes designem o mesmo domínio, a sua escrita não é idêntica nos dados assinados. Uma equivalência de nomes não torna duas sequências de bytes intercambiáveis para o cálculo criptográfico.

Suponha que uma mensagem com cabeçalhos internacionalizados contém um domínio de assinatura em Unicode. O verificador encontra a chave através do nome ASCII correspondente e depois verifica a assinatura conservando a representação do cabeçalho. Uma interface pode apresentar as duas escritas lado a lado para ajudar quem administra o domínio. Esta apresentação não autoriza a alteração da mensagem original.

Para o diagnóstico, guarde uma cópia em bruto da mensagem recebida. Uma captura de ecrã em que o programa de email reformatou os endereços facilita a leitura, mas não reproduz necessariamente os valores utilizados na assinatura. Anote d= e s= no cabeçalho DKIM e procure a chave na localização construída a partir desses valores. Uma chave publicada para o nome sem acento não passa a ser a chave do domínio acentuado.

O seletor merece tanta atenção como o domínio. Dois envios do mesmo domínio podem utilizar seletores diferentes; encontrar uma chave com um não valida a assinatura feita com o outro. No cenário example.com, septembre._domainkey.example.com e archives._domainkey.example.com são duas localizações. O erro seria então um seletor incorreto, mesmo que a escrita do domínio estivesse certa.

DMARC e o domínio visível em From

A secção 6 exige a conversão em A-labels de todos os U-labels do domínio do endereço From antes de continuar o processamento DMARC. Mantém também endereços convencionais nas etiquetas de relatórios rua e ruf. Esta última regra diz respeito aos destinos dos relatórios, não à escrita autorizada em todas as partes da mensagem.

O ponto de partida é o domínio do endereço From, depois da arroba. O nome apresentado da pessoa, por exemplo "Equipa comercial", não entra nesta comparação. Pode existir um acento nessa indicação mesmo que o endereço não contenha qualquer domínio internacionalizado. Abrir os detalhes do remetente evita diagnosticar o elemento errado.

DMARC procura uma autenticação SPF ou DKIM bem-sucedida e alinhada com esse domínio From. O alinhamento estrito compara os domínios exatos; o alinhamento relaxado tem em conta o domínio organizacional. Uma diferença de subdomínio pode, por isso, ser aceite consoante o modo escolhido. Retirar um acento não é uma regra de alinhamento relaxado: não transforma dois nomes independentes num só.

Na comparação deste artigo, café.fr e xn--caf-dma.fr podem corresponder durante o processamento dos nomes. cafe.fr continua distinto. Deter os dois domínios, utilizar o mesmo servidor ou apresentar o mesmo nome de empresa não altera esta relação. Se o seu remetente deve utilizar o nome acentuado mas assina pelo outro, corrija a configuração do fluxo em causa.

Para os relatórios, um destino de documentação como rua=mailto:rapports@example.com mostra o formato de um endereço convencional. Se o domínio destinatário for internacionalizado, a sua parte de domínio utiliza a forma ASCII; acrescentar um acento à parte local não respeita a regra da secção 6. O endereço também tem de poder receber os relatórios. A sua sintaxe não cria uma caixa de correio.

Considere, por fim, o caso que costuma suscitar dúvidas: configurou o nome acentuado e depois um relatório DMARC ou o cabeçalho Authentication-Results apresenta xn--caf-dma.fr. A correspondência com a interface pode estar inteiramente correta. Identifique o campo que contém esse valor e leia o resultado associado: o domínio From, o domínio SPF e o domínio de assinatura não são intercambiáveis.

Se os nomes corresponderem após a conversão, prossiga com as causas indicadas nos resultados: IP não autorizado, chave não encontrada, assinatura inválida ou identidade autenticada realmente diferente do domínio From. Não reescreva a política apenas por causa do prefixo. Ver xn-- em vez do acento não é, por si só, um erro de alinhamento.

O que as ferramentas verificam quando introduz café.fr

A consulta DNS e a verificação DMARC do CaptainDNS aceitam café.fr e consultam a sua forma ASCII. Para DMARC, o nome da consulta é _dmarc.xn--caf-dma.fr. A consulta DNS apresenta o Unicode ao lado dessa forma. A verificação DMARC apresenta o nome consultado em ASCII. Estes nomes ilustram o tratamento da entrada, sem apresentar resultados reais sobre este domínio de terceiros.

A consulta responde a uma questão de publicação DNS: que registos são devolvidos para o nome e o tipo pedidos? A verificação DMARC concentra-se na política publicada e na sua sintaxe. Ajudam a verificar a zona certa, mas um TXT DMARC válido não comprova que cada plataforma de envio assine as suas mensagens com o domínio correto.

Este limite conta durante uma mudança de fornecedor. Pode ter publicado exatamente o valor pedido e continuar a receber falhas em alguns emails. A plataforma que os envia pode ainda utilizar uma identidade antiga. Compare então a publicação DNS e os cabeçalhos de um envio dessa plataforma. Uma verificação do domínio e uma verificação da mensagem complementam-se; não observam a mesma coisa.

Um resultado vazio também deve ser lido em conjunto com o nome pedido. Se introduziu o domínio sem acento, a ferramenta examinou esse nome distinto. Se introduziu o domínio certo, a ausência de um registo exige uma análise da sua publicação. Em ambos os casos, a primeira verificação continua a ser a identidade da zona, antes de alterar qualquer valor.

Para relacionar apenas as escritas do nome, o Conversor Punycode / IDN fornece as duas formas sem consultar o DNS. Para conhecer os dados publicados pela entidade gestora do registo, pode consultar o registo do domínio com RDAP. RDAP não valida SPF nem DMARC: uma ficha de registo descreve o domínio registado, não o bom funcionamento dos seus emails.

Uma tabela de caracteres latinos sob .fr

A política de nomes da Afnic permite uma tabela de caracteres latinos, incluindo letras acentuadas, mas não caracteres cirílicos sob .fr. Nesta comparação entre um nome acentuado e a sua escrita sem acento, o único nome semelhante considerado é o nome ASCII sem acento, que continua a ser distinto; esta comparação não protege contra outras semelhanças visuais. Para nomes enganadores e ligações suspeitas fora deste caso, consulte os nossos artigos para reconhecer um email de phishing e examinar redirecionamentos e ligações suspeitas.

Um acento antes da arroba é outro assunto

No exemplo fictício élise@example.com, o acento pertence à parte local que identifica a caixa de correio; não se converte como um domínio. A internacionalização de endereços de email (EAI) distingue trocar mensagens com um endereço internacionalizado de criar essa caixa num fornecedor. O Gmail aceita envios para estes endereços e receção a partir deles, mas as suas regras de criação de nomes de utilizador excluem letras acentuadas. No Microsoft 365, o Exchange Online anuncia estas trocas com endereços internacionalizados, enquanto as regras de criação de utilizadores excluem acentos no endereço. O trânsito possível não autoriza criar uma caixa acentuada nestes fornecedores nem garante a compatibilidade de cada intermediário.

O certificado também utiliza a forma ASCII do domínio

O campo dNSName da extensão SAN de um certificado contém a forma ASCII do domínio internacionalizado. A RFC 5280, secção 7.2, impõe este formato para guardar o nome. Ver xn-- nos detalhes de um certificado pode, por isso, corresponder ao domínio que o navegador apresenta com o seu acento.

Um certificado que cobre o nome acentuado não cobre automaticamente o nome sem acento. Se um serviço tiver de apresentar ambas as identidades, os nomes abrangidos devem corresponder a essa necessidade. O princípio é o mesmo do email: uma semelhança ortográfica não substitui uma configuração explícita.

A CSR, ou pedido de assinatura de certificado, permite examinar os nomes pedidos antes da emissão. Não comprova quais os nomes que acabam por constar do certificado instalado. Durante um diagnóstico, distinga o que foi pedido do que o servidor efetivamente apresenta: a uma CSR correta pode ter-se seguido a instalação de outro certificado.

O analisador do CaptainDNS assinala como inválida uma forma Unicode não convertida num SAN dNSName e apresenta o Unicode ao lado de uma forma xn-- correta. Pode examinar os nomes do certificado na CSR para verificar esta escrita. A verificação incide sobre o pedido, sem permitir conclusões sobre as definições SPF ou DMARC do domínio.

O que este artigo não aborda

Este artigo ajuda a identificar o domínio a que pertencem as suas definições DNS e de email. Não desenvolve um tutorial de conversão, um guia de ligações enganadoras ou um procedimento de configuração HTTP. As páginas ligadas tratam essas necessidades separadamente.

A internacionalização completa das caixas de correio também exige outras verificações para além das do domínio. Aqui, o resultado pretendido continua a ser concreto: saber se duas escritas designam o mesmo nome, encontrar a sua zona e comparar as identidades efetivamente utilizadas pelo remetente. Conserve os cabeçalhos originais quando o problema disser respeito a uma assinatura.

FAQ

Um nome de domínio com acento é o mesmo que sem acento?

Não. Retirar o acento muda o domínio: café.fr e cafe.fr são distintos. Por outro lado, café.fr e xn--caf-dma.fr são duas representações do mesmo nome.

É necessário registar separadamente o domínio com acento e o domínio sem acento?

Sim, se pretende deter ambos os nomes e estiverem disponíveis para registo. A compra de um não atribui automaticamente o outro. As formas Unicode e xn-- de um mesmo domínio correspondem, em contrapartida, a um único registo.

Porque é que o meu relatório DMARC apresenta xn-- se configurei o nome com acento?

O relatório pode apresentar a representação ASCII do domínio internacionalizado configurado. Compare os nomes após a conversão e leia os resultados SPF, DKIM e o seu alinhamento com From. O prefixo, por si só, não assinala uma falha.

As definições SPF, DKIM e DMARC do domínio sem acento também cobrem o domínio acentuado?

Não, estes nomes têm definições independentes. Pode configurar os mesmos serviços para os dois, mas as publicações DNS e as identidades de envio devem corresponder a cada domínio. Retirar o acento não cria qualquer partilha automática.

Posso introduzir o meu domínio com acento numa ferramenta de verificação DNS ou DMARC?

Sim, na consulta DNS e na verificação DMARC do CaptainDNS: aceitam esta entrada e consultam a forma ASCII correspondente. Verifique o nome completo apresentado no resultado. Uma verificação DNS bem-sucedida não substitui a análise de uma mensagem enviada.

Um acento no domínio de um endereço de email equivale a um acento antes da arroba?

Não. Depois da arroba, o acento pertence ao domínio, que tem uma representação ASCII. Antes da arroba, pertence à parte local da caixa de correio e depende da EAI e das capacidades do fornecedor de email.

Que forma do domínio deve ser utilizada no certificado?

O SAN dNSName utiliza a forma ASCII do domínio internacionalizado. Um programa pode apresentar o Unicode ao lado para facilitar a leitura. Verifique separadamente os nomes pedidos na CSR e os nomes do certificado instalado.

Fontes

• RFC 8616 - regras DNS, SPF, DKIM e DMARC para correio internacionalizado, secções 3 a 6.
• Afnic - política de nomes de 6 de julho de 2026, artigo 2.2, caracteres permitidos.
• RFC 5280 - nomes internacionalizados no campo dNSName dos certificados, secção 7.2.
• Ajuda do Gmail - caracteres permitidos na criação de um nome de utilizador.
• RFC 9989 - domínios autenticados e alinhamento DMARC, secção 4.4.