Guia de zona DNS: registros A, MX, CNAME e TXT do zero

Zona DNS é o conjunto de registros que controla como um domínio resolve nomes para endereços IP, servidores de email e outros serviços. Configurar corretamente os registros A, MX, CNAME e TXT do zero é essencial para que seu site, email e serviços funcionem sem interrupções. Siga estes passos:

1. Acesse o painel de gerenciamento de DNS do seu provedor ou servidor autoritativo.
2. Crie o registro A apontando o domínio raiz para o IP do servidor.
3. Adicione o registro CNAME para o subdomínio www apontando para o domínio raiz.
4. Configure os registros MX com as prioridades corretas para o servidor de email.
5. Insira os registros TXT de SPF, DKIM e verificação de propriedade.
6. Verifique a propagação com o comando dig ou ferramentas online.

Pré-requisitos para configurar zona DNS

• Acesso ao painel de controle do registrador de domínio (ex: cPanel, Cloudflare, AviraHost) ou ao servidor DNS autoritativo (BIND 9, PowerDNS).
• Endereço IPv4 (e opcionalmente IPv6) do servidor de hospedagem.
• Dados do servidor de email fornecidos pelo provedor (ex: Google Workspace, Microsoft 365, Titan Mail).
• Chave DKIM gerada pelo servidor de email (necessária para o registro TXT de autenticação).
• Permissão de edição na zona DNS do domínio — verifique em Como gerenciar um domínio.
• Ferramenta dig instalada localmente (pacote dnsutils no Debian/Ubuntu ou bind-utils no Rocky Linux 9 / AlmaLinux 9).

O que é zona DNS e como ela funciona

A zona DNS é um arquivo de configuração mantido por um servidor autoritativo que mapeia nomes de domínio a recursos de rede. Quando um usuário digita meusite.com.br no navegador, o resolvedor recursivo do provedor de internet consulta os servidores raiz, depois os servidores de nomes autoritativos do domínio, e finalmente lê os registros da zona para retornar o endereço correto. Cada entrada nessa zona é chamada de resource record (RR) e possui tipo, nome, valor e TTL (Time to Live).

O TTL define por quantos segundos os servidores recursivos podem armazenar o registro em cache. Um TTL de 300 (5 minutos) é ideal durante migrações; após estabilizar, valores como 3600 ou 86400 reduzem a carga nos servidores autoritativos. Para entender como configurar DNS personalizado na AviraHost, consulte o artigo Como Configurar DNS Personalizado para Seu Domínio na AviraHost.

A estrutura básica de um registro em formato de zona BIND é:

nome    TTL    IN    TIPO    valor

Exemplo real de zona simplificada:

$ORIGIN meusite.com.br.
$TTL 3600
@       IN  SOA  ns1.avirahost.com.br. admin.meusite.com.br. (
                  2024010101 ; serial
                  3600       ; refresh
                  900        ; retry
                  604800     ; expire
                  300 )      ; minimum TTL

@       IN  NS   ns1.avirahost.com.br.
@       IN  NS   ns2.avirahost.com.br.
@       IN  A    203.0.113.10
www     IN  CNAME meusite.com.br.
mail    IN  A    203.0.113.11
@       IN  MX   10 mail.meusite.com.br.
@       IN  TXT  "v=spf1 ip4:203.0.113.11 ~all"

Como configurar o registro A do zero

O registro A (Address Record) é o tipo mais fundamental da zona DNS: ele associa um nome de host a um endereço IPv4. Sem ele, nenhum navegador consegue localizar seu servidor. Para domínios com IPv6, o equivalente é o registro AAAA.

1. Acesse o editor de zona DNS do seu painel (cPanel → Zone Editor, ou Cloudflare → DNS).
2. Clique em Adicionar registro e selecione o tipo A.
3. No campo Nome, insira @ (representa o domínio raiz, ex: meusite.com.br).
4. No campo Valor (ou Points to), insira o IPv4 do servidor: ex. 203.0.113.10.
5. Defina o TTL. Use 300 durante migrações e 3600 em produção estável.
6. Salve e aguarde a propagação.

