SPF flattening

O SPF flattening é a prática de resolver todos os mecanismos baseados em consultas do seu registro SPF - include:, a, mx, ptr, exists e redirect= - até os endereços IP concretos por trás deles, publicando esses endereços diretamente como entradas ip4: e ip6:. O objetivo é simples: manter seu registro dentro dos limites rígidos que os receptores de e-mail impõem, para que os e-mails legítimos continuem sendo autenticados à medida que sua infraestrutura de envio cresce.

Esta página é o ponto central para tudo sobre SPF flattening. Ela explica o que é o flattening, por que o limite de 10 consultas força a questão, como o processo funciona passo a passo e onde estão os verdadeiros trade-offs e riscos. A partir daqui você pode aprofundar-se em tarefas específicas: como achatar um registro SPF, as melhores ferramentas de SPF flattening, se o SPF flattening afeta DKIM e DMARC, fazê-lo na Cloudflare e como o flattening se compara em SPF flattening vs macros.

O que é SPF flattening?

Um registro SPF é um único registro TXT, começando com v=spf1, que informa aos servidores de e-mail receptores quais hosts têm permissão para enviar e-mail em nome do seu domínio. Quando você adiciona um serviço - um CRM, uma plataforma de marketing, um helpdesk, um provedor de e-mail transacional - normalmente você adiciona um include: para ele. Cada include: aponta para o registro SPF de outro domínio, e o receptor precisa buscar esse registro no momento da avaliação. Essas buscas são consultas DNS, e elas se acumulam rapidamente.

O SPF flattening pega todas essas referências indiretas e as pré-resolve. Em vez de pedir ao receptor que persiga include:_spf.google.com através de registros _netblocks aninhados, um registro achatado simplesmente lista as faixas de IP subjacentes:

• Antes: v=spf1 include:sendgrid.net include:_spf.google.com a mx -all
• Depois: v=spf1 ip4:149.72.0.0/16 ip4:167.89.0.0/17 ip4:64.233.160.0/19 ip6:2a00:1450:4000::/36 -all

No momento da avaliação, o receptor não faz mais recursão pelos includes nem resolve alvos A/MX - ele apenas compara o IP de conexão com as faixas CIDR que você publicou. Isso reduz a contagem de consultas DNS em tempo de execução para efetivamente zero e mantém seu registro leve, rápido e confiável.

“O limite de 10 consultas é a razão isolada mais comum pela qual registros SPF corporativos quebram silenciosamente”, diz Brad Slavin, General Manager da DuoCircle e fundador do AutoSPF. “Em nossa experiência gerenciando SPF para mais de 2.000 domínios de clientes, o modo de falha é sempre o mesmo: uma equipe adiciona uma nova ferramenta SaaS, seu include empurra o total para além de 10 e os e-mails legítimos começam a falhar - mas ninguém percebe até que um cliente reclame de faturas ou redefinições de senha que não chegaram.”

Por que o limite de 10 consultas DNS força o flattening

De acordo com a RFC 7208, a avaliação de SPF é limitada a 10 consultas de mecanismos DNS e 2 consultas vazias (void lookups) por verificação. Exceder qualquer um dos limites produz um PermError - uma falha permanente que informa aos servidores receptores que seu e-mail não pode ser autenticado. O servidor não tenta novamente e não avalia o restante do seu registro. Ele simplesmente para, e cada mensagem do seu domínio falha no SPF.

A armadilha é que esse limite é invisível até você cruzá-lo. Uma pequena empresa que envia por meio de um único provedor nunca o atingirá. Mas as pilhas de e-mail modernas rotineiramente acumulam múltiplos ESPs, um CRM, um suporte técnico e e-mail interno - e cada um adiciona uma ou mais consultas. O Google Workspace sozinho consome cerca de quatro das suas dez consultas por meio de seus includes aninhados. Adicione Salesforce, Mailchimp, SendGrid e Zendesk e você facilmente chega a doze ou quinze. A décima primeira consulta nunca é avaliada, então qualquer serviço que estiver além desse ponto perde silenciosamente a autorização.

Veja quais mecanismos contam:

Aciona uma consulta DNS	Não aciona uma consulta
include:example.com	ip4:x.x.x.x[/CIDR]
a, a:example.com	ip6:…
mx, mx:example.com	all
ptr (desencorajado pela RFC 7208)
exists:domain
redirect=example.com

