Uma boa solução de problemas de DNS para e-mail começa por um fato desconfortável: quando o SPF, o DKIM ou um CNAME de rastreamento não é verificado, a causa raramente é o registro que você pretendia publicar. Em geral, é a forma como o seu painel de DNS o armazenou. Uma chave com mais de 255 caracteres, um nome de domínio adicionado duas vezes, um par de aspas que passou a fazer parte do valor, um segundo registro SPF ou uma resposta antiga que ainda não expirou em algum cache. Vamos percorrer cada um desses casos, mostrar como verificá-los com dig e nslookup e terminar com uma tabela que você pode usar por sintoma.
Como os registros de e-mail vivem no DNS
Todo método de autenticação de e-mail se apoia em alguns tipos de registro. SPF e DKIM são publicados como registros TXT, o DMARC é um registro TXT em um nome que começa com _dmarc, e muitas plataformas de envio pedem registros CNAME para um hostname de return-path ou de rastreamento. Os registros MX direcionam o e-mail recebido. Um resolvedor pede um nome e um tipo, e a resposta traz um tempo de vida, ou TTL, que informa a cada cache por quanto tempo ele pode reutilizá-la.
Três detalhes explicam a maior parte dos problemas. Primeiro, os painéis de DNS são interfaces amigáveis sobre uma zona, e cada um faz suas próprias escolhas sobre nomes, aspas e divisão de valores. Segundo, existem caches em várias camadas, de modo que o mesmo nome pode dar respostas diferentes em lugares diferentes por algum tempo. Terceiro, alguns tipos de registro se excluem mutuamente no mesmo nome. Cobrimos o conjunto completo de registros em nosso guia de autenticação e o fluxo de verificação em verificação do seu domínio de envio. Este artigo é o complemento de diagnóstico.
Verifique primeiro o lugar certo: os servidores de nomes autoritativos
Antes de alterar qualquer coisa, descubra o que está realmente publicado. Um resolvedor público, como o que o seu notebook usa, pode guardar uma resposta mais antiga. Os servidores de nomes autoritativos são os que mantêm a sua zona e dão a resposta definitiva; por isso, sempre os consultamos primeiro.
# 1. Find the authoritative nameservers for the domain
dig NS example.com +short
# 2. Ask one of them directly for the record (no cache involved)
dig TXT selector1._domainkey.example.com @ns1.dns-host.example +noall +answer
# 3. Compare with what a public resolver says
dig TXT selector1._domainkey.example.com @9.9.9.9 +noall +answer
# 4. Check the TTL and the negative caching value
dig SOA example.com @ns1.dns-host.example +noall +answer
# nslookup equivalent
nslookup -type=TXT selector1._domainkey.example.com ns1.dns-host.exampleSe a resposta autoritativa estiver errada, o problema está no painel: corrija o registro. Se a resposta autoritativa estiver certa e o resolvedor público mostrar algo diferente, o problema é um cache: aguarde. Se ambas estiverem certas e a verificação ainda falhar, provavelmente você está consultando o nome errado, ou a plataforma espera um tipo de registro diferente. Essa única comparação elimina mais suposições do que qualquer outra coisa neste artigo.
Dica: Faça a consulta a partir de uma máquina que não use o seu próprio cache de DNS e lembre-se de que o resultado de um verificador web reflete o resolvedor dele, não o seu.
Strings TXT com mais de 255 caracteres e chaves DKIM de 2048 bits
Um registro TXT contém uma ou mais character-strings, e cada character-string é limitada a 255 bytes. Isso vem do formato original do DNS na RFC 1035, que armazena cada string com um comprimento de um byte. Um registro pode conter várias strings e, no SPF e no DKIM, o receptor as une em ordem, sem acrescentar espaços. As especificações de ambos dizem isso (RFC 7208 para o SPF, RFC 6376 para o DKIM).
O impacto prático recai sobre o DKIM. Uma chave pública RSA de 1024 bits em base64 fica perto do limite quando se somam as tags de versão e de tipo de chave, enquanto uma chave de 2048 bits tem aproximadamente o dobro do tamanho, de modo que só o valor de p= já tem várias centenas de caracteres. Ele precisa ser armazenado em mais de uma string. Nosso guia sobre rotação de chaves DKIM, seletores e tamanho da chave explica por que as chaves de 2048 bits valem o esforço.
| Como o seu painel se comporta | O que você deve fazer | Como verificar |
|---|---|---|
| Divide valores longos automaticamente | Cole o valor completo uma única vez, sem aspas e sem quebras de linha | O dig mostra várias strings entre aspas que, juntas, formam a chave completa |
| Espera que você informe blocos entre aspas | Divida em qualquer ponto abaixo de 255 caracteres, coloque cada parte entre aspas e separe com um único espaço | O texto unido é exatamente igual à chave original |
| Rejeita valores com mais de 255 caracteres | Procure uma configuração para registros longos ou outro modo de edição; consulte a hospedagem se não houver | A consulta retorna a chave completa, não uma truncada |
| Trunca o valor silenciosamente | Informe novamente em blocos e leia o resultado de volta | Uma chave que termina antes do fim falha no DKIM com erro de chave ou de sintaxe |
Como é uma divisão correta
O exemplo abaixo mostra o formato de um registro dividido. O texto da chave é inventado e abreviado para fins de ilustração. Em um registro real, os blocos somam a chave completa fornecida pela sua plataforma.
selector1._domainkey.example.com. 3600 IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
"q1x2example0invented0key0chunk0one0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
"IDAQAB" )Duas armadilhas são comuns. Não coloque um espaço dentro da chave ao dividi-la, porque o receptor concatena as strings e um espaço passaria a fazer parte da chave. E não corte o registro no meio do nome do seletor ou das tags. Se uma chave dividida falhar, compare o resultado unido com o original, caractere por caractere, usando uma ferramenta de diff de texto em vez de confiar nos olhos.
Particularidades de registradores e painéis de DNS
O mesmo registro pode ser informado de quatro maneiras diferentes em quatro painéis. Estas são as particularidades que mais encontramos.
O domínio é acrescentado duas vezes
Muitos painéis adicionam o nome da zona automaticamente. Se você digitar selector1._domainkey.example.com no campo de host, o painel pode armazenar selector1._domainkey.example.com.example.com. O sintoma é que o registro existe no painel, mas a consulta ao nome correto não retorna nada. Informe apenas a parte relativa, selector1._domainkey, e use @ ou deixe o campo vazio para o apex, dependendo do painel. Um ponto final normalmente marca um nome como totalmente qualificado em arquivos de zona, mas os painéis web variam; por isso, leia o nome salvo de volta com dig.
Aspas, quebras de linha e caracteres invisíveis
Copiar um valor de uma página web ou de um documento pode trazer aspas tipográficas, espaços não separáveis ou uma quebra de linha. Se o painel também adicionar as próprias aspas, você pode acabar com um caractere de aspas literal no início do valor, e um registro que começa com aspas não começa com v=spf1 nem v=DKIM1, portanto não é reconhecido. Cole primeiro em um editor de texto simples, depois no painel, e leia o resultado de volta.
O tipo de registro ou o nome errado
Às vezes as plataformas pedem um registro TXT onde você esperaria um CNAME, ou o contrário. Use o tipo exatamente como instruído. Verifique também se você está na zona certa: se o domínio usa servidores de nomes em um provedor, mas você editou a zona no registrador, a alteração nunca é servida. A consulta NS mostrada anteriormente indica onde está a zona ativa.
| Sintoma no painel | Causa provável | Correção |
|---|---|---|
| O registro mostra o domínio duas vezes no nome | O painel acrescentou a zona a um nome completo | Informe somente o nome relativo |
| O valor começa e termina com aspas apenas na saída da consulta | Normal para a saída de TXT do dig | Nenhuma alteração necessária |
| O valor contém aspas com escape ou aspas no início | Você adicionou aspas e o painel adicionou as dele | Remova as suas aspas |
| Registro salvo, mas a consulta não retorna nada | Foi editada uma zona que os servidores de nomes ativos não servem | Edite a zona no provedor indicado pelos registros NS |
| O painel não aceita um underscore no nome | Regra de validação de nomes do painel | Use outro modo de edição ou consulte o provedor de DNS |
CNAME no apex, flattening e conflitos de registros
Um CNAME diz que um nome é um alias de outro nome, de modo que o resolvedor deve segui-lo e usar as respostas de lá. Por isso, um CNAME não pode coexistir com nenhum outro registro no mesmo nome (RFC 1034 e RFC 2181). A raiz do seu domínio, o apex, precisa conter registros SOA e NS e geralmente também tem MX e TXT; portanto, um CNAME no apex não é válido.
Alguns provedores de DNS contornam isso com flattening ou com um tipo de registro de alias. O próprio provedor consulta o destino e retorna registros de endereço comuns no apex. Isso ajuda a apontar o endereço web da raiz para um serviço hospedado. Não ajuda na autenticação de e-mail. Se uma plataforma pedir um CNAME em um hostname como um subdomínio, coloque-o nesse subdomínio. Se a plataforma pedir um CNAME no domínio puro, peça a ela uma alternativa, como registros TXT e de endereço.
O conflito também ocorre no sentido inverso. Se você adicionar um CNAME a um nome que já tem um registro TXT, por exemplo um seletor DKIM que você havia publicado antes como TXT, um dos dois será rejeitado ou ignorado, dependendo do painel. Exclua o registro antigo antes de adicionar o CNAME. Essa situação é comum durante uma troca de provedor, e nosso guia de migração trata da ordem das etapas.
Registros SPF duplicados e outras duplicatas
Um domínio pode publicar apenas um registro SPF, que é um registro TXT começando com v=spf1. Se os receptores encontrarem dois, o resultado é um erro permanente (RFC 7208), e o SPF falha para todas as mensagens, não apenas para as de um fornecedor. Isso acontece quando duas equipes adicionam, cada uma, o registro que o seu fornecedor pediu.
| Situação | O que os receptores veem | Correção |
|---|---|---|
| Dois registros TXT, ambos começando com v=spf1 | Erro permanente, o SPF não passa | Una em um único registro com todos os mecanismos include |
| Um registro, mais de 10 consultas | Erro permanente após o limite de consultas | Faça flattening ou remova includes; veja o guia de consultas SPF |
| Dois registros DMARC em _dmarc | A política pode ser ignorada | Mantenha um único registro |
| O mesmo seletor publicado duas vezes com chaves diferentes | Seleção de chave imprevisível | Exclua a chave antiga ou use um novo seletor |
Unir é simples em princípio: pegue os mecanismos include e ip4 de cada registro, coloque-os em um único registro v=spf1 e termine com um único qualificador all. A parte mais difícil é a contagem de consultas, que explicamos em o guia sobre o permerror do SPF e em gerenciamento de vários fornecedores em um domínio.
Registros com proxy: desative o proxy de DNS para e-mail
Alguns provedores de DNS oferecem um modo proxy, muitas vezes exibido como um ícone de nuvem colorido ao lado de um registro. Nesse modo, o provedor responde às consultas do nome com os próprios endereços e faz o tráfego web passar pela sua rede. Isso é útil para sites e inútil para e-mail.
Se um CNAME relacionado a e-mail estiver com proxy, a consulta deixa de retornar o destino que a sua plataforma de envio espera. A verificação falha, os hostnames de return-path ou de rastreamento não resolvem para o servidor correto e os certificados HTTPS dos domínios de rastreamento podem não ser emitidos. O hostname de um servidor de e-mail com proxy não aceitará conexões SMTP, porque o proxy trata portas web e não portas de e-mail. Por isso, defina todos os registros relacionados a e-mail como somente DNS: destinos MX, registros A de servidores de e-mail, CNAMEs de hostnames de return-path e de rastreamento e CNAMEs de DKIM. Os registros TXT nunca passam por proxy, portanto não são afetados. Nosso guia sobre domínios de return-path e de rastreamento explica por que esses hostnames devem resolver diretamente para a plataforma.
Verificação: Uma consulta dig a um nome com proxy retorna endereços que não pertencem à sua plataforma, mesmo que você tenha salvo um CNAME. Esse é o sinal de que o proxy está ativado.
Escolhas de TTL e planejamento de alterações
O TTL é o número de segundos pelo qual um resolvedor pode guardar uma resposta. Um TTL longo reduz as consultas e torna o registro mais resiliente caso os seus servidores de nomes fiquem brevemente indisponíveis. Um TTL curto permite se recuperar rapidamente de um erro. A abordagem sensata é variá-lo conforme a fase.
| Fase | TTL sugerido | Por quê |
|---|---|---|
| Criação ou teste de um novo registro | 300 a 600 segundos | As correções aparecem rapidamente |
| Antes de uma alteração planejada | Reduza o TTL com bastante antecedência, por pelo menos o tempo do TTL atual | Os caches antigos expiram antes de você trocar |
| No dia da alteração | Mantenha-o curto | Você pode reverter |
| Registros estáveis | 3600 segundos até um dia | Menos consultas e menor exposição a indisponibilidades |
O ponto-chave do planejamento de alterações é que reduzir um TTL não ajuda de imediato. Os caches que já guardam o registro o mantêm pelo TTL antigo. Se um registro tem TTL de 86400 segundos, reduza-o pelo menos um dia antes da alteração. Depois altere o valor, aguarde, verifique e aumente o TTL novamente.
Propagação e cache negativo
As alterações de DNS não se espalham a partir de um único ponto. Não existe um envio global. O que as pessoas chamam de propagação é simplesmente o tempo que os caches levam para expirar. Os servidores autoritativos respondem com o novo valor assim que a zona é salva e carregada, e cada resolvedor muda quando a cópia em cache termina. Alguns resolvedores ignoram TTLs muito baixos ou mantêm as respostas um pouco mais; por isso, deixe uma margem.
Há um segundo cache fácil de esquecer: o cache negativo. Se um resolvedor perguntou por um nome que ainda não existia, ele lembra a resposta de "não encontrado", e a RFC 2308 diz que esse tempo se baseia no registro SOA (o menor entre o TTL do SOA e o seu campo mínimo). Se a sua plataforma verificou o registro alguns minutos antes de você adicioná-lo, a falha pode continuar em cache até esse tempo acabar, mesmo que o registro agora exista.
Um exemplo prático
Imagine um domínio cujo registro TXT de DKIM foi publicado às 10:00 com TTL de 3600 segundos e tempo de cache negativo do SOA de 900 segundos. Às 10:05, a plataforma verifica cedo demais e recebe "não encontrado"; assim, esse resolvedor guarda a falha em cache até cerca de 10:20. Às 10:10 você nota um erro de digitação, corrige a chave e a salva. Os servidores autoritativos passam a dar a nova resposta. Um resolvedor que guardou o primeiro registro às 10:00 pode continuar servindo o antigo até as 11:00. Um que guardou o "não encontrado" pode servi-lo até as 10:20. Portanto, um resultado totalmente limpo em todos os resolvedores pode levar até as 11:00, mas uma verificação feita diretamente nos servidores autoritativos passa às 10:10. Nesse caso, você usa o resultado autoritativo para confirmar que a sua edição está correta e depois aguarda o maior tempo de cache, 60 minutos, antes de pressionar o botão de verificar novamente.
Quando a plataforma repete as verificações automaticamente, talvez você não precise fazer nada. Quando ela só verifica ao clicar no botão, aguarde o maior período de cache que você calculou. Não altere o registro de novo enquanto espera, porque cada alteração reinicia o relógio dos caches que se atualizam.
Uma tabela de diagnóstico por sintoma
| Sintoma | Causa mais provável | Primeira verificação | Correção |
|---|---|---|---|
| A plataforma diz que o registro DKIM não foi encontrado | Nome duplicado, zona errada ou ainda sem propagação | Faça um dig no nome exato do seletor no servidor autoritativo | Corrija o campo de host ou aguarde os caches |
| O DKIM é verificado, mas a assinatura falha com erro de chave | Chave truncada ou dividida com um espaço | Una as strings TXT e compare com o original | Informe novamente em blocos sem espaços |
| O SPF retorna permerror | Dois registros SPF ou mais de 10 consultas | Faça um dig TXT no apex e conte os registros v=spf1 | Una os registros, reduza as consultas |
| O registro SPF parece ignorado | Aspas literais ou espaço inicial no valor | Procure um valor que não comece com v=spf1 | Remova os caracteres soltos |
| O CNAME não é salvo | Existe outro registro nesse nome, ou o nome é o apex | Liste todos os tipos de registro no nome | Remova o conflito ou use um subdomínio |
| O CNAME existe, mas a verificação falha | Proxy de DNS ativado ou destino digitado errado | O dig retorna o destino esperado? | Defina como somente DNS, corrija o destino |
| Funciona no seu computador, falha na plataforma | Caches de resolvedores diferentes | Consulte o servidor autoritativo e dois resolvedores públicos | Aguarde o TTL mais antigo |
| O registro existe, mas a verificação ainda informa não encontrado | Cache negativo | Veja os valores do SOA e o horário da primeira verificação | Aguarde o tempo de cache negativo |
| O relatório DMARC não mostra política | Registro no nome errado | Verifique se o nome começa com _dmarc | Mova-o para _dmarc.seudominio |
Problemas no nível do cabeçalho, ao contrário dos problemas no nível do registro, são mais fáceis de confirmar na própria mensagem. Veja como ler cabeçalhos de e-mail para entender o que os resultados de autenticação significam quando o DNS está correto.
Uma rotina prática que você pode repetir
- Identifique. Anote o nome e o tipo exatos que a sua plataforma pede.
- Localize. Encontre os servidores de nomes ativos com uma consulta NS e confirme que você está editando essa zona.
- Informe. Use o nome de host relativo, cole o valor sem aspas adicionais e divida strings longas somente se o seu painel precisar.
- Leia de volta. Consulte o servidor autoritativo e compare o resultado com o original.
- Limpe. Remova duplicatas, seletores antigos com o mesmo nome e tipos de registro conflitantes.
- Proxy desativado. Confirme que os registros relacionados a e-mail estão definidos como somente DNS.
- Espere com inteligência. Calcule o maior entre o TTL antigo e o tempo de cache negativo.
- Verifique. Execute a verificação da plataforma e envie uma mensagem de teste. Consulte a sua conta MigoSMTP ou a documentação da API para ver os nomes e valores exatos dos registros a publicar.
Checklist antes de pedir ajuda
- O nome do registro foi lido de volta do servidor de nomes autoritativo e corresponde exatamente ao que a plataforma pediu.
- Nenhum sufixo de domínio aparece duas vezes no nome armazenado.
- O valor não tem aspas coladas, quebras de linha nem espaços dentro de chaves longas.
- Os valores TXT longos estão completos quando as strings são unidas.
- Existe apenas um registro SPF no nome, e a contagem de consultas está dentro do limite.
- Nenhum CNAME compartilha um nome com outro registro, e nenhum CNAME está no apex.
- Todos os registros relacionados a e-mail estão definidos como somente DNS, sem proxy.
- Você aguardou o TTL antigo e o tempo de cache negativo antes de verificar novamente.
- A zona que você editou é aquela para a qual os registros NS apontam.
Preso a um registro que não é verificado? Envie-nos o nome do registro, o valor exato que você publicou e a saída de uma consulta dig ao seu servidor de nomes autoritativo, e ajudaremos você a encontrar a diferença.
Leitura complementar e fontes
Perguntas frequentes
Por que meu registro DKIM diz que é longo demais?
Uma única character-string de DNS comporta no máximo 255 bytes, e uma chave pública RSA de 2048 bits em base64 é mais longa que isso. O registro em si pode conter várias strings, e os receptores as unem sem espaços. Alguns painéis dividem o valor para você, outros pedem que você informe blocos entre aspas, e alguns rejeitam um valor longo de imediato. Verifique como o seu painel lida com isso e confirme o resultado com uma consulta TXT.
Devo colocar aspas no valor do TXT?
Depende do painel. Muitos formulários web adicionam as aspas por você; assim, ao incluir as suas, o valor passa a ter um caractere de aspas literal e o registro não é interpretado corretamente. Editores de arquivo de zona e algumas ferramentas de linha de comando esperam aspas. Leia o registro de volta com dig após salvar e, se vir aspas duplicadas ou com escape, remova as suas.
Por que meu registro virou selector._domainkey.example.com.example.com?
O painel acrescenta o seu domínio ao que você digita no campo de host. Se você informa o nome completo, o domínio é adicionado duas vezes. Informe apenas a parte anterior ao seu domínio, como selector._domainkey, ou siga a dica exibida no painel. Um ponto final geralmente indica ao painel que o nome está completo, mas nem todo painel o trata assim; por isso, teste com uma consulta.
Posso colocar um CNAME no meu domínio raiz?
O DNS padrão não permite, porque um CNAME não pode coexistir com outros registros no mesmo nome e o domínio raiz precisa conter registros SOA e NS. Alguns provedores oferecem um recurso de flattening ou alias que retorna registros de endereço na raiz. Use-o para tráfego web, se precisar, mas não como substituto dos registros TXT e MX de que o e-mail necessita na raiz.
Tenho dois registros SPF. Isso é mesmo um problema?
Sim. Um domínio deve publicar apenas um registro SPF, e os receptores que encontram mais de um retornam um erro permanente em vez de escolher um deles. Una os mecanismos em um único registro. Nosso guia sobre vários fornecedores em um mesmo domínio explica como fazer isso sem exceder o limite de consultas.
Qual TTL devo definir?
Use um TTL curto, de 300 a 3600 segundos, enquanto estiver criando ou alterando registros, e um mais longo, de várias horas a um dia, quando tudo estiver estável. O número ideal é um equilíbrio entre a rapidez com que você consegue reverter e a carga que você coloca sobre os seus servidores de nomes.
Corrigi o registro, mas a verificação continua falhando. Por quê?
Ou um resolvedor ainda guarda a resposta antiga até o TTL expirar, ou guarda uma resposta de "não encontrado" em cache até o fim do tempo de cache negativo, ou você está verificando um nome diferente daquele que a plataforma consulta. Consulte os servidores de nomes autoritativos para ver a realidade e depois aguarde os caches.
Por que os CNAMEs de e-mail não podem ter proxy?
Um proxy de DNS responde às consultas com os próprios endereços, em vez do destino real do seu registro. Uma plataforma de e-mail precisa ver o destino do CNAME ou o endereço real do servidor; por isso, um registro com proxy falha na verificação e pode quebrar o rastreamento ou o tratamento de bounces. Defina esses registros como somente DNS.
Em qual ferramenta devo confiar: dig, nslookup ou um verificador web?
Todas servem, desde que você saiba o que cada uma consulta. O dig e o nslookup permitem escolher o servidor, o que é a chave para separar um problema de publicação de um problema de cache. Os verificadores web normalmente consultam de um único local por meio de um resolvedor público; por isso, uma divergência em relação ao seu resultado local geralmente significa apenas caches diferentes.