Para verificar se o registro A foi publicado corretamente, execute no terminal:

dig A meusite.com.br +short

Output esperado:

203.0.113.10

Se quiser criar um registro A para um subdomínio específico, como app.meusite.com.br, use app no campo Nome em vez de @. Cada subdomínio pode apontar para um IP diferente, permitindo separar ambientes de produção, staging e desenvolvimento.

Atenção: ao alterar o registro A de um domínio em produção, o site ficará inacessível durante a propagação para usuários cujos resolvedores ainda têm o IP antigo em cache. Reduza o TTL para 300 pelo menos 24 horas antes da mudança.

Como configurar o registro CNAME corretamente

O registro CNAME (Canonical Name) cria um alias de um nome de host para outro nome de host — nunca para um IP diretamente. É amplamente usado para apontar www para o domínio raiz, ou subdomínios de serviços externos como loja.meusite.com.br para plataformas de e-commerce.

1. No editor de zona DNS, adicione um novo registro do tipo CNAME.
2. No campo Nome, insira o subdomínio: ex. www.
3. No campo Valor (ou Points to), insira o nome canônico: ex. meusite.com.br. (com ponto final em zonas BIND).
4. Defina o TTL e salve.

www     IN  CNAME  meusite.com.br.

Verificação:

dig CNAME www.meusite.com.br +short

Output esperado:

meusite.com.br.

Regra crítica: o CNAME não pode ser usado no apex do domínio (o @ ou meusite.com.br diretamente), pois conflita com os registros SOA e NS. Provedores como Cloudflare oferecem o recurso CNAME Flattening para contornar essa limitação no apex. Além disso, nunca aponte um CNAME para outro CNAME em cadeia — isso causa latência adicional e pode resultar em falha de resolução.

Outro uso comum: integrar serviços de terceiros. O Google Search Console, por exemplo, pode solicitar um CNAME de verificação como:

abc123def456  IN  CNAME  gv-xyzxyzxyz.dv.googlehosted.com.

Como configurar registros MX para email profissional

Os registros MX (Mail Exchanger) definem quais servidores são responsáveis por receber emails destinados ao domínio. A configuração incorreta é a causa mais comum de perda de mensagens em ambientes corporativos.

1. Obtenha os hostnames dos servidores MX fornecidos pelo seu provedor de email (ex: Google Workspace, Microsoft 365, Titan Mail).
2. No editor de zona DNS, adicione registros do tipo MX.
3. No campo Nome, use @ (domínio raiz).
4. No campo Prioridade, insira o valor numérico (menor = maior prioridade).
5. No campo Valor, insira o hostname do servidor MX.
6. Repita para cada servidor MX adicional com prioridades diferentes.

Exemplo para Google Workspace:

@   IN  MX  1   aspmx.l.google.com.
@   IN  MX  5   alt1.aspmx.l.google.com.
@   IN  MX  5   alt2.aspmx.l.google.com.
@   IN  MX  10  alt3.aspmx.l.google.com.
@   IN  MX  10  alt4.aspmx.l.google.com.

Verificação após configuração:

dig MX meusite.com.br

Output esperado (trecho):

meusite.com.br.  3600  IN  MX  1  aspmx.l.google.com.
meusite.com.br.  3600  IN  MX  5  alt1.aspmx.l.google.com.

Atenção: o valor do campo MX deve ser sempre um hostname, nunca um endereço IP. Inserir um IP diretamente no campo de valor do MX é inválido segundo a RFC 5321 e causará falha na entrega de emails.

Para testar se o servidor MX está aceitando conexões SMTP, use:

telnet aspmx.l.google.com 25

Output esperado (início da sessão SMTP):

220 mx.google.com ESMTP ...

Como configurar registros TXT: SPF, DKIM e DMARC

Os registros TXT são os mais versáteis da zona DNS. Eles armazenam texto livre e são usados principalmente para autenticação de email (SPF, DKIM, DMARC) e verificação de propriedade de domínio. Um domínio pode ter múltiplos registros TXT sem conflito entre eles.