Como os mecanismos ip4: e ip6: não exigem resolução, o flattening troca todos os mecanismos baseados em consultas por mecanismos livres de consultas. Esse é todo o mecanismo pelo qual o flattening mantém você em conformidade. Uma maneira rápida de ver onde você está hoje é rodar seu domínio no SPF Checker, que expande cada include e conta suas consultas.

Por que o flattening importa para entregabilidade e segurança

O limite de 10 consultas não é apenas uma nota de rodapé técnica - ele está diretamente no caminho entre o seu e-mail e a caixa de entrada.

Entregabilidade. O DMARC depende de SPF e DKIM. Se o seu registro SPF retornar um PermError, o DMARC trata isso como uma falha, e e-mails legítimos podem ser colocados em quarentena ou rejeitados. Desde 2024, Google, Yahoo e Microsoft passaram a exigir que remetentes em massa se autentiquem com SPF, DKIM e DMARC, e agora rejeitam mensagens não conformes de imediato, em vez de encaminhá-las para o spam. Juntos, esses provedores cobrem cerca de 90% de uma lista de consumidores típica, então um único registro acima do limite pode cortar a entrega para a maior parte do seu público de uma só vez.

Segurança. Quando o SPF falha, os servidores receptores perdem a capacidade de distinguir seus e-mails legítimos de mensagens falsificadas. É exatamente essa lacuna que o phishing e o comprometimento de e-mail corporativo (BEC) exploram. Manter o SPF válido - e dentro do limite - preserva o sinal de autenticação que separa você de um invasor se passando pelo seu domínio.

Gerenciabilidade. À medida que sua marca cresce, cresce também a lista de plataformas que enviam em seu nome. O flattening reduz uma cadeia dispersa de includes a uma lista limpa de faixas de IP, fácil de ler, auditar e compreender.

Como o SPF flattening funciona, passo a passo

Seja feito manualmente ou por automação, o flattening segue o mesmo pipeline:

1. Descoberta. Leia seu registro SPF TXT atual e identifique todo mecanismo que aciona uma consulta - include, a, mx, exists, redirect.
2. Resolução recursiva. Siga cada cadeia de include, buscando o registro SPF do alvo e fazendo recursão até que todo o conteúdo upstream seja conhecido. Resolva os alvos a/mx para seus registros A/AAAA a fim de reunir endereços IPv4 e IPv6.
3. Deduplique e comprima. Mescle faixas sobrepostas e agregue blocos contíguos em notação CIDR para que o registro permaneça compacto.
4. Publique. Reescreva o registro como v=spf1 ip4:… ip6:… -all, respeitando o limite de 255 caracteres por string do TXT (divida em várias strings concatenadas se necessário) e atualize seu DNS.
5. Valide. Confirme a sintaxe, verifique se a contagem de consultas é 0-1 e envie e-mails de teste para confirmar SPF=pass e DMARC=pass.

Para o passo a passo completo com comandos e especificidades de provedores DNS, veja como achatar um registro SPF.

O detalhe: um registro achatado não é uma correção única

O flattening resolve o problema de consultas, mas introduz um novo. Quando você substitui um include: dinâmico por IPs estáticos, você assume a responsabilidade de manter esses IPs atualizados. Os provedores rotacionam sua infraestrutura de envio constantemente, e raramente notificam você quando o fazem.

“O equívoco sobre o SPF flattening é que ele é uma correção única”, diz Adam Lundrigan, CTO da DuoCircle e arquiteto do mecanismo de flattening do AutoSPF. “As faixas de IP dos fornecedores mudam constantemente - o Google rotacionou seus _netblocks três vezes só em 2025. Um registro achatado que não é re-resolvido automaticamente fica desatualizado e desautoriza silenciosamente remetentes legítimos. É por isso que o AutoSPF reexamina a cada 15 minutos.”

