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

⚡TL;DR

• Mantenha o acento ao identificar o domínio: café.fr e cafe.fr são dois nomes distintos, com configurações independentes.
• Associe café.fr a xn--caf-dma.fr: são duas representações do mesmo nome, sem um segundo registro para comprar.
• Em um email, anote o domínio do envelope SPF, o domínio d= de DKIM e o domínio do endereço From antes de comparar os resultados.
• Confira o nome consultado no DNS: ver xn-- em um relatório DMARC não comprova uma falha de alinhamento.

Você configurou um domínio com acento. Alguns dias depois, um relatório de email exibe um nome que começa com xn--. Você procura um domínio desconhecido na sua conta ou tira o acento para encontrar uma forma mais familiar. Cada uma dessas reações leva a um erro diferente.

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

Essa distinção determina em qual zona você deve procurar suas configurações e quais domínios os destinatários autenticam. Também explica por que uma interface fácil de ler e um log técnico podem parecer contraditórios. Os nomes acima servem apenas para comparar formas de escrita: este artigo não descreve seus titulares, seus serviços nem seus registros reais.

Tirar o acento muda o nome de domínio

café.fr e xn--caf-dma.fr indicam o mesmo nome; cafe.fr é outro domínio. O primeiro par relaciona uma forma Unicode, legível com seu acento, à representação ASCII correspondente. A segunda comparação muda a grafia. Nenhum mecanismo do DNS conecta automaticamente as configuraçõ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 mantém a identidade do nome acentuado. Ela não resulta da remoção dos acentos. As letras, os números e os hifens de xn--caf-dma.fr representam aquele nome específico, e o prefixo faz parte da escrita que você precisa manter. Copiar só o final dessa sequência não faz sentido para encontrar o domínio.

Na hora de registrar, essa distinção evita contar a mesma compra duas vezes. Uma interface pode mostrar o nome acentuado durante o pedido e depois a forma xn-- no resumo. As duas descrições podem indicar um único domínio registrado. Ter o nome sem acento não dá a você automaticamente o nome com acento, nem o contrário. Se você quiser usar os dois nomes, precisa tratar o registro e a configuração de cada um separadamente.

O mesmo raciocínio vale para os serviços. Uma organização que controla dois nomes pode escolher a mesma hospedagem DNS e o mesmo provedor de email. Pode até configurar os endereços correspondentes para entregar mensagens em uma única caixa de entrada. Essas são decisões explícitas de configuração. Tirar um acento não cria essa caixa, nem um alias de email, nem uma cópia dos registros.

Imagine dois domínios da sua organização, um acentuado e outro não. O segundo já recebe emails, enquanto o primeiro acabou de ser registrado. Adicionar um endereço acentuado aos seus documentos comerciais não configura o recebimento de mensagens. O provedor de email precisa conhecer esse domínio, e as configurações DNS precisam corresponder ao uso pretendido. O serviço existente no outro nome não resolve essa falta.

O diagrama mostra, portanto, duas zonas ilustrativas independentes. Isso não exige dois provedores nem dois servidores físicos: uma mesma infraestrutura pode hospedar várias zonas. A independência diz respeito aos nomes e aos seus dados. Uma mudança aplicada a um não se propaga para o outro porque a grafia é parecida.

O nome que você encontra na zona DNS e nos logs

A forma xn-- oferece uma referência comum para relacionar uma zona DNS, um log e uma interface que exibe o acento. Ela identifica o nome internacionalizado sem mudar seu domínio.

Em um console DNS, o título da zona pode aparecer em Unicode. Uma exportação ou um log de consultas pode usar a forma ASCII. Antes de procurar um registro ausente, compare os nomes completos. Você pode ter aberto a zona certa com outra apresentação, ou uma zona realmente diferente cujo nome perdeu o acento.

O nome da zona e o nome de um registro nem sempre aparecem juntos. Alguns consoles esperam um nome relativo e acrescentam a zona atual. Em uma zona fictícia example.com, digitar _dmarc pode indicar _dmarc.example.com. O rótulo curto _dmarc parece igual em dois consoles, mas o nome completo depende da zona aberta. Esse nome completo permite identificar qual política você alterou.

