Consulta DNS: como verificar registros TXT, registros MX e outros registros DNS

Verificar registros TXT e verificar registros MX são as tarefas de DNS mais comuns: o TXT guarda registros SPF, DKIM, DMARC e de verificação de domínio, enquanto o MX informa ao mundo para onde entregar o seu e-mail. A forma mais rápida de verificar os registros DNS de um domínio online é usar uma consulta DNS: a ferramenta gratuita, sem cadastro, mostra os registros A, AAAA, CNAME, MX, NS, TXT, SOA e SRV, junto com seus valores e TTL. A consulta MX detalha melhor os servidores de e-mail e as prioridades, e, pela linha de comando, nslookup -type=txt example.com e nslookup -type=mx example.com mostram o mesmo. A seguir: como interpretar os resultados e o que fazer quando seus registros "não atualizam".

Como verificar registros DNS online

1. Abra a consulta DNS e digite o domínio: example.com. Não é preciso remover o protocolo nem o caminho: a ferramenta extrai o hostname da URL automaticamente.
2. Para um subdomínio, digite-o por completo: www.example.com, shop.example.com. Cada nome tem seus próprios registros, e um CNAME geralmente fica no subdomínio.
3. Compare os resultados com o que seu provedor de hospedagem ou de e-mail forneceu: o IP no registro A, os hostnames no MX, as strings no TXT.
4. Confira a coluna TTL: ela indica em quantos segundos os caches serão atualizados caso você tenha acabado de alterar algo.

A ferramenta consulta os registros pelo resolvedor do nosso servidor, então mostra o que um ponto da rede enxerga neste momento. Para verificar se as alterações já se propagaram, compare essa resposta com a de resolvedores públicos usando os comandos da próxima seção.

Nomes com sublinhado, como _dmarc.example.com, não são aceitos na consulta geral: os registros de e-mail têm ferramentas próprias. A consulta MX mostra os servidores de e-mail com prioridades e IPs, o verificador de SPF detalha os mecanismos e as cadeias de include, e o verificador de DMARC mostra a política e os endereços de relatório.

Como verificar DNS com nslookup e dig

O nslookup está disponível no Windows, macOS e Linux; o dig vem com o macOS e a maioria das distribuições Linux. O último parâmetro do nslookup, ou o argumento @ no dig, define qual servidor DNS consultar.

nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8
nslookup -type=CNAME www.example.com

dig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com NS +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig selector1._domainkey.example.com TXT +short
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

No PowerShell, Resolve-DnsName example.com -Type MX faz o mesmo. Para ver o que realmente está na zona, sem caches no caminho, consulte diretamente o servidor autoritativo: primeiro dig example.com NS +short, depois dig @ns1.your-provider.net example.com A. O dig +trace example.com percorre toda a cadeia a partir dos servidores raiz e mostra em que etapa a resposta difere do esperado.

Tipos de registro DNS e o que verificar

Como verificar um registro CNAME

Um CNAME diz: "este nome é um alias de outro nome: pergunte lá." Ele é usado em subdomínios que apontam para um serviço externo: um construtor de sites como Shopify, Wix ou Squarespace, uma CDN, uma loja hospedada. Você pode consultar o registro CNAME de um domínio online, informando o subdomínio na consulta de DNS, ou com dig www.example.com CNAME +short.

• Um CNAME não pode coexistir com outros registros no mesmo nome. Por isso você não pode colocar um CNAME comum no domínio raiz (example.com, que sempre tem NS e SOA). Alguns provedores de DNS oferecem um substituto: ALIAS, ANAME ou CNAME flattening. Visto de fora, esse registro parece um registro A normal.
• Cadeias CNAME → CNAME → CNAME funcionam, mas deixam a resolução mais lenta e dificultam a depuração.
• Um CNAME apontando para um nome que não existe mais é um motivo comum para um subdomínio "não carregar" depois que um serviço externo é desativado.
• O ponto final. Alguns painéis de controle exigem que o valor termine com um ponto; caso contrário, seu domínio é anexado ao final e você acaba com shop.example.net.example.com.

