O seu registro SPF parece correto, todos os remetentes que você usa estão listados, e mesmo assim um dia um relatório de DMARC ou uma devolução mostra permerror. A causa habitual é o limite de 10 consultas DNS: o SPF só pode disparar um número fixo de consultas DNS durante a avaliação, e cada ferramenta que você adiciona com um include: gasta parte desse orçamento. Este guia mostra como contar suas consultas, quais termos custam uma e quais são gratuitos, e a ordem para corrigir um registro acima do limite sem quebrar o e-mail de um remetente esquecido.
A resposta curta#
O SPF é definido na RFC 7208, que diz que uma implementação deve limitar a 10 os termos que causam consultas DNS durante a avaliação. Os termos que contam são include, a, mx, ptr, exists e o modificador redirect. Os termos que não exigem consulta, ip4, ip6 e all, são gratuitos. A contagem é recursiva: um include: custa uma consulta, mais tudo o que há dentro do registro para o qual ele aponta. Passou de 10, a verificação devolve permerror, o que significa que o SPF não passa para nenhum e-mail do domínio. Para corrigir, apague os includes de ferramentas que você não usa mais, depois troque o que der por ip4/ip6 para servidores estáveis e então mude os remetentes em massa para um subdomínio. Só faça flattening como último recurso. O verificador de SPF, DKIM e DMARC e o verificador de saúde do domínio gratuitos mostram o registro que você publicou, mas não seguem os includes nem contam consultas, então conte à mão como descrito abaixo ou use uma ferramenta que faça a recursão.
O que conta para o limite#
| Termo | Custa uma consulta? | Observações |
|---|---|---|
include:domain | Sim, 1 mais o conteúdo dele | O registro incluído também é avaliado, então os includes dele contam |
a ou a:domain | Sim, 1 | Um termo, não importa quantos endereços devolva |
mx ou mx:domain | Sim, 1 | Fácil de esquecer; talvez você nem precise dele |
ptr | Sim, 1 | Desaconselhado na RFC; remova |
exists:domain | Sim, 1 | Raro, muito usado em configurações com macros |
redirect=domain | Sim, 1 mais o conteúdo dele | Ignorado se o registro também tiver um termo all |
ip4: e ip6: | Não | Gratuitos, mas você precisa mantê-los atualizados |
all | Não | Sempre por último; os termos depois dele nunca são avaliados |
Um exemplo concreto mostra como a conta sobe rápido.
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net mx a ~all"
Esse registro tem seis termos que custam consulta no nível superior, e cada include: pode conter mais termos por dentro. A contagem visível é 6, a contagem real é o que os registros aninhados somarem. Por isso um registro que parece curto pode estar acima do limite, e por isso o número muda sem você mexer no DNS: um provedor edita o próprio registro SPF e o seu total se move.
A RFC também diz que as implementações devem limitar a duas as "consultas vazias" (void lookups), aquelas que não devolvem nada. É uma recomendação, não uma exigência rígida, mas um termo include:, a ou mx que aponta para um nome que não existe mais é exatamente esse tipo de consulta. É mais um motivo para remover primeiro os includes mortos.
Passo 1: confirme que é um problema de contagem#
Antes de mudar qualquer coisa, descarte as outras causas de erro de SPF.
- Mais de um registro SPF. Dois registros TXT
v=spf1no mesmo nome também são um erro permanente, e é fácil criá-los sem querer quando a página de configuração de uma ferramenta manda adicionar um registro. Rodedig +short TXT example.come conte as linhas que começam comv=spf1. Se achar duas, junte-as. Quando SPF, DKIM e DMARC param de funcionar trata disso e das outras causas habituais. - Um erro de sintaxe. Um erro de digitação como
includesem domínio, uma faixaip4inválida ou um espaço faltando quebra o registro. - Um include em loop. Dois domínios que se incluem mutuamente nunca terminam de ser avaliados.
- Um include que aponta para o nada. O domínio de destino não publica nenhum registro SPF.
Se nada disso se aplica, conte as consultas. Faça isso à mão uma vez para entender a árvore: consulte o registro de nível superior, liste cada termo que custa consulta, depois consulte cada destino de include: e redirect= e repita. Uma ferramenta que segue os includes faz a recursão por você e vale a pena, porque um registro aninhado de um provedor pode ter vários níveis. Os verificadores gratuitos deste site leem o registro, mas não contam.
Passo 2: remova o que você não usa mais#
É a correção mais barata e costuma recuperar várias consultas. Percorra cada include: e pergunte se algo ainda envia por ele.
- Ferramentas de teste. Serviços que você experimentou por um mês e nunca removeu.
- Plataformas aposentadas. A ferramenta de marketing que você trocou há dois anos, ou o helpdesk antigo.
- Provedores que você só sabe nomear pelo include. Se você não sabe dizer o que é, descubra antes de apagar. Os relatórios agregados de DMARC mostram quais fontes realmente enviaram em nome do seu domínio, então um include que nunca aparece em um mês de relatórios é um bom candidato.
Apague um por vez, conte de novo e guarde o texto do registro antigo para poder voltar atrás. Remova também os termos mx e a soltos, a menos que você realmente envie desses hosts, e remova o ptr por completo.
Passo 3: troque includes por faixas de IP, com cuidado#
Para um remetente com um conjunto pequeno e estável de endereços, como o seu próprio servidor de e-mail, você pode trocar um include: ou mx por entradas ip4: e economizar consultas.
v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.google.com ~all
O custo é a manutenção. Uma entrada ip4: é a promessa de que você vai perceber quando os endereços mudarem. Faça isso apenas para a infraestrutura que você controla. Nunca copie a lista de IPs de um ESP grande para o seu registro: os provedores adicionam e aposentam endereços sem avisar, e a sua cópia fica desatualizada em silêncio.
Passo 4: mude os remetentes em massa e de marketing para um subdomínio#
Cada domínio de envio tem seu próprio registro SPF e seu próprio orçamento. Se a sua plataforma de marketing, o serviço transacional e o suporte enviam todos como example.com, eles dividem um único orçamento de 10. Dê à newsletter um subdomínio como news.example.com, publique ali um registro SPF curto e configure a plataforma para usá-lo no return-path e no endereço From. Isso também isola a reputação, o que o guia de subdomínio de envio explica por completo.
Tenha o DMARC em mente ao fazer isso. O alinhamento compara o domínio do From com o domínio que passou no SPF ou no DKIM. O alinhamento relaxado deixa news.example.com se alinhar com example.com, mas o remetente ainda precisa se autenticar em um desses domínios. Configurar o DMARC trata do alinhamento.
Passo 5: flattening, e por que ele fica desatualizado#
Flattening é trocar os termos include: pelos endereços IP literais para os quais eles resolvem, de modo que o registro não precise de consultas. Funciona, e também é a correção mais arriscada, porque o include existe justamente para que o provedor possa mudar os endereços sem que você edite o DNS. Um registro achatado congela os endereços no momento em que você o montou. Quando o provedor adiciona um servidor, o e-mail vindo dele falha no SPF até alguém atualizar o seu registro.
Aplicam-se mais dois limites. Um registro achatado pode passar do tamanho que um único registro TXT comporta com folga, e o DNS limita a resposta UDP, então registros grandes precisam ser divididos ou servidos com cuidado. E agora você é dono de uma rotina de atualização. Se for fazer flattening, use um serviço ou script que resolva de novo em intervalos e avise quando falhar, nunca uma cópia única colada à mão.
Para a maioria dos domínios, a ordem acima basta. Apagar primeiro, subdomínio em segundo, ip4 em terceiro, flattening por último.
Como manter a contagem sob controle#
A contagem de consultas não é fixa. Ela se move quando você adiciona uma ferramenta e quando um provedor edita o próprio registro, então um registro que passava em março pode falhar em setembro sem nenhuma mudança sua. Três hábitos mantêm você na frente.
- Conte antes de adicionar. Confira o total antes de adicionar qualquer include, para saber se o novo remetente cabe.
- Verifique de novo em intervalos. As verificações de saúde do domínio recalculam a contagem recursiva a cada vez.
- Alerte em 9, não em 11. Quando a contagem passa de 10, você já está falhando.
O monitoramento de saúde do domínio cuida dos dois últimos. Cada domínio coberto recebe uma verificação diária de SPF que segue includes e redirects e conta as consultas como descreve a seção 4.6.4 da RFC 7208. Ele emite um aviso com 9 ou 10 consultas e um problema de severidade grave acima de 10, e envia um e-mail quando isso acontece. Também sinaliza os outros problemas de SPF do passo 1: vários registros, erros de sintaxe, um include que não publica registro, um final +all ou ?all e o mecanismo ptr. Um limite a conhecer: cada relatório tem um orçamento de 40 consultas DNS por domínio, então em um registro muito grande alguns itens aparecem como não verificados e a contagem é um limite inferior. O argumento mais amplo para verificar mais do que o SPF está em monitoramento de saúde do domínio de e-mail, e os guias de SPF por provedor mostram o que cada remetente soma à sua contagem.
Perguntas frequentes
01O que é o limite de 10 consultas DNS do SPF?
A RFC 7208 diz que uma verificação de SPF deve limitar a 10 os termos que causam consultas DNS. Contam os termos include, a, mx, ptr, exists e redirect, e os includes aninhados também contam. Passar disso devolve permerror, que os receptores tratam como falha de SPF.
02Os mecanismos ip4 e ip6 contam para o limite?
Não. ip4, ip6 e all não precisam de consulta DNS, então são gratuitos. O custo é a manutenção: você precisa atualizar os endereços por conta própria sempre que o remetente os mudar.
03Fazer flattening do meu registro SPF é uma boa correção?
Funciona, mas congela os endereços atuais do provedor, então o e-mail falha quando ele adiciona servidores, a menos que o registro seja atualizado. Tente primeiro remover includes sem uso e mover os remetentes em massa para um subdomínio, e só faça flattening com atualização automática.
04Por que o meu SPF quebrou se eu não mudei nada?
Os includes são avaliados de forma recursiva, então quando um provedor edita o próprio registro SPF o seu total muda. Um registro com 9 ou 10 consultas pode passar do limite sem nenhuma edição sua, e é por isso que alertar antes de 10 é útil.
O SPF só diz quais servidores podem enviar em seu nome e não diz se as pessoas da sua lista querem receber seus e-mails, nem se elas existem. Os 100 créditos gratuitos na página de preços rodam a verificação completa em uma lista, para você ver quantos endereços devolveriam. Um registro que passa no SPF ainda precisa de uma lista saudável para conquistar a caixa de entrada.