Um exemplo de documentação, sem valores retirados de um domínio de terceiros, mostra a diferença:

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

Use essa leitura para os seus próprios nomes com acento. Se a interface exibir a zona em Unicode e o nome completo em ASCII, confira a correspondência antes de criar uma segunda entrada. Adicionar um registro para corrigir apenas a apresentação pode criar uma duplicata; publicar no domínio sem acento deixaria a zona desejada sem alteração.

O conteúdo de um log também precisa de contexto. O nome consultado, o tipo solicitado e a resposta recebida descrevem uma operação específica. 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 foi rejeitado. Guarde o nome exato e o resultado: trocar essas informações por uma aproximação deixa o diagnóstico menos confiável.

Ao abrir um chamado de suporte, inclua a forma digitada e a representação ASCII correspondente, além do nome completo do registro envolvido. Acrescente a data da observação se você acabou de alterar a zona. Esses dados ajudam a distinguir uma confusão de nomes de uma resposta antiga ainda em cache. Nenhum tempo de espera fará uma correção aparecer em uma zona que você não alterou.

Converter um nome também não consulta o DNS. A conversão pode gerar uma forma ASCII correta sem provar que o domínio está registrado, tem uma zona publicada ou recebe emails. Cada uma dessas perguntas exige uma verificação própria. Saber escrever um destino não comprova que um serviço responde nele.

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

As verificações de email usam várias identidades de domínio, cuja forma de escrita depende da etapa do processamento. A RFC 8616 define separadamente as regras de DNS, SPF, DKIM e DMARC. Confundir essas etapas pode levar você a procurar uma chave na zona errada ou a alterar um cabeçalho que precisava preservar.

Dois termos ajudam a acompanhar o texto da RFC. Um U-label é a forma Unicode de uma parte internacionalizada do nome, como café. Seu A-label é a representação ASCII correspondente, neste caso xn--caf-dma. Os pontos separam as partes do domínio; fr não muda. Esse vocabulário descreve duas representações, nunca dois registros de domínio que você precisa contratar.

Os nomes consultados no DNS

A seção 3 da RFC 8616 mantém em ASCII as sequências de caracteres armazenadas nos registros DNS usados por esses protocolos. Um nome obtido de um cabeçalho é convertido antes da consulta DNS se contiver U-labels. O software que consulta um registro não pode presumir que só um sistema de email com cabeçalhos internacionalizados vai ler a resposta.

Essa regra não descreve o formato de todos os campos de um email. Ela delimita os dados publicados e a consulta DNS. A mesma mensagem pode conter um endereço legível em Unicode e gerar uma consulta com o nome ASCII correspondente. Nenhum titular ou destino muda nessa etapa.

Ao ler uma configuração, separe o nome do registro do seu valor. O primeiro responde a "onde procurar?"; o segundo contém a política ou a chave. Um texto SPF perfeitamente formado, salvo sob o nome errado, não será o que o destinatário vai consultar. Ter uma chave DKIM em algum lugar da sua conta DNS também não basta: a localização precisa corresponder ao domínio e ao seletor da assinatura.

Estas são as localizações de um cenário inteiramente fictício com example.com. A tabela descreve nomes para 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, esses domínios podem ser diferentes. Um provedor pode gerenciar o domínio do envelope ou assinar com seu próprio domínio. Comece anotando as identidades realmente usadas em uma mensagem recebida. Procurar apenas o nome que aparece no topo do console nem sempre responde à pergunta de cada protocolo.

SPF e o domínio do envelope

A seção 4 exige converter todos os U-labels em A-labels antes da validação SPF. O domínio apresentado em EHLO já precisa estar em A-labels; o domínio de MAIL FROM pode usar qualquer uma das formas em uma troca internacionalizada. A conversão também vale para nomes usados nas expansões de macros SPF, não só para a primeira consulta.