Esta é a coisa mais importante a entender sobre o flattening. Um registro achatado construído à mão é preciso no dia em que você o publica e vai lentamente ficando desatualizado depois. Quando um provedor adiciona uma nova faixa de IP, o e-mail dessa faixa começa a falhar no SPF - e, como a falha é silenciosa, você normalmente descobre por uma fatura devolvida ou uma redefinição de senha perdida, não por um alerta. Na telemetria do AutoSPF em 1.200 domínios, o flattening reduziu as taxas de PermError em 93% e melhorou as taxas de aprovação de DMARC em 7-12% nos primeiros 30 dias - mas somente quando o registro foi mantido atualizado. A rotatividade mediana de IPs de ESPs fica em 2-4 mudanças por semana para provedores de alto volume.

Os outros trade-offs que vale a pena planejar:

• Tamanho do registro. O flattening pode empurrar um registro TXT na direção dos limites de tamanho do DNS. Procure manter as respostas abaixo de cerca de 1.000-1.200 bytes para evitar fragmentação e truncamento de UDP, e prefira faixas CIDR agregadas em vez de enumerar endereços individuais.
• Autorização excessiva. Alguns includes autorizam muito mais da internet do que você realmente usa. Auditar e enxugar antes de achatar mantém sua superfície de ataque pequena.

Manual, por script ou automatizado?

Há três maneiras de achatar, com perfis de risco muito diferentes:

• Manual. Consulte cada include para obter seus IPs atuais, agregue-os e publique à mão. Gratuito e totalmente sob seu controle, mas trabalhoso e propenso a desatualizar no momento em que um provedor muda os IPs. Prático apenas para ambientes pequenos e estáticos.
• Por script. Um script em Python ou Go faz recursão pelos includes, resolve A/MX, mescla faixas CIDR e envia ao DNS via API de forma programada. Repetível e auditável, mas você é dono dos casos de borda, da proteção contra loops e da confiabilidade contínua.
• Serviço automatizado (dinâmico). Um serviço hospedado re-resolve continuamente seus includes, detecta mudanças de IP e republica automaticamente. Isso remove totalmente o fardo da manutenção, ao custo de uma dependência gerenciada.

Para qualquer organização que use provedores dinâmicos como Google Workspace, Microsoft 365, SendGrid ou Amazon SES, uma abordagem automatizada é fortemente preferível - toda a dificuldade do flattening está em acompanhar a rotatividade, e é exatamente isso que a automação resolve. Uma comparação completa das opções está em melhores ferramentas de SPF flattening.

Onde o AutoSPF se encaixa

O serviço de SPF flattening automático do AutoSPF foi criado especificamente para o problema de manutenção que torna o flattening arriscado. Ele descobre e expande seus includes aninhados, resolve as cadeias completas A/MX/AAAA, deduplica e comprime faixas em blocos CIDR mínimos e publica um registro achatado, validado e consciente do tamanho, que permanece abaixo do limite de 10 consultas.

Duas coisas o diferenciam:

• Ele reexamina a cada 15 minutos e atualiza automaticamente seu registro no momento em que os IPs de um provedor upstream mudam - de modo que um registro achatado nunca fica desatualizado silenciosamente.
• Ele resolve exatamente para os mesmos IPs para os quais seus includes resolvem - sem faixas amplas e excessivamente permissivas e sem autorização excessiva. Seu registro achatado autoriza precisamente os hosts que seus includes reais autorizam, e nada mais.

Além disso, ele oferece registros versionados com rollback em um clique, publicação canary/staging e alertas de deriva quando o e-mail chega de IPs fora do seu conjunto achatado atual. Ele se integra diretamente aos principais provedores de DNS, incluindo Route 53, Cloudflare, Google Cloud DNS e Azure DNS. Antes e depois de qualquer mudança, você pode confirmar que o registro resolve de forma limpa com o SPF Checker.

Flattening entre provedores DNS e em escala

A mecânica do flattening é a mesma em todo lugar, mas a publicação difere por plataforma. Na Cloudflare, por exemplo, você gerencia o registro TXT pelo painel ou pela API e precisa respeitar seu comportamento de divisão de strings - os detalhes estão em SPF flattening na Cloudflare.

Em escala SaaS - milhares de tenants, múltiplos fluxos de envio - o padrão vencedor é em camadas: segmente os fluxos de e-mail em subdomínios (por exemplo, mkt.example.com para marketing, tx.example.com para transacional), centralize a política com redirect= para um pequeno registro canônico, faça o flattening completo de provedores de alta rotatividade em conjuntos ip4/ip6 agregados e automatize a atualização com publicação baseada em diff, para que registros inalterados nunca causem rotatividade no DNS. Delegar remetentes pesados a subdomínios também mantém seu domínio organizacional enxuto e simplifica o alinhamento do DMARC.

