Um email de redefinição de senha é enviado. Nunca chega. Nenhuma mensagem de erro do lado do remetente, nenhum bounce, sem alerta na sua ferramenta de envio. Apenas o silêncio. Em alguns casos, a causa é um registro SPF que excedeu seu limite de 10 consultas DNS, sem que ninguém na organização percebesse. Isso é o que chamamos de PermError. Acontece muito mais frequentemente do que se imagina em empresas que utilizam diversos serviços SaaS para seus envios.
O que é o limite SPF e por que ele existe
O SPF (Sender Policy Framework) é um protocolo de autenticação de email que permite a um domínio declarar quais servidores estão autorizados a enviar em seu nome. O limite de 10 consultas DNS por verificação SPF está inscrito na RFC 7208 (IETF, 2014), a especificação oficial do protocolo. Não é opcional: a RFC estipula que uma implementação SPF deve retornar um erro permanente se este limite for excedido.
A razão técnica é concreta. Cada mecanismo SPF do tipo include:, a, mx, ptr ou exists aciona uma consulta DNS adicional. Sem um limite, uma regra SPF maliciosa ou mal configurada poderia forçar os servidores receptores a realizar dezenas de consultas DNS, criando uma carga excessiva nos resolvedores recursivos e abrindo a porta para ataques de negação de serviço. Os mecanismos ip4:, ip6: e all não acionam consultas e não contam no limite.
Este teto data de uma época em que uma empresa raramente tinha mais de um ou dois prestadores de envio de email. Em 2014, o Microsoft 365 não existia sob esse nome, o Salesforce Marketing Cloud ainda se chamava Exact Target, e o HubSpot representava apenas uma fração de seu uso atual. O limite foi pensado para um mundo que não é mais o nosso.
Por que as empresas SaaS de hoje atingem esse limite sem perceber
O problema está na forma como os serviços de email modernos publicam seus próprios registros SPF. Um include: para um prestador não custa apenas uma consulta: custa tantas consultas quantas o prestador definiu em seu próprio registro, incluídas as inclusões em cascata. O Google Workspace (_spf.google.com) consome entre 3 e 5 consultas sozinho. O Microsoft 365 (spf.protection.outlook.com) consome de 3 a 5, dependendo da configuração regional. Adicione SendGrid (1 a 3), Salesforce (1 a 3) e HubSpot (1 a 2): o total ultrapassa 10 antes mesmo de adicionar o serviço de faturamento, a plataforma RH ou a ferramenta de suporte.
O que agrava a situação: os prestadores podem modificar sua infraestrutura DNS sem aviso prévio. O serviço ao qual você delegou um include: há seis meses pode ter adicionado novos servidores desde então, fazendo o seu número de consultas passar de 9 para 12 sem qualquer ação do seu lado. De acordo com dados de dmarcchecker.app sobre o top 1 milhão de domínios (2024), 2% dos domínios com um registro SPF válido já têm uma configuração inválida que causa um PermError. Esse número parece pequeno, mas representa milhares de organizações cujos emails legítimos são afetados continuamente, muitas vezes sem que as equipes de TI saibam.
O que acontece concretamente quando o limite é ultrapassado
Quando uma verificação SPF atinge 11 consultas DNS, o servidor receptor retorna um resultado de permerror, um erro permanente irrecuperável. O que acontece com o email a seguir depende da política DMARC configurada no domínio remetente.
Com p=none, o email geralmente é entregue apesar do PermError. O domínio é tratado como não autenticado. É uma falsa tranquilidade: os emails passam. A proteção contra a falsificação do domínio não existe. Com p=quarantine, os emails vão para o spam, sem alerta do lado do remetente. Com p=reject, a política mais rígida e aquela que Google e Yahoo exigem desde fevereiro de 2024 para remetentes que enviam mais de 5000 mensagens por dia, os emails são rejeitados. Confirmações de pedido, redefinições de senha, alertas de segurança e comunicações internas desaparecem sem deixar rastros nas ferramentas de envio.
É o cenário mais difícil de diagnosticar. O email é enviado. Não retorna. Não chega.
O SPF flattening: por que a solução rápida piora as coisas
A reação mais comum a esse problema é o “flattening” SPF: substituímos todos os mecanismos include: pelos endereços IP correspondentes, o que reduz o número de consultas a zero ou quase. O resultado imediato é positivo. Os efeitos a médio prazo são mais problemáticos.
O CTO da dmarcian resume bem o problema de fundo: a maioria dos registros flattening acabará autorizando faixas de endereços IP muito amplas, pertencentes a grandes provedores de nuvem, das quais uma parte não corresponde a nenhum servidor de envio real do prestador. Atores maliciosos podem explorar essas faixas autorizadas para enviar a partir do seu domínio. Resolvemos um problema de deliverability criando um problema de segurança.
A outra dificuldade é a manutenção. Os prestadores de email mudam suas pools de IP regularmente, sem aviso prévio. Um registro flattening precisa ser atualizado manualmente a cada alteração, caso contrário, os novos servidores do prestador ficam excluídos, e os emails que eles tratam falham na autenticação SPF. O flattening transforma um problema de configuração em uma carga operacional permanente.
As abordagens que duram no longo prazo
A primeira etapa é uma auditoria do número real de consultas. Ferramentas como MXToolbox e o SPF Record Checker da dmarcian analisam seu registro SPF e contam as consultas em cascata, incluindo inclusões aninhadas. Sem essa auditoria, é impossível saber onde realmente está o contador.
A segmentação por subdomínios é a solução arquitetural mais confiável. Mover emails de marketing para marketing.seudominio.com e emails transacionais para notificacoes.seudominio.com dá a cada subdomínio sua própria cota de 10 consultas. Essa separação tem uma vantagem adicional: um problema de reputação nas campanhas de marketing não afeta os emails transacionais críticos.
Para os domínios que não podem criar segmentações facilmente, as macros SPF são uma alternativa séria. Elas movem a avaliação para fora da sequência de consultas padrão, passando a verificação para um serviço externo por meio de uma única consulta DNS. Soluções funcionam nesse princípio. O revés é real: se a infraestrutura do prestador cair, a autenticação SPF do domínio cai junto.
A medida mais frequentemente negligenciada continua sendo a remoção de entradas que se tornaram desnecessárias. Muitos registros SPF acumulam include: para prestadores que a empresa não utiliza há meses ou mecanismos a e mx herdados de uma configuração antiga. Uma auditoria anual frequentemente recupera várias consultas sem tocar na arquitetura de envio.
Monitorizar ao longo do tempo, não apenas corrigir uma vez
Um registro SPF conforme hoje pode ultrapassar o limite amanhã se um prestador modificar sua infraestrutura. Os relatórios DMARC agregados (formato RUA) são o indicador mais acessível: eles mostram a proporção de emails que passam ou falham na autenticação SPF para cada domínio remetente declarado. Qualquer pico repentino de falhas SPF merece uma investigação imediata sobre o número de consultas.
O limite das 10 consultas SPF é uma restrição de 2014 que a RFC 7208 não revisou desde então. As organizações que mudam para o DMARC em modo de aplicação, como o Google exige desde 2024 para remetentes de alto volume, às vezes a descobrem no pior momento: quando seus emails críticos param de chegar e ninguém sabe por quê.
O que é um PermError SPF?
Um PermError SPF é um erro permanente retornado pelo servidor receptor quando a verificação SPF não pode ser concluída, principalmente porque o número de consultas DNS excede 10. Ao contrário de um TempError (erro temporário recuperável), um PermError persiste até que o registro SPF seja corrigido. O DMARC trata um PermError como uma falha SPF completa.
Os mecanismos ip4 e ip6 contam no limite das 10 consultas?
Não. Os mecanismos ip4:, ip6: e all não acionam qualquer consulta DNS e não contam no limite. Apenas os mecanismos que necessitam de uma resolução DNS são contabilizados: include:, a, mx, ptr, exists e o modificador redirect.
Como saber se meu registro SPF ultrapassa o limite?
Ferramentas como o MXToolbox SPF Checker e o verificador de domínio da dmarcian analisam o registro SPF e contam as consultas DNS em cascata, incluindo inclusões aninhadas. Um resultado superior a 10 confirma que o registro retorna um PermError a cada verificação, independentemente da política DMARC em vigor.