SPF examina identidades da sessão SMTP. EHLO apresenta o servidor que envia; MAIL FROM carrega o endereço do envelope, usado, entre outras finalidades, para devoluções por erro. Esse endereço é diferente do endereço From que o leitor vê no cliente de email. Um domínio configurado para exibição não passa automaticamente a ser o domínio verificado por SPF.

Por que EHLO precisa usar a forma ASCII desde o início? Esse comando vem antes da resposta que informa se o servidor aceita a extensão necessária ao email internacionalizado. O software de envio ainda não tem essa informação. O formato exigido nesse momento não determina quais formatos poderão ser usados nas etapas seguintes.

Em um 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 usado, não um TXT escolhido porque aparece na página inicial do site. Se a plataforma usa um domínio internacionalizado, a mesma consulta adota a forma ASCII depois da conversão. O protocolo não tenta, em seguida, o domínio sem acento como alternativa de fallback.

Para entender um resultado SPF, identifique primeiro o que foi testado e depois leia os detalhes da política. Um pass indica que o endereço IP foi autorizado para a identidade avaliada. Ele não certifica que essa identidade é a do endereço From, nem que todo o sistema de email está configurado corretamente. A comparação com From cabe ao DMARC.

Os nomes internacionalizados mencionados dentro de um registro SPF também precisam ser escritos em A-labels. Uma interface de administração que aceita acento no nome da zona não autoriza você a colocá-lo livremente no valor TXT. O campo de entrada do domínio e o conteúdo publicado cumprem funções diferentes.

Se você administra os dois nomes, com e sem acento, evite copiar as políticas automaticamente. Os mesmos servidores podem estar autorizados para ambos, desde que os fluxos de email justifiquem isso. Um domínio usado apenas para receber não tem necessariamente as mesmas necessidades que um domínio de envio. A semelhança entre os nomes não é um inventário dos seus remetentes.

DKIM e os valores assinados

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

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

A verificação DKIM inclui uma busca da chave pública no DNS e um cálculo criptográfico sobre a mensagem. As duas operações seguem regras diferentes de transformação. O nome da consulta precisa usar a forma esperada pelo DNS. Para calcular ou verificar o hash, porém, a RFC exige o domínio exatamente como está escrito no cabeçalho, com as regras de canonicalização DKIM aplicáveis.

Essa diferença impede uma correção que pode parecer tentadora: substituir os nomes Unicode pela forma ASCII em todo o email bruto antes de verificar a assinatura. Mesmo quando os nomes indicam o mesmo domínio, a forma de escrita nos dados assinados não é idêntica. A equivalência entre nomes não torna duas sequências de bytes intercambiáveis no cálculo criptográfico.

Suponha que uma mensagem com cabeçalhos internacionalizados tenha um domínio de assinatura em Unicode. O verificador encontra a chave com o nome ASCII correspondente e depois confere a assinatura mantendo a representação do cabeçalho. Uma interface pode exibir as duas formas lado a lado para ajudar quem administra o domínio. Essa exibição não autoriza alterar a mensagem original.

Para o diagnóstico, salve uma cópia bruta da mensagem recebida. Uma captura de tela com endereços reformatados pelo cliente de email ajuda na leitura, mas nem sempre reproduz os valores usados 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 quanto o domínio. Dois envios do mesmo domínio podem usar seletores diferentes; encontrar uma chave com um deles 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 o domínio estivesse escrito da forma certa.

DMARC e o domínio visível em From

A seção 6 exige converter em A-labels todos os U-labels do domínio do endereço From antes de continuar o processamento DMARC. Ela também mantém endereços convencionais nas tags de relatórios rua e ruf. Essa última regra trata dos destinos dos relatórios, não da escrita permitida em todas as partes da mensagem.

O ponto de partida é o domínio do endereço From, depois da arroba. O nome de exibição da pessoa, por exemplo "Equipe comercial", não entra nessa comparação. Esse texto pode ter um acento mesmo que o endereço não contenha nenhum domínio internacionalizado. Abra os detalhes do remetente para evitar o diagnóstico do 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 considera o domínio organizacional. Uma diferença de subdomínio pode, portanto, ser aceita conforme o modo escolhido. Tirar um acento não é uma regra de alinhamento relaxado: não transforma dois nomes independentes em um só.

