Registros DNS A, AAAA, CNAME, MX e TXT: exemplos de quando usar cada um
Publicado em 2026-10-26 por frfrand
Tipos de registros DNS e erros comuns ao conectar web e e-mail
Te dão um domínio e alguém diz «coloque o IP no DNS». Isso chega para alguns sites, mas e-mail, validação de serviços e subdomínios precisam de registros diferentes. Entender cinco tipos evita muitas mudanças desnecessárias.
Vamos transformar isso em um procedimento que você pode usar em um VPS real. O objetivo é entender por que funciona, como testar e qual problema aparece se uma parte estiver mal configurada.
O que significam A, AAAA, CNAME, MX e TXT e quando você precisa deles
A aponta um nome para IPv4; AAAA para IPv6; CNAME cria um alias DNS para outro nome em condições compatíveis; MX indica servidores de recebimento de e-mail; TXT carrega informações textuais como verificações, SPF, DKIM ou DMARC de acordo com seu formato.
Antes de mudar qualquer coisa em produção, anote o estado atual: IP, domínio, porta, serviço afetado e hora do último deploy. Uma modificação isolada é fácil de comprovar; cinco mudanças simultâneas tornam mais difícil reconstruir o que aconteceu.
Configuração ou comandos de exemplo
dig ejemplo.com A +short
dig ejemplo.com AAAA +short
dig www.ejemplo.com CNAME +short
dig ejemplo.com MX +short
dig ejemplo.com TXT +short
# DMARC suele consultarse como TXT
dig _dmarc.ejemplo.com TXT +shortOs domínios, IPs, caminhos e nomes são ilustrativos. Não copie uma configuração inteira sobre a atual sem comparar primeiro. Nos exemplos que incluem portas ou firewall, certifique-se de manter o acesso administrativo.
Como eu faria passo a passo
- Preparação. Para publicar um site em VPS, configure A ou AAAA para endereços que realmente atendam ao site.
- Passo 2. Se você criar
wwwcomo CNAME, verifique restrições e como seu provedor DNS o aceita. - Passo 3. Para e-mail, configure MX para hosts adequados e verifique reputação, SPF, DKIM e DMARC.
- Passo 4. Não crie dois registros incompatíveis no mesmo nome só porque um tutorial fez isso.
- Verificação. Verifique a resposta do DNS e depois teste o serviço real: resolução não garante que HTTP ou SMTP funcione.
Quando terminar, comprove a operação real a partir de outra conexão. Por exemplo, para uma API não basta abrir o navegador: execute uma requisição de leitura, uma gravação em um banco de teste e consulte os logs do processo.
Exemplo de um projeto de verdade
Uma agência conecta api.cliente.com ao FastAPI no ArduMaker e mantém o e-mail do Google Workspace. Só precisa alterar o registro da API; tocar em MX sem motivo pode cortar o e-mail do cliente.
A lição é simples: uma configuração de infraestrutura não vive isolada da aplicação. O frontend, o servidor, o banco de dados e os workers se conectam, então medir onde começa a falha é mais útil do que reiniciar tudo.
O erro que evitaria
Um CNAME no apex do domínio tem restrições DNS padrão, embora alguns provedores ofereçam flattening ou alias próprios. Não assuma que toda interface de DNS implementa o mesmo.
Quando trabalha com servidores de clientes, guarde um backup ou procedimento de reversão antes de mudanças que afetem dados, rede ou certificados. E se não souber quais permissões uma operação precisa, evite executar como root apenas para parar de mostrar erros.
Como isso se relaciona com o ArduMaker?
Ao administrar domínios e VPS a partir do ArduMaker, diferencie registros web de e-mail. Publicar uma API não deve implicar alterar configurações MX de serviços existentes.
Em um caso típico, você pode criar um VPS para o aplicativo, implantar a partir do Git, associar domínio HTTPS e administrar o backend e os bancos de dados necessários. As ferramentas ajudam a centralizar operações, mas é preciso entender qual porta e processo cumpre cada função.
Perguntas que surgem ao testar
Como saber se a falha é de DNS ou do serviço? Consulte primeiro a resolução, depois a conexão na porta e, finalmente, a resposta do aplicativo. Essa ordem evita confundir problemas diferentes.
Posso expor um banco de dados para facilitar a manutenção? É melhor projetar acesso privado ou túneis autenticados quando possível. Expor uma porta não substitui as permissões do mecanismo nem o firewall.
O que devo documentar? A configuração esperada, como verificar e como voltar ao estado anterior. Esse documento ajuda mais do que uma lista de comandos sem contexto.
Referências
Em resumo: uma boa configuração de rede ou servidor é aquela que você consegue explicar, verificar e recuperar quando algo falha.