Registro TXT de SPF (Sender Policy Framework)

O SPF define quais servidores têm autorização para enviar email em nome do domínio. Sem ele, seus emails têm maior chance de cair em spam.

@   IN  TXT  "v=spf1 include:_spf.google.com ~all"

Interpretação: v=spf1 indica a versão; include:_spf.google.com autoriza os servidores do Google; ~all marca como suspeito qualquer servidor não listado (softfail). Use -all (hardfail) em produção quando tiver certeza de todos os remetentes autorizados.

Registro TXT de DKIM (DomainKeys Identified Mail)

O DKIM adiciona uma assinatura criptográfica aos emails. A chave pública fica publicada no DNS como registro TXT em um subdomínio específico:

google._domainkey  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

O seletor (google neste exemplo) é fornecido pelo provedor de email. A chave pública (p=...) é gerada automaticamente pelo provedor e deve ser copiada exatamente como fornecida.

Registro TXT de DMARC

O DMARC instrui os servidores receptores sobre o que fazer com emails que falham nas verificações SPF e DKIM:

_dmarc  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

Parâmetros: p=quarantine move para spam; p=reject rejeita; p=none apenas monitora. Comece com none para coletar relatórios antes de aplicar políticas restritivas.

Registro TXT de verificação de propriedade

Serviços como Google Search Console e Microsoft 365 solicitam um registro TXT para confirmar que você controla o domínio:

@   IN  TXT  "google-site-verification=abc123XYZ..."

Verificação de todos os registros TXT do domínio:

dig TXT meusite.com.br

Output esperado (trecho):

meusite.com.br.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"
meusite.com.br.  3600  IN  TXT  "google-site-verification=abc123XYZ..."

Problemas comuns e como resolver

Sintoma: site não carrega após alterar o registro A

Causa: o TTL anterior era alto (ex: 86400 segundos), e os resolvedores recursivos ainda estão servindo o IP antigo do cache.
Solução: aguarde o tempo equivalente ao TTL anterior. Para verificar qual IP está sendo resolvido por diferentes servidores ao redor do mundo, use ferramentas como dig @8.8.8.8 A meusite.com.br (Google DNS) e dig @1.1.1.1 A meusite.com.br (Cloudflare DNS). Se ambos retornarem o IP novo, o problema é local — limpe o cache DNS do sistema operacional com sudo systemd-resolve --flush-caches no Ubuntu 24.04 ou ipconfig /flushdns no Windows.

Sintoma: emails não chegam ao destino após configurar MX

Causa: o registro MX foi configurado com um endereço IP no campo de valor em vez de um hostname, ou a prioridade foi definida incorretamente, ou o TTL ainda não expirou.
Solução: execute dig MX meusite.com.br e confirme que o campo de valor contém um hostname (ex: aspmx.l.google.com.), não um IP. Verifique também se não há registros MX antigos conflitantes. Remova entradas duplicadas ou desatualizadas. Teste a conectividade SMTP com telnet hostname_mx 25.

Sintoma: CNAME retorna NXDOMAIN ou não resolve

Causa: o nome canônico de destino foi digitado incorretamente (falta de ponto final em zonas BIND, ou typo no hostname), ou o registro ainda não propagou.
Solução: execute dig CNAME www.meusite.com.br e verifique o valor retornado. Em zonas BIND, nomes absolutos devem terminar com ponto (meusite.com.br.); sem o ponto, o servidor DNS concatena o $ORIGIN ao valor, resultando em meusite.com.br.meusite.com.br. — um hostname inválido.

Sintoma: emails marcados como spam mesmo com SPF configurado

Causa: SPF sozinho não é suficiente. A ausência de DKIM e DMARC reduz a reputação do domínio. Além disso, múltiplos registros SPF no mesmo domínio (ex: dois registros TXT começando com v=spf1) invalidam ambos segundo a RFC 7208.
Solução: consolide todos os mecanismos SPF em um único registro TXT. Adicione DKIM e DMARC. Verifique com dig TXT meusite.com.br | grep spf — deve retornar exatamente uma linha com v=spf1.

