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:
- Acesse o painel de gerenciamento de DNS do seu provedor ou servidor autoritativo.
- Crie o registro A apontando o domínio raiz para o IP do servidor.
- Adicione o registro CNAME para o subdomínio
wwwapontando para o domínio raiz. - Configure os registros MX com as prioridades corretas para o servidor de email.
- Insira os registros TXT de SPF, DKIM e verificação de propriedade.
- Verifique a propagação com o comando
digou 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
diginstalada localmente (pacotednsutilsno Debian/Ubuntu oubind-utilsno 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.
- Acesse o editor de zona DNS do seu painel (cPanel → Zone Editor, ou Cloudflare → DNS).
- Clique em Adicionar registro e selecione o tipo A.
- No campo Nome, insira
@(representa o domínio raiz, ex:meusite.com.br). - No campo Valor (ou Points to), insira o IPv4 do servidor: ex.
203.0.113.10. - Defina o TTL. Use
300durante migrações e3600em produção estável. - 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.
- No editor de zona DNS, adicione um novo registro do tipo CNAME.
- No campo Nome, insira o subdomínio: ex.
www. - No campo Valor (ou Points to), insira o nome canônico: ex.
meusite.com.br.(com ponto final em zonas BIND). - 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.
- Obtenha os hostnames dos servidores MX fornecidos pelo seu provedor de email (ex: Google Workspace, Microsoft 365, Titan Mail).
- No editor de zona DNS, adicione registros do tipo MX.
- No campo Nome, use
@(domínio raiz). - No campo Prioridade, insira o valor numérico (menor = maior prioridade).
- No campo Valor, insira o hostname do servidor MX.
- 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, executedig TIPO meudominio.com.br +shortconsultando 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.