SPF flattening: como resolver o limite de 10 consultas

O limite de 10 consultas explicado

O SPF (Sender Policy Framework) falha com permerror quando o servidor de e-mail de destino precisa fazer mais de 10 consultas DNS para resolver seu registro SPF. Isso acontece por causa de instruções include aninhadas: se o seu registro inclui um provedor, e esse provedor inclui outro serviço, cada etapa conta para o limite. Para corrigir isso, você precisa usar SPF flattening, que substitui essas consultas recursivas por uma lista estática de endereços IP.

Como engenheiro responsável pela entregabilidade, já vi esse problema aparecer principalmente com a "proliferação de fornecedores". Uma empresa começa com um provedor transacional, adiciona uma ferramenta de marketing, depois um CRM, e de repente o registro SPF vira um castelo de cartas. Quando a 11ª consulta é acionada, o servidor de destino para a busca e retorna um erro permanente. Isso significa que seu e-mail não é apenas marcado como spam: ele pode ser rejeitado por completo, porque a verificação de autenticação falhou na base.

Como funciona o limite de consultas

De acordo com a RFC 7208, o limite existe para evitar ataques de negação de serviço (DoS) contra a infraestrutura de DNS. Sem ele, um agente mal-intencionado poderia criar uma referência circular ou uma cadeia enorme de includes que obrigasse o servidor de destino a fazer centenas de consultas para um único e-mail.

O que conta como consulta?

Nem todo mecanismo do seu registro SPF é gratuito. Os seguintes disparam uma consulta DNS:

• include: o culpado mais comum. Ele diz ao servidor para consultar o registro SPF de outro domínio.
• a: consulta o registro A do domínio.
• mx: consulta os registros MX do domínio.
• ptr: consulta o DNS reverso (embora esteja obsoleto e deva ser evitado).
• exists: consulta um domínio específico para verificar se ele existe.

Mecanismos como ip4 e ip6 são gratuitos, porque o endereço IP está listado explicitamente no registro.

Anatomia de uma cadeia de consultas

Considere este registro SPF hipotético:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

À primeira vista, são 3 consultas. Mas, se _spf.google.com tiver mais três instruções include e spf.protection.outlook.com tiver quatro, você já está em 10 consultas. Se o registro do SendHQ também tivesse um include, você teria atingido o limite. Isso é uma "cadeia de include".

Identificando o permerror

Se você não tem certeza se atingiu o limite, use o Verificador de DNS de e-mail do SendHQ para validar seus registros. Em um log bruto ou em uma ferramenta de análise de cabeçalhos, você verá um resultado como este:

spf=permerror (too many DNS lookups)

Isso é diferente de um softfail (~all) ou de um fail (-all). Um permerror significa que a verificação SPF não pôde ser concluída. Quando isso acontece, o destinatário não consegue verificar se o remetente está autorizado, o que muitas vezes faz o e-mail ser descartado ou sinalizado por filtros agressivos.

O que é SPF flattening?

SPF flattening é o processo de resolver todos os mecanismos include, a e mx em uma lista simples de endereços ip4 e ip6.

Exemplo: antes e depois

Antes (recursivo):

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(Suponha que _spf.example.com resolva para 1.2.3.4 e _spf.vendor.com resolva para 5.6.7.8)

Depois (com flattening):

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

Ao converter o registro em uma lista de IPs, a contagem de consultas cai de 2 (ou mais) para 0. O servidor de destino vê os IPs imediatamente e valida o remetente sem novas consultas DNS.

Os trade-offs do flattening

O flattening é uma correção poderosa, mas traz um peso de manutenção significativo.

1. O problema dos IPs desatualizados

Quando você usa uma instrução include, está delegando ao provedor o gerenciamento dos endereços IP. Se o Amazon SES ou o SendGrid adicionarem uma nova faixa de IPs à sua infraestrutura, eles atualizam o próprio registro SPF, e seus e-mails continuam fluindo.

Se você achata esses registros no seu próprio DNS, passa a ser responsável por esses IPs. Se o provedor mudar um IP e você não atualizar sua lista achatada, seus e-mails vão falhar na autenticação SPF. Esse é o principal motivo pelo qual o flattening manual é perigoso para e-mail transacional de alto volume.

2. Limites de tamanho do registro

Registros DNS têm tamanho máximo. Uma única string em um registro TXT é limitada a 255 caracteres. Embora seja possível concatenar várias strings, alguns parsers de DNS mais antigos têm dificuldade com registros muito longos. Se você fizer o flattening de provedores demais, seu registro SPF pode ficar grande demais para ser processado corretamente.

Como corrigir cadeias de include

Se você está atingindo o limite de 10 consultas, siga esta hierarquia de soluções, da mais segura para a mais agressiva.

Passo 1: audite e faça a limpeza

Procure provedores antigos no seu registro. Muitas equipes ainda têm instruções include de serviços que deixaram de usar há três anos. Remova qualquer provedor que não envie mais e-mails em seu nome.

Passo 2: use subdomínios para tráfegos diferentes

Esta é a correção de arquitetura mais profissional. Em vez de colocar todos os serviços no domínio raiz, separe-os por função:

• Domínio raiz (example.com): e-mail corporativo (Google Workspace/Outlook).
• Subdomínio transacional (mail.example.com): SendHQ ou Amazon SES.
• Subdomínio de marketing (news.example.com): Mailchimp ou Klaviyo.

