Poupe até 53% em Servidores VPS, escolha agora. Oferta limitada.

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

16 min de leitura  ·  Guia técnico

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.com203.0.113.10). O registro CNAME cria um alias que aponta para outro nome de host, não para um IP (ex: www.meusite.commeusite.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

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

  • 0 Os usuários acharam isso útil
  • DNS, zona DNS, registros DNS, cPanel, AviraHost, domínio, MX
Esta resposta foi útil?

Artigos Relacionados

Guia Completo para Configurar E-mails Profissionais no cPanel

Guia Completo para Configurar E-mails Profissionais no cPanel Ter um e-mail profissional é...

Como Configurar DNS Personalizado para Seu Domínio na AviraHost

Como Configurar DNS Personalizado para Seu Domínio na AviraHost Ter um DNS personalizado é...

Como gerenciar um domínio.

Adicione um domínio a sua conta, utilizando nosso painel de gerenciar domínios, Você pode...

Solucionar problemas de resolução de nomes DNS em VPS Linux e servidor dedicado

Introdução Falhas na resolução de nomes DNS podem causar lentidão, indisponibilidade de sites e...

Checklist para Configurar e Testar Limite de E-mails Enviados por Hora no VPS Linux e Servidor Dedicado

Introdução Controlar o volume de e-mails enviados por hora é fundamental para evitar bloqueios...