Domínio de e-mail não verifica: diagnóstico por provedor de DNS

Você copiou os registros do serviço de e-mail, colou no painel de DNS, esperou um dia e a tela continua com "pendente". O deploy está pronto, o e-mail de boas-vindas não sai e o suporte responde "aguarde a propagação". Na maioria das vezes, propagação não é o problema: é um dos seis erros abaixo, e dá para achar qual com dois comandos.

Primeiro: descubra quem responde pelo DNS do domínio#

Antes de mexer em qualquer registro, confirme que você está editando o painel certo. O DNS de um domínio é respondido pelos servidores de nomes (NS) configurados no registro do domínio. Criar registros em qualquer outro painel não muda nada.

dig +short NS exemplo.com.br
# ana.ns.cloudflare.com.
# bob.ns.cloudflare.com.

Esse é o erro de uma pergunta no Stack Overflow de 2024: o domínio estava registrado num lugar e o site hospedado na Vercel, e a pessoa criou os registros primeiro no painel do registrador, depois na Vercel, depois nos dois. Dois de três registros verificaram, o DKIM não. Com o dig NS no começo, a dúvida "onde coloco?" some.

Como conferir um registro com dig e nslookup#

Os comandos que respondem "o registro existe e tem o valor certo?":

dig +short TXT exemplo.com.br                        # SPF
dig +short TXT _dmarc.exemplo.com.br                 # DMARC
dig +short CNAME couryo1._domainkey.exemplo.com.br   # DKIM por CNAME
dig +short CNAME bounces.exemplo.com.br              # return path

nslookup -type=TXT _dmarc.exemplo.com.br
nslookup -type=CNAME couryo1._domainkey.exemplo.com.br
Resolve-DnsName -Type CNAME couryo1._domainkey.exemplo.com.br

Para tirar o cache do caminho, pergunte direto ao servidor de nomes do domínio (o que apareceu no dig NS):

dig +short CNAME couryo1._domainkey.exemplo.com.br @ana.ns.cloudflare.com

Como ler a resposta:

• Resposta vazia no servidor do domínio: o registro não existe com esse nome. É erro de nome ou de painel, não de propagação.
• Resposta certa no servidor do domínio e vazia no seu computador: é cache. Espere o TTL ou teste com outro resolvedor (@1.1.1.1, @8.8.8.8).
• Resposta com outro valor: erro de digitação ou registro antigo no mesmo nome.

Os 6 erros mais comuns#

1. Domínio repetido no campo de nome#

Quase todo painel completa o nome com o domínio sozinho. Se você cola o nome inteiro, o registro nasce em couryo1._domainkey.exemplo.com.br.exemplo.com.br.

Como achar: o dig no nome certo vem vazio; no nome duplicado, responde.

dig +short CNAME couryo1._domainkey.exemplo.com.br.exemplo.com.br

Correção: no campo de nome, escreva só a parte antes do domínio (couryo1._domainkey, _dmarc, bounces). Alguns painéis aceitam o nome completo com um ponto final (couryo1._domainkey.exemplo.com.br.), que marca o nome como absoluto; na dúvida, use só a parte curta.

2. CNAME com proxy na Cloudflare#

Com a nuvem laranja ligada, a Cloudflare responde com os IPs dela em vez do CNAME, e o DKIM e o return path deixam de apontar para o serviço de envio. A documentação da Cloudflare recomenda "DNS only" para registros de e-mail e de verificação de terceiros, e diz que só registros A, AAAA e CNAME podem passar pelo proxy.

Como achar: o dig CNAME volta vazio e o dig A no mesmo nome devolve IPs.

Correção: edite o registro e mude Proxy status para DNS only (nuvem cinza).

3. Dois registros SPF#

Dois TXT começando com v=spf1 no mesmo nome invalidam os dois: o resultado é permerror (RFC 7208, seção 4.5). Acontece quando a hospedagem ou o e-mail da empresa já criou um SPF e o serviço novo pede outro.

Foi o caso de uma discussão na comunidade da Vercel, em 2024: a verificação não passava por um conflito entre o SPF do serviço de encaminhamento de e-mail e o do serviço de envio, e se resolveu juntando os dois num registro só.

Como achar:

dig +short TXT exemplo.com.br | grep spf1

Correção: um registro só, com todos os include e um all no fim:

v=spf1 include:_spf.google.com include:spf.outro-servico.com ~all