Como verificar o registro TXT de um domínio

1. Descubra em qual nome o registro deve ficar. O SPF e a verificação do Search Console ficam no próprio domínio (geralmente "@" em um painel de DNS), o DMARC em _dmarc.example.com e o DKIM em selector._domainkey.example.com. Os registros de verificação de outros serviços vão onde o serviço indicar.
2. Consulte online. Para o próprio domínio, use a consulta de DNS: a aba TXT lista todos os registros TXT com seu TTL. Nomes com sublinhado não são aceitos pela consulta geral: use o verificador de SPF, o verificador de DKIM e o verificador de DMARC para esses casos.
3. Ou pela linha de comando:

   nslookup -type=txt example.com
   nslookup -type=txt _dmarc.example.com 8.8.8.8
   dig TXT example.com +short
   dig TXT _dmarc.example.com +short
   dig @ns1.your-provider.net TXT example.com +short

   O último comando consulta diretamente o servidor autoritativo, então você vê o registro logo após adicioná-lo, sem esperar pelos caches.
4. Compare o valor caractere por caractere com o que o serviço forneceu: um espaço sobrando, uma chave truncada ou aspas dentro do valor vão quebrar a validação.

Não exclua o registro de verificação do Google depois que a propriedade for verificada: sem ele, a verificação pode ser perdida.

Erros comuns em registros TXT

• Dois registros v=spf1. Pelo padrão SPF, isso é um erro, e o SPF deixa de funcionar por completo. Incorpore os mecanismos do segundo serviço ao registro existente. Observe que nosso verificador de SPF analisa o primeiro registro v=spf1 que encontra, então procure duplicatas na lista de TXT da consulta de DNS ou com dig TXT example.com +short.
• Aspas dentro do valor. A maioria dos painéis espera o valor sem aspas e as adiciona para você. Se você colar com aspas, elas às vezes passam a fazer parte do texto: o dig então mostra "\"v=spf1 ...\"".
• Strings com mais de 255 caracteres. Uma única string dentro de um registro TXT é limitada a 255 caracteres, então um valor longo, normalmente uma chave DKIM de 2048 bits, é armazenado como várias strings entre aspas em um só registro: "v=DKIM1; k=rsa; p=MIIB..." "...continued". O destinatário as junta sem espaços. Muitos painéis dividem o valor para você; o erro é criar dois registros TXT separados.
• Nome errado. O domínio completo foi digitado no campo "Nome" e o painel o anexou de novo, gerando _dmarc.example.com.example.com.

Como os registros funcionam e como configurá-los: SPF, DKIM e DMARC explicados e o que são um registro DKIM e um seletor.

Registros TXT: SPF, DKIM e DMARC

Se os e-mails do seu domínio estão caindo no spam, verifique três registros TXT:

example.com.                     TXT  "v=spf1 include:_spf.google.com ~all"
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com.              TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

• SPF: a lista de servidores autorizados a enviar e-mails em nome do domínio. Deve existir apenas um registro v=spf1: dois registros SPF invalidam a verificação. A avaliação do SPF é limitada a dez consultas DNS, e cadeias longas de include facilmente ultrapassam esse limite.
• DKIM: a chave pública de assinatura, publicada em selector._domainkey.domain. O seletor é definido pelo seu serviço de e-mail; sem ele, você não consegue encontrar o registro.
• DMARC: a política para mensagens que falham no SPF e no DKIM: none (apenas relatórios), quarantine (enviar para spam), reject (recusar).

Os registros TXT também armazenam verificações de propriedade: por exemplo, uma propriedade de domínio no Search Console é verificada com um registro TXT. Veja o artigo sobre como conectar uma propriedade.

Como verificar registros MX

Um registro MX informa aos remetentes qual servidor recebe os e-mails do domínio. Ele tem dois campos: uma prioridade e um nome de servidor. Quanto menor o número, maior a prioridade: os remetentes tentam primeiro o servidor com 10 e recorrem ao 20 se ele estiver inacessível. Vários registros MX com a mesma prioridade dividem a carga: os remetentes escolhem entre eles, o que é um balanceamento de carga normal.