Sintoma: registro TXT de verificação não é reconhecido pelo serviço

Causa: o valor do TXT foi inserido com aspas extras ou espaços adicionais, ou o registro ainda não propagou completamente.
Solução: verifique o valor exato com dig TXT meusite.com.br +short. O output deve mostrar o valor entre aspas exatamente como fornecido pelo serviço. Aguarde pelo menos o tempo do TTL configurado antes de tentar a verificação novamente no painel do serviço.

Perguntas frequentes sobre zona DNS

Quanto tempo leva a propagação de DNS após alterar os registros?

A propagação de DNS pode levar de alguns minutos até 48 horas, dependendo do TTL configurado nos registros e dos servidores recursivos dos provedores de internet. Registros com TTL baixo (300 segundos) propagam mais rápido; registros com TTL alto (86400 segundos) podem demorar mais para atualizar em cache. Para migrações críticas, reduza o TTL para 300 pelo menos 24 horas antes de fazer a alteração, e restaure para um valor maior após confirmar que tudo funciona.

Qual a diferença entre registro A e registro CNAME no DNS?

O registro A aponta um nome de host diretamente para um endereço IPv4 (ex: meusite.com → 203.0.113.10). O registro CNAME cria um alias que aponta para outro nome de host, não para um IP (ex: www.meusite.com → meusite.com). O CNAME não pode ser usado na raiz do domínio (apex), apenas em subdomínios — usar CNAME no apex conflita com os registros SOA e NS obrigatórios.

O que acontece se eu configurar o registro MX errado?

Um registro MX incorreto faz com que emails destinados ao seu domínio sejam rejeitados ou entregues ao servidor errado, resultando em perda de mensagens. O campo de prioridade do MX (ex: 10, 20) define a ordem de tentativa entre múltiplos servidores de email — menor valor significa maior prioridade. Sempre verifique com o comando dig MX seudominio.com após qualquer alteração para confirmar que os registros estão corretos antes de comunicar a mudança.

Para que serve o registro TXT no DNS?

O registro TXT armazena texto arbitrário associado a um domínio e é amplamente usado para verificação de propriedade (Google Search Console, Microsoft 365), autenticação de email (SPF, DKIM, DMARC) e validação de certificados SSL. Um domínio pode ter múltiplos registros TXT simultaneamente sem conflito — a única exceção é o SPF, que deve ter exatamente um registro v=spf1 por domínio.

Posso ter mais de um registro MX no mesmo domínio?

Sim, é possível e recomendado ter múltiplos registros MX com prioridades diferentes para garantir redundância no recebimento de emails. O servidor com menor valor de prioridade (ex: 10) é tentado primeiro; se estiver indisponível, o próximo (ex: 20) é usado automaticamente. Provedores como Google Workspace e Microsoft 365 exigem múltiplos registros MX para garantir alta disponibilidade na entrega de mensagens.

Conclusão

• Configure o registro A primeiro — ele é o ponto de partida de toda a zona DNS e deve apontar para o IPv4 correto do servidor antes de qualquer outro ajuste.
• Implemente SPF, DKIM e DMARC juntos — os três registros TXT de autenticação de email funcionam em conjunto; configurar apenas um deles não garante proteção adequada contra spoofing e spam.
• Monitore a propagação com dig — após cada alteração, execute dig TIPO meudominio.com.br +short consultando diferentes resolvedores (@8.8.8.8, @1.1.1.1) para confirmar que a mudança está visível globalmente antes de considerar a tarefa concluída.

Leia também

• Guia para configurar subdomínio no cPanel do jeito certo
• Passo a passo para configurar email profissional com domínio próprio no cPanel
• Otimizar a propagação de DNS: por que demora e como acelerar

Precisa de ajuda com DNS e hospedagem?

Configurar zona DNS corretamente é fundamental para o funcionamento do seu site e email profissional. A AviraHost oferece planos de hospedagem com painel intuitivo para gerenciar registros DNS, suporte técnico especializado e infraestrutura estável para manter seu domínio sempre acessível.

Conheça os planos de hospedagem da AviraHost