Rede
Guia de referência de tipos de registros DNS
Referência dos tipos de registros DNS necessários para operar e-mail e sites — A, MX, TXT, SPF, DKIM, DMARC e mais — com propósito, exemplos de sintaxe e cuidados para cada um.
Tipos de registros DNS
| Tipo | Propósito | Exemplo | Observação |
|---|---|---|---|
| Registro A | O tipo de registro mais básico: associa um nome de domínio a um endereço IPv4, indicando onde um servidor web ou de e-mail realmente está. | example.com. 3600 IN A 192.0.2.1 |
Um TTL muito curto (3600 segundos = 1 hora neste exemplo) aumenta as consultas ao servidor autoritativo e a carga; um TTL muito longo atrasa a propagação quando o IP muda. |
| Registro AAAA | Associa um nome de domínio a um endereço IPv6 — essencialmente a versão IPv6 do registro A. | example.com. 3600 IN AAAA 2001:db8::1 |
Manter também um registro A permite que redes sem suporte a IPv6 usem IPv4 como alternativa (operação dual-stack). |
| Registro CNAME | Trata um nome de host como um alias de outro nome de host canônico, por exemplo apontando www.example.com para example.com. | www.example.com. 3600 IN CNAME example.com. |
Um nome de host com CNAME não pode ter outros registros (como MX ou TXT) coexistindo (restrição da RFC 1034). Um CNAME também não pode ser definido na raiz da zona (@). |
| Registro MX | Especifica qual servidor de e-mail deve receber mensagens endereçadas a um domínio. Vários servidores podem ser listados com um valor de prioridade. | example.com. 3600 IN MX 10 mail.example.com. |
Um valor de prioridade menor indica prioridade mais alta. É comum listar vários servidores com prioridades diferentes para redundância. O destino de um MX deve ser um nome de host com registro A, nunca um CNAME. |
| Registro TXT | Um registro de propósito geral que anexa texto arbitrário a um domínio. Usado para SPF, DKIM e DMARC, além de verificação de propriedade de domínio, entre outros usos. | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
Um domínio pode ter vários registros TXT, mas colocar mais de um registro para o mesmo propósito (como SPF) causa erros de interpretação — devem ser consolidados em um único registro. |
| Registro SPF (um tipo de registro TXT) | Lista os servidores (endereços IP) autorizados a enviar e-mail em nome de um domínio, fornecendo autenticação do remetente para ajudar a prevenir falsificação. Configurado como registro TXT. | example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all" |
Apenas um registro SPF é válido por domínio. Cuidado com cadeias de "include", pois exceder o limite de 10 consultas DNS causa um erro permanente. O tipo de registro dedicado (RRTYPE 99) foi descontinuado em 2014, então hoje o SPF é expresso apenas por meio de registros TXT. |
| Registro DKIM (um tipo de registro TXT) | Anexa uma assinatura digital ao e-mail enviado para que o destinatário possa verificar que não foi adulterado durante o trânsito e que veio de um remetente legítimo. A chave pública é publicada como registro TXT. | selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." |
O seletor (a parte inicial do nome de host) varia conforme o serviço de envio. A chave privada permanece no servidor de envio — apenas a chave pública é publicada no DNS. |
| Registro DMARC (um tipo de registro TXT) | Declara, com base nos resultados de SPF e DKIM, como o destinatário deve tratar e-mails que falham na autenticação (entregar, colocar em quarentena ou rejeitar) e fornece um canal para receber relatórios agregados. | _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
Começar com p=none apenas para monitoramento e endurecer gradualmente para quarantine e reject após confirmar que não há problemas é a forma segura de implantar. |
| Registro NS | Indica quais são os servidores DNS autoritativos de um domínio (zona) — o ponto de partida para resolver qualquer nome sob ele. | example.com. 86400 IN NS ns1.example-dns.com. |
Se os servidores de nomes registrados no registrador não coincidirem com os registros NS dentro da zona, a resolução de nomes fica instável (chamada de delegação capenga, ou "lame delegation"). |
| Registro SOA | Contém informações administrativas de uma zona — servidor primário, e-mail do administrador, número de série, intervalos de nova tentativa e mais. Toda zona deve ter exatamente um. | example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400) |
Sempre que atualizar o arquivo de zona, é preciso incrementar o número de série; caso contrário, os servidores secundários nunca receberão a mudança via transferência de zona. |
| Registro CAA | Restringe quais autoridades certificadoras (CAs) podem emitir certificados para um domínio, impedindo que CAs não intencionais emitam certificados fraudulentos. | example.com. 3600 IN CAA 0 issue "letsencrypt.org" |
Se um domínio não tiver nenhum registro CAA, qualquer CA é considerada autorizada a emitir para ele. Certificados curinga exigem uma tag issuewild separada. |
| Registro PTR | Resolve um endereço IP de volta a um nome de host — o inverso de um registro A. Configurado em uma zona reversa (in-addr.arpa / ip6.arpa). | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
Muitos servidores de e-mail marcam como spam ou rejeitam mensagens de remetentes sem PTR reverso ou cujo PTR não corresponde ao registro A, então isso é praticamente obrigatório para servidores de envio. |
Dicas
- Se estiver em dúvida sobre SPF, DKIM ou DMARC, diagnostique primeiro seus registros atuais com a ferramenta "Verificador de registros SPF/DKIM/DMARC" e depois compare com os exemplos de sintaxe desta página.
- Um TTL de cerca de uma hora (3600 segundos) é um padrão seguro para registros comuns; reduzi-lo para cerca de 300 segundos pouco antes de uma migração de DNS acelera a propagação, e depois é possível aumentá-lo novamente.
- Valores de registros TXT com mais de 255 caracteres podem ser divididos automaticamente em várias strings, então confira se as aspas continuam corretas ao copiar e colar.
- Se também quiser verificar o formato do próprio endereço de e-mail, a ferramenta "Validador de formato de endereço de e-mail" cobre essa parte.
- Ao adotar um novo serviço de envio de e-mail, comece o DMARC com p=none, acompanhe os relatórios por uma ou duas semanas para confirmar que não há problemas e só então mude para uma política de aplicação — é o caminho mais seguro.
Perguntas frequentes
O SPF verifica a legitimidade do IP de origem — ou seja, "de qual servidor isso foi enviado" —, enquanto o DKIM verifica a integridade da mensagem por meio de uma assinatura digital — "se o conteúdo foi adulterado". Somente quando ambos passam é que a autenticação do remetente oferece proteção significativa.
Não é uma exigência legal, mas provedores de e-mail importantes, como Gmail e Yahoo Mail, exigem DMARC na prática para remetentes de grande volume, e não tê-lo aumenta bastante o risco de ser marcado como spam ou rejeitado.
As causas mais comuns são o destino do MX apontar para um CNAME em vez de um nome de host com registro A, um valor de prioridade configurado incorretamente, ou o próprio servidor de e-mail não estar configurado para aceitar mensagens desse domínio.
Use um registro A/AAAA quando o endereço IP for fixo e você quiser defini-lo na raiz do domínio (@); use CNAME quando quiser que o nome de host funcione como alias de outro host, como um endpoint de CDN.
Para operação normal, cerca de uma hora (3600 segundos) é comum. Reduzi-lo para cerca de 300 segundos pouco antes de uma migração de servidor ou troca de DNS faz a mudança se propagar mais rápido assim que aplicada.
Curiosidade — a história por trás dos registros DNS e da autenticação de e-mail
O DNS é mais conhecido por associar nomes de domínio a endereços IP, mas na verdade existem muitos outros tipos de registros além de A e AAAA, cada um com um papel distinto. No mundo da entrega de e-mail, em particular, vários registros — MX, TXT (que carrega SPF/DKIM/DMARC) e PTR — só resultam em um e-mail "legítimo, não falsificado" quando funcionam todos juntos; faltando apenas um, o risco de cair na pasta de spam ou ser rejeitado aumenta.
Olhando para a história da autenticação de remetente, o SPF foi proposto no início dos anos 2000 como medida contra spam, e o DKIM, voltado a detectar adulteração no conteúdo da mensagem, foi padronizado por volta de 2007. No entanto, nenhum dos dois, isoladamente, definia o que o destinatário deveria fazer quando a autenticação falhasse — o DMARC surgiu em 2012 para preencher essa lacuna. O DMARC avalia em conjunto os resultados de SPF e DKIM e fornece tanto uma política de aplicação para falhas quanto um mecanismo de relatórios, funcionando como uma espécie de centro de comando da autenticação.
Alguns registros DNS mudaram de forma ao longo do tempo por razões históricas. Um tipo de registro dedicado ao SPF (RRTYPE 99) chegou a ser definido em uma RFC de 2006, mas causou confusão de implementação e foi formalmente descontinuado pela RFC 7208 em 2014 — hoje o SPF é expresso exclusivamente por meio de registros TXT. Da mesma forma, DKIM e DMARC também não têm um tipo de registro próprio: ambos são implementados inteiramente dentro de registros TXT usando uma sintaxe específica (strings que começam com v=DKIM1 ou v=DMARC1), o que diz muito sobre o quanto o DNS é extensível.