Cada subdomínio tem seu próprio registro SPF e seu próprio limite de 10 consultas. Isso isola o risco e impede que a cadeia SPF complexa de uma ferramenta de marketing quebre seus e-mails transacionais críticos.

Passo 3: SPF flattening dinâmico

O flattening dinâmico é um serviço que monitora em tempo real as cadeias de include dos seus provedores e atualiza automaticamente seu registro DNS com os endereços IP atuais. Isso resolve o problema dos "IPs desatualizados" automatizando a atualização via API.

O SPF no contexto da entrega moderna

É importante entender que o SPF é apenas uma peça do quebra-cabeça da autenticação. Para garantir que seus e-mails sejam aceitos pelo servidor de destino, você precisa coordenar o SPF com o DKIM e o DMARC. Você encontra uma explicação detalhada dessas relações no guia do SendHQ sobre DKIM, SPF e DMARC.

Aceitação vs. entrega vs. chegada à caixa de entrada

Como engenheiro, eu distingo estas três etapas:

1. Aceitação: o servidor de destino aceita a conexão e a mensagem. Um permerror de SPF pode fazer o servidor rejeitar a mensagem no nível SMTP, ou seja, ela nunca é aceita.
2. Entrega: a mensagem é aceita e movida para a caixa postal do usuário (ou para uma pasta).
3. Chegada à caixa de entrada: a mensagem chega à caixa de entrada principal, e não à pasta de spam.

O SPF flattening corrige um problema de aceitação. Ele não garante a chegada à caixa de entrada, que depende da reputação do remetente, do conteúdo e de métricas de engajamento.

Considerações especiais para agentes de IA

Com o crescimento de agentes de IA enviando e-mails por APIs, o risco de problemas de SPF aumenta, porque os agentes podem disparar grandes volumes de e-mails a partir de vários domínios. Ao construir fluxos com agentes, trate o envio de e-mail como um efeito colateral externo.

Idempotência e aprovação

Agentes nunca devem enviar e-mails em loop sem um mecanismo de segurança. Use uma chave de idempotência para garantir que a lógica de novas tentativas do seu agente não envie o mesmo e-mail transacional dez vezes a um cliente. Além disso, para e-mails críticos, implemente uma etapa de aprovação com humano no circuito antes da chamada à API.

Análise de custo dos provedores de envio

Ao escolher um provedor para incluir no seu registro SPF, considere o custo do volume que você envia. Com base nos preços de setembro de 2026:

• Amazon SES: custa 0.10 USD por 1.000 e-mails no modelo a la carte (preços do Amazon SES). Para 50.000 e-mails, isso dá aproximadamente 5 USD. Os novos planos em níveis, lançados em 21 de julho de 2026, incluem Essentials (0.16 USD por 1.000), Pro (0.22 USD por 1.000 mais 105 USD/mês/região) e Enterprise (0.23 USD por 1.000 mais 500 USD/mês).
• Postmark: 15 USD por mês para 10.000 e-mails, com excedente entre 1.80 e 1.20 USD por 1.000 (preços do Postmark). 50.000 e-mails nos planos do Postmark custam cerca de 66 USD.
• Resend: o plano gratuito oferece 3.000 e-mails por mês (limitado a 100/dia). O Pro custa 20 USD por mês para 50.000 e-mails, com excedente de 0.90 USD por 1.000 (preços do Resend).
• Mailgun: 15 USD por mês para 10.000 e-mails, com excedente de 1.80 a 1.10 USD por 1.000 (preços do Mailgun).
• SendGrid: o plano gratuito agora é um teste de 60 dias, e o Essentials começa em 19.95 USD por mês (preços do SendGrid).

Lista de verificação para solução de problemas de SPF

Se você suspeita de um problema com o limite de consultas, percorra esta lista:

• Execute uma verificação de DNS no domínio raiz e em todos os subdomínios de envio.
• Conte o número total de mecanismos include, a, mx e exists.
• Rastreie as cadeias de include de cada provedor para verificar se há consultas aninhadas.
• Identifique e remova provedores não utilizados.
• Avalie se o tráfego pode ser movido para um subdomínio dedicado (por exemplo, notifications.example.com).
• Se o limite ainda for excedido, implemente o flattening dinâmico de SPF.
• Verifique se o registro final não excede o limite de 255 caracteres por string.

Tabela-resumo: mecanismos SPF

Mecanismo | Consulta DNS? | Risco | Recomendação

ip4 / ip6 | Não | Baixo | Use para IPs estáticos

include | Sim | Alto | Use com moderação, monitore as cadeias

a | Sim | Médio | Evite se possível, use ip4

mx | Sim | Médio | Evite se possível

ptr | Sim | Alto | Não use (obsoleto)

Gerenciando seus registros SPF de forma proativa, você evita o permerror que destrói a entregabilidade antes mesmo de o e-mail chegar ao filtro de spam. Seja usando uma API simples ou um sistema complexo com agentes, manter o DNS enxuto é a melhor forma de garantir que seus e-mails transacionais sejam aceitos.

Para um conjunto completo de ferramentas de gerenciamento da autenticação do seu domínio, acesse https://sendhq.cc.