O passo a passo para juntar está em Registro SPF na Hostinger, HostGator e Locaweb.

4. Propagação e TTL (inclusive o cache do "não existe")#

Propagação é o tempo que os resolvedores levam para esquecer a resposta antiga. Quanto vale isso depende do TTL do registro e do painel. Um detalhe que quase ninguém conhece: se o verificador consultou o nome antes de você criar o registro, a resposta "não existe" também fica em cache, pelo tempo definido no registro SOA da zona (RFC 2308).

dig SOA exemplo.com.br +noall +answer
# o "não existe" fica em cache pelo menor entre o TTL do SOA e o último número dele, em segundos

Correção: confira no servidor do domínio (com @). Se ali está certo, é só esperar. Se o painel deixa, baixe o TTL antes de uma mudança grande.

5. Registro na zona errada#

Variações do mesmo erro:

• o registro foi criado no registrador, mas o DNS é respondido por outro lugar (veja o dig NS no começo);
• o domínio tem um subdomínio com zona própria (por exemplo, mail.exemplo.com.br delegado para outro provedor) e o registro foi criado na zona do domínio principal, ou o contrário;
• o registro foi criado em outro domínio da conta, parecido (exemplo.com em vez de exemplo.com.br).

Como achar: dig +short NS mail.exemplo.com.br mostra se o subdomínio tem servidores de nomes próprios.

6. Erro de digitação, espaço ou aspas#

• Espaço ou quebra de linha no começo ou no fim do valor, comum ao copiar de PDF ou planilha.
• Aspas duplicadas: alguns painéis põem as aspas do TXT sozinhos; colar "v=DMARC1; ..." com aspas pode gerar "\"v=DMARC1...\"".
• Chave DKIM cortada em TXT longos. Prefira os registros por CNAME quando o serviço oferecer.
• Letra trocada no seletor (couryo1 contra couyro1).

Como achar: compare caractere por caractere a saída do dig com o valor esperado. Muitos serviços mostram o valor encontrado ao lado do esperado; use isso.

Painel por painel#

A Vercel lembra, na própria documentação, que trocar os servidores de nomes não leva os registros antigos junto: copie o MX, o SPF, o DKIM e o DMARC antes de mudar o NS, ou o e-mail para de funcionar.

Do sintoma à causa#

Onde o Couryo entra#

No Couryo, cada registro do domínio aparece com o próprio status: ok, pending (ainda não encontrado) ou wrong (encontrado com outro valor), e no wrong o campo found mostra o que está publicado, para comparar com o esperado. Domínios pendentes são conferidos de novo sozinhos a cada 10 minutos por 72 horas. Com a Cloudflare conectada (um token com permissão de editar o DNS da zona), os registros são criados na sua zona e verificados na hora, sem copiar e colar. O SPF fica no subdomínio de devolução, então o SPF do domínio principal não muda e o erro 3 não acontece. Veja Domínios e DNS.

Perguntas frequentes#

Quanto tempo a verificação de domínio leva?#

Com os registros certos no painel certo, de minutos a algumas horas. Na Cloudflare e na Vercel costuma ser questão de minutos. Se depois de um dia o dig no servidor do domínio ainda não mostra o registro, o problema não é propagação: confira o painel e o nome.

O registro aparece no dig, mas o serviço diz que não verificou. Por quê?#

Três motivos comuns: o verificador ainda tem em cache a resposta "não existe" (espere o tempo do SOA), o valor tem uma diferença pequena (espaço, aspas, letra) ou o registro é um CNAME com proxy na Cloudflare, que responde com IPs. Peça a verificação de novo depois de corrigir.

Posso ter dois registros DKIM no mesmo domínio?#

Pode, desde que tenham seletores diferentes (google._domainkey, couryo1._domainkey). Cada serviço usa o seu. O que não pode é dois SPF no mesmo nome ou dois DMARC.

Preciso apagar o SPF da hospedagem para usar outro serviço de envio?#

Não. Se o serviço novo pede um include no domínio principal, junte no SPF que já existe. Se ele usa um subdomínio de devolução (como bounces.), o SPF do domínio principal fica como está.

O que é o ponto final no nome do registro?#

Num nome de DNS, o ponto final indica que ele está completo (exemplo.com.br.). Sem o ponto, alguns painéis acrescentam o domínio no fim. Se o registro foi criado com o domínio repetido, apague e crie de novo só com a parte curta do nome.