O flattening altera o DKIM ou o DMARC?

O flattening só muda como os remetentes autorizados são expressos no SPF - ip4/ip6 em vez de include - não a identidade do seu domínio nem suas assinaturas DKIM. Desde que o SPF achatado seja publicado no domínio usado em seu MAIL FROM/Return-Path, o alinhamento do DMARC não é afetado e, ao eliminar o PermError, ele geralmente melhora as taxas de aprovação de DMARC quando o SPF é o identificador alinhado. A relação completa, incluindo como o DKIM frequentemente carrega o alinhamento para remetentes em massa, está em o SPF flattening afeta DKIM e DMARC.

Flattening vs macros de SPF

O flattening tradicional pré-resolve os includes em IPs estáticos, e é por isso que ele precisa de atualização constante. As macros de SPF seguem outro caminho: elas usam expansão dinâmica para que um único registro possa autorizar um número efetivamente ilimitado de remetentes sem nunca atingir o limite de 10 consultas - ao custo de complexidade adicional e suporte mais fraco de resolvers. Qual abordagem lhe convém depende de sua infraestrutura e do seu apetite por manutenção; a análise completa está em SPF flattening vs macros.

Perguntas Frequentes

O que é SPF flattening em termos simples?

O SPF flattening é o processo de substituir os mecanismos include:, a e mx do seu registro SPF pelos endereços IP reais para os quais eles resolvem. Isso dá aos servidores de e-mail receptores uma lista pronta de IPs autorizados, em vez de forçá-los a realizar consultas DNS, o que mantém seu registro dentro do limite de 10 consultas definido pela RFC 7208 e evita falhas de autenticação.

Por que o SPF flattening é necessário?

O flattening se torna necessário quando seu domínio excede o teto de 10 consultas DNS por avaliação da especificação SPF. Assim que você cruza esse limite, o SPF retorna um PermError e cada mensagem do seu domínio falha na autenticação, o que também pode fazer o DMARC falhar. Como a maioria das organizações usa vários remetentes terceiros que cada um adiciona includes, domínios em crescimento atingem o teto rapidamente e precisam do flattening para permanecer em conformidade.

O SPF flattening melhora a entregabilidade de e-mail?

Sim. Ao eliminar as condições de PermError e TempError causadas por consultas em excesso ou includes upstream lentos, o flattening mantém o SPF aprovando de forma confiável. Nos dados de clientes do AutoSPF, passar de 12-18 consultas para um registro totalmente achatado reduziu as falhas de DMARC relacionadas ao SPF em mais de 80% e melhorou a colocação na caixa de entrada de e-mails de marketing em 10-15% durante envios de pico.

Com que frequência um registro SPF achatado deve ser atualizado?

Com a mesma frequência com que seus provedores mudam os IPs. ESPs de alta rotatividade como SendGrid e Mailchimp justificam atualizações a cada 12-24 horas, suítes estáveis como Google Workspace e Microsoft 365 diariamente, e faixas estáticas auto-hospedadas semanalmente. Um registro mantido à mão quase sempre desatualiza - o AutoSPF contorna isso reexaminando a cada 15 minutos e republicando automaticamente sempre que uma faixa upstream muda.

O SPF flattening manual é seguro?

O flattening manual é seguro apenas para ambientes pequenos e estáticos onde os IPs de envio raramente mudam. Para qualquer domínio que use provedores dinâmicos, um registro construído à mão fica desatualizado assim que um provedor rotaciona sua infraestrutura, desautorizando silenciosamente remetentes legítimos. O flattening automatizado é fortemente preferível em qualquer escala real, porque acompanhar a rotatividade dos provedores é a parte difícil.

Devo usar -all ou ~all após o flattening?

Use -all (hard fail) quando estiver confiante de que sua lista achatada está completa e ativamente monitorada, pois ele dá aos receptores o sinal mais claro para rejeitar e-mails falsificados. Use ~all (soft fail) durante o rollout ou enquanto você ainda estiver adicionando remetentes com frequência. Uma boa prática é manter ~all até que os relatórios de DMARC mostrem uma janela de aprovação limpa e, então, apertar para -all.