Na comparação deste artigo, café.fr e xn--caf-dma.fr podem corresponder durante o processamento dos nomes. cafe.fr continua sendo distinto. Ter os dois domínios, usar o mesmo servidor ou exibir o mesmo nome de empresa não muda essa relação. Se o seu remetente deve usar o nome acentuado, mas assina pelo outro, corrija a configuração daquele fluxo de envio.

Para 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, sua parte de domínio usa a forma ASCII; adicionar um acento à parte local não respeita a regra da seção 6. O endereço também precisa conseguir receber os relatórios. Sua sintaxe não cria uma caixa de entrada.

Considere agora o caso que costuma gerar a dúvida: você configurou o nome acentuado e depois um relatório DMARC ou o cabeçalho Authentication-Results exibe xn--caf-dma.fr. A correspondência com a interface pode estar totalmente 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 depois da conversão, siga 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 sua política apenas por causa do prefixo. Ver xn-- no lugar do acento não é, por si só, um erro de alinhamento.

O que as ferramentas verificam quando você digita café.fr

A consulta DNS e a verificação DMARC do CaptainDNS aceitam café.fr e consultam sua forma ASCII. Para DMARC, o nome de consulta é _dmarc.xn--caf-dma.fr. A consulta DNS exibe o Unicode ao lado dessa forma. A verificação DMARC mostra o nome consultado em ASCII. Esses nomes ilustram o processamento da entrada, sem apresentar um resultado real sobre esse domínio de terceiros.

A consulta responde a uma pergunta sobre a publicação DNS: quais registros são retornados para o nome e o tipo solicitados? A verificação DMARC se concentra na política publicada e na sintaxe dela. Elas ajudam você a verificar a zona certa, mas um TXT DMARC válido não prova que todas as plataformas de envio assinam suas mensagens com o domínio correto.

Esse limite importa quando você troca de provedor. Você pode ter publicado exatamente o valor pedido e ainda receber falhas em alguns emails. A plataforma que envia essas mensagens pode continuar usando uma identidade antiga. Compare então a publicação DNS e os cabeçalhos de um envio dessa plataforma. Uma verificação de domínio e uma verificação de mensagem se complementam; elas não observam a mesma coisa.

Um resultado vazio também precisa ser lido junto com o nome solicitado. Se você digitou o domínio sem acento, a ferramenta examinou esse outro nome. Se digitou o domínio certo, a ausência de um registro pede uma análise da publicação. Nos dois casos, a primeira verificação continua sendo a identidade da zona, antes de qualquer alteração de valor.

Para relacionar apenas as formas de escrita do nome, o Conversor Punycode / IDN fornece as duas representações sem consultar o DNS. Para conhecer os dados publicados pela entidade responsável pelo registro, você pode consultar o registro do domínio com RDAP. RDAP não valida SPF nem DMARC: uma ficha de registro descreve o domínio registrado, não o funcionamento correto dos seus emails.

Uma tabela de caracteres latinos em .fr

A política de nomes da Afnic permite uma tabela de caracteres latinos, incluindo letras acentuadas, mas não caracteres cirílicos em .fr. Nesta comparação entre um nome acentuado e sua escrita sem acento, o único nome parecido considerado é o nome ASCII sem acento, que continua sendo distinto; essa comparação não protege contra outras semelhanças visuais. Para nomes enganosos e links suspeitos fora desse caso, consulte nossos artigos para reconhecer um email de phishing e examinar redirecionamentos e links suspeitos.

Um acento antes da arroba é outro assunto

No exemplo fictício élise@example.com, o acento está na parte local que identifica a caixa de entrada; ela não é convertida como um domínio. A internacionalização de endereços de email (EAI) diferencia trocar mensagens com um endereço internacionalizado de criar essa caixa em um provedor. O Gmail aceita envios para esses endereços e mensagens vindas deles, mas suas regras de criação de nomes de usuário excluem letras acentuadas. No Microsoft 365, o Exchange Online anuncia essas trocas com endereços internacionalizados, enquanto as regras de criação de usuários excluem acentos no endereço. O trânsito possível não autoriza criar uma caixa acentuada nesses provedores nem garante a compatibilidade de cada intermediário.

