SPF, DKIM ou DMARC pararam de funcionar? Como achar a causa

Uma autenticação que passou por dois anos pode falhar numa terça-feira, sem mensagem de erro e sem nenhuma mudança de que você se lembre. Os e-mails continuam saindo dos seus servidores. Só que chegam no spam, ou como uma falha de DMARC num relatório que você não abriu, ou simplesmente não chegam. Este guia mostra o que costuma quebrar SPF, DKIM e DMARC depois de funcionarem, como achar a causa em minutos com algumas consultas DNS e como saber da próxima regressão antes que a sua taxa de devolução avise.

A resposta curta#

Quando uma autenticação que funcionava começa a falhar, algo mudou no DNS ou algo mudou no remetente. Verifique nesta ordem: o host de DNS ou os nameservers foram trocados recentemente, existe exatamente um registro SPF, o seletor DKIM da mensagem que falhou ainda devolve uma chave, existe exatamente um registro DMARC em _dmarc, e uma ferramenta nova passou a enviar em nome do seu domínio? Essas cinco perguntas explicam a maioria das regressões. Leia primeiro o cabeçalho Authentication-Results de uma mensagem que falhou, porque ele diz qual dos três, SPF, DKIM ou DMARC, falhou e para qual domínio. O analisador de cabeçalhos de e-mail mostra esses veredictos, e o verificador de SPF, DKIM e DMARC mostra o que o DNS diz neste momento.

Leia primeiro a mensagem que falhou#

Não adivinhe qual protocolo quebrou. Abra os cabeçalhos completos de uma mensagem que falhou e encontre a linha Authentication-Results adicionada pelo servidor receptor.

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounce.example.com;
  dkim=fail header.d=example.com header.s=mail;
  dmarc=fail header.from=example.com

Três detalhes importam. spf= e dkim= mostram qual verificação falhou. header.s é o seletor DKIM que foi usado, o que revela o nome DNS exato a consultar. E smtp.mailfrom ou header.d mostram qual domínio cada verificação avaliou, o que importa quando a mensagem passa no SPF para um domínio diferente do que está no cabeçalho From.

Depois consulte os registros pela linha de comando. Estes comandos funcionam no macOS e no Linux.

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com

Troque mail pelo seletor do cabeçalho. Se você não o conhece, como encontrar um seletor DKIM explica o caminho. Se a consulta não devolver nada, o registro sumiu. Se devolver algo, leia com atenção, porque a próxima seção mostra como um registro pode existir e ainda assim estar quebrado.

Causa 1: uma migração de DNS perdeu ou deformou registros#

Mudar para um novo host de DNS, um novo registrador ou uma nova plataforma de site é o gatilho mais comum. A ferramenta de importação copia o que entende, em geral registros A, CNAME e MX, e ignora ou reescreve os registros TXT em silêncio. Os sintomas são um domínio sem SPF, sem DMARC, ou com um seletor DKIM que não resolve mais, tudo começando na data da migração.

Verifique três coisas depois de qualquer mudança: se os nameservers realmente apontam para onde você pensa, se todos os registros de autenticação existem no novo host e se os valores TXT longos chegaram inteiros. As chaves DKIM longas são a vítima habitual: alguns hosts as truncam ou acrescentam espaços soltos, e uma chave cortada falha na verificação mesmo com o registro "existindo" (por que chaves longas precisam ser divididas). Os guias específicos por provedor para Cloudflare e Route 53 mostram como cada um lida com isso, e trocar de provedor de e-mail trata da mesma armadilha pelo lado do e-mail.

Causa 2: dois registros SPF, ou dois registros DMARC#

Um domínio pode publicar exatamente um registro SPF e exatamente um registro DMARC. Isso quebra em silêncio quando a página de configuração de uma ferramenta nova diz "adicione este registro TXT" e alguém acrescenta uma segunda entrada v=spf1 em vez de editar a primeira.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

Com dois registros assim, os receptores devolvem um erro permanente para o SPF, então o SPF falha em todas as mensagens, inclusive nas das ferramentas que estão listadas. A correção é juntá-los em um único registro, com os dois includes antes de ~all. A mesma regra vale em _dmarc: dois registros DMARC fazem os receptores ignorarem ambos. Fique de olho no orçamento de consultas ao juntar, porque cada include: adicionado custa consultas DNS e o limite é 10. SPF com consultas DNS demais explica como contar.

Causa 3: uma chave DKIM foi rotacionada, movida ou removida#

O DKIM assina cada mensagem com uma chave privada e publica a metade pública em selector._domainkey.yourdomain.com. Se o registro DNS desaparece enquanto o remetente ainda assina com esse seletor, toda mensagem falha no DKIM.

Isso acontece de algumas formas. Um provedor rotaciona para um novo seletor e você apaga o registro antigo cedo demais. Alguém exclui entradas _domainkey "sem uso" numa faxina do DNS. Um CNAME que aponta para uma chave hospedada pelo provedor deixa de resolver porque o provedor mudou algo ou porque você saiu do serviço. Ou a chave foi revogada, o que é publicado como um valor p= vazio.