1. Digite o domínio na consulta de MX: ela lista os servidores de e-mail por prioridade, com seus endereços IPv4 e IPv6 e registros PTR, e reconhece o provedor de e-mail.
2. Ou execute nslookup -type=mx example.com ou dig MX example.com +short: a resposta é parecida com 10 mx1.example.net.
3. Confirme que cada hostname de MX resolve para um endereço: dig A mx1.example.net +short.
4. Compare a lista com as instruções do seu provedor de e-mail: geralmente é preciso remover todos os registros MX antigos, e não adicionar os novos ao lado deles.

Sem registros MX? Segundo a RFC 5321, os remetentes tentam o próprio endereço A/AAAA do domínio: o chamado MX implícito. Um domínio que não recebe e-mails deve publicar um MX nulo, 0 . (RFC 7505), para que os remetentes devolvam a mensagem imediatamente. Sem MX nem A, não é possível entregar e-mails ao domínio.

O MX cobre apenas o recebimento. Evitar que seus e-mails caiam na caixa de spam dos destinatários é papel do SPF, DKIM e DMARC, e a rota de uma mensagem específica está nos cabeçalhos dela. Veja como ler cabeçalhos de e-mail.

TTL e propagação de DNS

TTL é o tempo, em segundos, que os resolvers mantêm uma resposta em cache. Com um TTL de 3600, um provedor de internet que já consultou seu registro A continuará entregando o valor antigo por uma hora, mesmo que você já o tenha alterado. A chamada "propagação de DNS" é simplesmente a expiração gradual dos caches pelo mundo. Alterar os nameservers no registrador costuma demorar mais: os registros na zona do domínio de nível superior têm seu próprio TTL, em geral longo.

• Antes de mudanças planejadas, reduza o TTL para 300 segundos, com pelo menos um período do TTL antigo de antecedência.
• Se você consultou um nome antes de o registro ser criado, a resposta negativa também fica em cache, pelo tempo definido no registro SOA da zona.
• Seu cache local também pode atrapalhar: no Windows, limpe-o com ipconfig /flushdns; no macOS, com sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
• Se o servidor autoritativo responde corretamente, mas os resolvers públicos não, não há nada quebrado: basta esperar o TTL expirar.

Quando você precisa verificar o DNS

• O site carrega para algumas pessoas, mas não para outras. Uma causa comum são registros alterados recentemente, com alguns provedores de internet ainda mantendo dados antigos.
• O e-mail vai para o spam. Verifique SPF, DKIM e DMARC nos seus registros TXT.
• Mudança para um novo host. Anote seu DNS atual antes de fazer a troca.
• Conexão de um serviço externo: e-mail, CDN, construtor de sites. Quase sempre se trata de um registro CNAME ou TXT.

Erros comuns

• Editar registros no lugar errado. Se os registros NS do domínio apontam para um provedor, as alterações feitas no painel de outro provedor (o do seu registrador, por exemplo) não têm efeito. Verifique o NS primeiro.
• Dois registros SPF após adicionar um segundo serviço de e-mail, em vez de uni-los em um só.
• Um CNAME no domínio raiz que quebra os registros MX e TXT.
• Registros MX esquecidos durante uma migração: o site funciona, mas os e-mails deixam de chegar.
• Um IP antigo no www: o registro A da raiz foi atualizado, mas o www ainda aponta para o antigo.

Checklist para mudar de host

1. Com um dia de antecedência, reduza o TTL dos seus registros para que a troca seja assimilada rapidamente.
2. Anote seus registros atuais: A, MX, TXT e NS devem estar documentados antes de qualquer alteração.
3. Configure o site no novo servidor e teste pelo IP, sem mexer no domínio.
4. Troque o registro A e acompanhe as respostas de diferentes resolvers.
5. Confirme que o e-mail continua funcionando: MX e SPF são os registros mais esquecidos durante uma mudança.
6. Restaure o TTL original e verifique o certificado SSL no novo endereço.