O certificado também usa 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, seção 7.2, exige esse formato para armazenar o nome. Ver xn-- nos detalhes de um certificado pode, portanto, corresponder ao domínio que o navegador exibe com acento.

Um certificado que cobre o nome acentuado não cobre automaticamente o nome sem acento. Se um serviço precisa apresentar as duas identidades, os nomes cobertos devem corresponder a essa necessidade. O princípio é o mesmo do email: uma grafia parecida não substitui uma configuração explícita.

A CSR, ou solicitação de assinatura de certificado, permite examinar os nomes pedidos antes da emissão. Ela não prova quais nomes vão aparecer no certificado instalado. Durante o diagnóstico, diferencie o que foi solicitado do que o servidor realmente apresenta: depois de uma CSR correta, pode ter sido instalado outro certificado.

O parser do CaptainDNS sinaliza como inválida uma forma Unicode não convertida em um SAN dNSName e exibe o Unicode ao lado de uma forma xn-- correta. Você pode examinar os nomes do certificado na CSR para conferir essa escrita. A verificação trata da solicitação e não permite concluir nada sobre as configurações SPF ou DMARC do domínio.

O que este artigo não aborda

Este artigo ajuda você a identificar o domínio ao qual pertencem suas configurações de DNS e email. Ele não desenvolve um tutorial de conversão, um guia de links enganosos nem um procedimento de configuração HTTP. As páginas vinculadas tratam dessas necessidades separadamente.

A internacionalização completa das caixas de entrada também exige verificações além das do domínio. Aqui, o resultado esperado continua sendo concreto: saber se duas representações indicam o mesmo nome, encontrar a zona correspondente e comparar as identidades realmente usadas pelo remetente. Guarde os cabeçalhos originais quando o problema envolver uma assinatura.

FAQ

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

Não. Tirar o acento muda o domínio: café.fr e cafe.fr são distintos. Já café.fr e xn--caf-dma.fr são duas representações do mesmo nome.

Preciso registrar separadamente o domínio com acento e o domínio sem acento?

Sim, se você quiser ter os dois nomes e eles estiverem disponíveis para registro. Comprar um não dá a você automaticamente o outro. As formas Unicode e xn-- de um mesmo domínio correspondem a um único registro.

Por que meu relatório DMARC mostra xn-- se configurei o nome com acento?

O relatório pode exibir a representação ASCII do domínio internacionalizado que você configurou. Compare os nomes depois da conversão e leia os resultados SPF, DKIM e seu alinhamento com From. O prefixo sozinho não indica uma falha.

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

Não, esses nomes têm configurações independentes. Você pode configurar os mesmos serviços para os dois, mas as publicações DNS e as identidades de envio precisam corresponder a cada domínio. Tirar o acento não cria nenhum compartilhamento automático.

Posso digitar meu domínio com acento em uma ferramenta de verificação DNS ou DMARC?

Sim, na consulta DNS e na verificação DMARC do CaptainDNS: elas aceitam essa entrada e consultam a forma ASCII correspondente. Confira o nome completo exibido 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, ele pertence à parte local da caixa de entrada e depende da EAI e dos recursos do provedor de email.

Qual forma do domínio devo usar no certificado?

O SAN dNSName usa a forma ASCII do domínio internacionalizado. Um software pode exibir o Unicode ao lado para facilitar a leitura. Confira separadamente os nomes solicitados na CSR e os nomes do certificado instalado.

Fontes

• RFC 8616 - regras DNS, SPF, DKIM e DMARC para email internacionalizado, seçõ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, seção 7.2.
• Ajuda do Gmail - caracteres permitidos na criação de um nome de usuário.
• RFC 9989 - domínios autenticados e alinhamento DMARC, seção 4.4.