O teste é simples: pegue o seletor do header.s da mensagem que falhou, consulte selector._domainkey.yourdomain.com e confirme que há um valor p= com dados de chave de verdade. Se o seletor estiver errado porque o remetente migrou para um novo, publique o novo registro que o provedor fornece. Uma rotação bem feita sobrepõe a chave antiga e a nova, como descreve o guia de seletores.

Causa 4: um novo remetente começou a enviar em nome do seu domínio#

Às vezes os seus registros estão certos e o que mudou foi o remetente. Uma equipe ativa um CRM, um helpdesk, uma ferramenta de faturamento ou uma plataforma de newsletter, e cada um passa a enviar com o seu domínio no endereço From. Se ninguém adicionou esse serviço ao SPF e configurou a chave DKIM dele, o e-mail falha no alinhamento do SPF, pode não passar em nada e aparece como falha nos relatórios de DMARC.

Você não vai pegar isso olhando o DNS, porque o DNS não mudou. Você pega olhando quem de fato está enviando. É para isso que servem os relatórios agregados de DMARC: uma fonte nova com taxa de aprovação baixa é a assinatura do problema. Para cada fonte assim, ou você a autentica direito (include no SPF quando fizer sentido e, mais importante, assinatura DKIM com o seu próprio domínio) ou impede que ela envie em seu nome.

Causa 5: um registro de apoio expirou ou mudou#

Algumas falhas ficam ao lado da autenticação, e não dentro dela.

• O destino de um CNAME mudou. Muitos provedores pedem que você aponte um registro para o hostname deles. Se eles o aposentam ou você apaga o CNAME, a chave ou o domínio do return-path deixa de resolver.
• Um host MX perdeu o endereço. Os e-mails para o seu domínio começam a ser devolvidos mesmo com a autenticação de saída perfeita, porque o host nomeado no MX não tem registro A nem AAAA.
• A política MTA-STS e o DNS saíram de sincronia. O registro TXT _mta-sts continua lá, mas o arquivo de política em HTTPS já não lista seus hosts MX atuais, ou o certificado de um servidor de e-mail expirou. Os remetentes que guardam uma política em modo enforce então adiam ou recusam o e-mail, enquanto os que não têm política em cache simplesmente voltam à entrega comum, então o dano é irregular. Veja MTA-STS e TLS-RPT.
• O DMARC foi endurecido. Alguém passou de p=none para quarantine ou reject. Falhas que sempre existiram, como uma ferramenta não autenticada ou e-mails encaminhados, agora custam entregas. A falha não era nova. Nova é a consequência.

Como pegar a próxima regressão cedo#

Quase tudo isso é detectável só pelo DNS, antes de uma única devolução, porque o estado quebrado é um registro ausente ou malformado. A exceção é tudo o que está por trás do registro DNS, como um arquivo de política MTA-STS. Verifique, nesta ordem de urgência:

1. O MX está presente e todos os hosts resolvem.
2. Exatamente um registro SPF, com sintaxe válida e 10 consultas ou menos.
3. Todo seletor DKIM do qual você depende devolve uma chave com valor p=.
4. Exatamente um registro DMARC com política válida e endereço rua=.

Você pode rodar isso à mão após cada mudança de DNS, e deve. A fraqueza da verificação manual é que a regressão que importa acontece quando ninguém está olhando. O monitoramento de saúde do domínio repete essas verificações em cada domínio coberto uma vez por dia e envia um e-mail quando um problema aparece e de novo quando é resolvido. Os códigos de problema correspondem a esta lista: SPF ausente ou múltiplo, SPF acima do limite de consultas, um include de SPF que não publica nenhum registro, um seletor DKIM configurado sem chave ou com chave revogada, DMARC ausente ou inválido e problemas de MX. Um artigo central, monitoramento de saúde do domínio de e-mail, explica o quadro mais amplo e com que frequência verificar.

Dois detalhes valem a pena. Você diz quais seletores DKIM observar, porque um seletor ausente só pode ser reportado se você o nomeou. E um timeout de DNS gera "não foi possível verificar", não um alerta, então você não é acordado por um resolvedor instável.

O que o monitoramento não pega#

O monitoramento de DNS lê apenas o DNS público. Ele não sabe que um CRM novo começou a enviar em seu nome, que um registro SPF válido está sem um remetente, nem que um provedor rotacionou uma chave que você nunca informou. Os relatórios agregados de DMARC mostram quem realmente envia como você, e o teste de entregabilidade de e-mail mostra como uma mensagem real se autentica. A lista completa de limites está no guia de monitoramento de saúde do domínio.

Uma autenticação que funciona prova que o e-mail é seu, não que a sua lista vale o envio. Quando você estiver pronto para olhar a lista em si, o plano gratuito na página de preços dá 100 créditos que rodam a verificação completa. Registros corretos ainda precisam de uma lista saudável por trás.