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

> Registro DKIM ou SPF não verificado? Os 6 erros que travam o domínio, como achar cada um com dig e a correção na Cloudflare, Registro.br e outros.

Fonte: https://couryo.com/blog/dominio-de-email-nao-verifica · Publicado em 2026-10-20

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.

```bash title="Terminal"
dig +short NS exemplo.com.br
# ana.ns.cloudflare.com.
# bob.ns.cloudflare.com.
```

| O NS termina em | Onde editar |
|---|---|
| `ns.cloudflare.com` | Cloudflare |
| `dns.br` (servidores do Registro.br) | Registro.br |
| `dns-parking.com` ou `hostinger` | Hostinger (hPanel) |
| `domaincontrol.com` | GoDaddy |
| `vercel-dns.com` | Vercel |

Esse é o erro de [uma pergunta no Stack Overflow](https://stackoverflow.com/questions/78437991/dkim-record-not-being-verified-by-resend) 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?":

```bash title="Terminal (macOS e Linux)"
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
```

```bash title="Windows"
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`):

```bash title="Terminal"
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.

```bash title="Terminal"
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](https://developers.cloudflare.com/dns/proxy-status/) 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](https://www.rfc-editor.org/rfc/rfc7208#section-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](https://community.vercel.com/t/having-problems-to-verify-dns-record-with-resend-x-vercel/2505), 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:

```bash title="Terminal"
dig +short TXT exemplo.com.br | grep spf1
```

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

```text title="TXT em exemplo.com.br"
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](https://couryo.com/blog/registro-spf-hostinger-hostgator-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](https://www.rfc-editor.org/rfc/rfc2308)).

```bash title="Terminal"
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

| Painel | Onde fica | Campo de nome | Cuidado específico |
|---|---|---|---|
| **Cloudflare** | domínio > **DNS** > **Records** > **Add record** | só a parte curta; `@` para o domínio principal | nuvem cinza (**DNS only**) nos CNAMEs de e-mail |
| **Registro.br** | **Domínios** > domínio > **Configurar endereçamento** > **Modo avançado**; depois **Nova entrada** e **Salvar alterações** | só a parte curta; vazio para o domínio principal | só vale se o domínio usa os servidores do Registro.br; a troca para o modo avançado leva alguns minutos ([passo a passo](https://www.locaweb.com.br/ajuda/wiki/como-acessar-a-zona-de-dns-na-registro-br-registro-de-dominio)) |
| **Hostinger (hPanel)** | **Domínios** > domínio > **DNS / Nameservers** ([ajuda](https://www.hostinger.com/br/support/1583249-como-gerenciar-seus-registros-dns-no-hpanel-hostinger/)) | `@` para o principal, só o subdomínio nos outros | a hospedagem costuma criar SPF e DMARC próprios: edite em vez de duplicar |
| **GoDaddy** | **Domain Portfolio** > domínio > **DNS** > **Add New Record** ([ajuda](https://www.godaddy.com/help/add-a-txt-record-19232)) | `@` ou só o prefixo, sem o domínio | o nome não pode começar nem terminar com ponto |
| **Vercel** | **Domains** > domínio > formulário de DNS ([documentação](https://vercel.com/docs/domains/managing-dns-records)) | só o prefixo (`bounces`, não `bounces.exemplo.com.br`); vazio para o principal | só funciona com os servidores de nomes da Vercel; o TTL padrão é 60 segundos |

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

| O que você vê | Causa mais provável |
|---|---|
| tudo pendente, nada aparece no `dig` | painel errado (o NS aponta para outro lugar) |
| só o DKIM e o return path pendentes, na Cloudflare | proxy ligado nos CNAMEs |
| `dig` responde no nome com o domínio repetido | domínio colado no campo de nome |
| SPF "não verificado" ou `spf=permerror` | dois registros SPF ou mais de 10 consultas |
| certo no servidor do domínio, vazio no seu computador | cache; espere o TTL |
| valor quase igual ao esperado | espaço, aspas ou letra trocada |

## 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](https://couryo.com/docs/domains.md).

## 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.