Como achatar um registro SPF

Achatar um registro SPF significa substituir os mecanismos que acionam consultas DNS — include:, a, mx, exists, ptr e redirect — pelas faixas explícitas ip4: e ip6: para as quais eles resolvem. O resultado é um registro que autoriza exatamente os mesmos remetentes, mas força os servidores receptores a percorrer bem menos (idealmente zero) consultas DNS, mantendo você com segurança abaixo do limite de 10 consultas da RFC 7208. Este guia percorre o processo passo a passo, mostra como fica um registro achatado e explica como mantê-lo preciso depois que ele entra no ar.

Esta página faz parte do nosso guia mais amplo sobre SPF flattening. Se você quiser pular todo o trabalho manual, o SPF Checker expande cada include e conta suas consultas em segundos.

Por que você achataria um registro SPF em primeiro lugar

A autenticação SPF é limitada a 10 consultas DNS por avaliação sob a RFC 7208. Cada termo include:, a, mx, exists e redirect conta nesse orçamento, e cada um pode acionar novas consultas recursivas dentro do domínio para o qual aponta. Adicione uma plataforma de marketing, um CRM, um helpdesk e um serviço de faturamento, e um único registro v=spf1 pode discretamente inchar para 15-40 consultas.

Quando você cruza o limite, os receptores retornam um PermError. Um PermError não falha apenas uma mensagem — ele invalida o registro inteiro, então e-mails legítimos de todas as fontes autorizadas podem começar a falhar no SPF. Como nada é devolvido de forma barulhenta, as equipes muitas vezes não percebem até que um cliente relate uma fatura ou um e-mail de redefinição de senha que não chegou.

O flattening resolve isso ao resolver esses mecanismos indiretos com antecedência e publicar os IPs brutos. Um receptor que avalia um registro totalmente achatado faz uma simples correspondência de IP, sem travessia recursiva de DNS, o que também significa validação mais rápida e nenhuma exposição a uma interrupção temporária de DNS de terceiros.

Como fica um registro SPF achatado

Aqui está um registro típico não achatado que se apoia em três includes:

v=spf1 include:_spf.google.com include:vendor.com include:vendor2.net -all

Cada include é ao menos uma consulta, e o include do Google sozinho aninha várias outras. Achatada, a mesma autorização se torna uma lista direta de IPs:

v=spf1 ip4:203.0.113.5 ip4:192.168.1.1 ip4:185.23.45.67 -all

Nenhuma consulta acontece no momento da avaliação, porque cada endereço autorizado já está detalhado. O qualificador -all é preservado, para que a política permaneça rígida.

Como achatar um registro SPF, passo a passo

Passo 1: Encontre e audite seu registro atual

Recupere seu registro SPF existente com uma consulta dig TXT yourdomain.com (ou o painel do seu provedor de DNS) e confirme que você tem exatamente um registro TXT v=spf1. Múltiplos registros SPF no mesmo nome são, por si só, um PermError. Anote quais mecanismos causam consultas (include, a, mx, exists, redirect, ptr) versus as entradas gratuitas ip4/ip6 que você pode manter como estão.

Passo 2: Conte suas consultas

Antes de mudar qualquer coisa, meça o quão acima do orçamento você está. Rode seu domínio no SPF Checker, que expande recursivamente cada include e fornece uma contagem exata de consultas. Se você está em 8 ou mais, ou já vendo PermError, o flattening (ou a delegação) se justifica. Se você está em 3 ou menos includes estáveis, talvez não precise achatar de forma alguma.

Passo 3: Resolva recursivamente cada mecanismo em IPs

Este é o núcleo do flattening. Para cada termo que causa consulta, resolva-o até endereços explícitos:

Mecanismo	Como resolvê-lo	Resultado
include:	Busque o registro SPF do alvo e expanda seus mecanismos recursivamente	ip4:/ip6: para cada IP que ele autoriza
a	Resolva os registros A/AAAA do domínio	Um ip4:/ip6: por endereço
mx	Resolva os registros MX e depois o A/AAAA de cada host de e-mail	ip4:/ip6: para cada IP de host MX
ptr	Não achate — está obsoleto, é lento e não confiável	Remova-o
exists:	Normalmente não pode ser achatado (depende de macros em tempo de execução)	Mantenha como está ou isole em um subdomínio
ip4/ip6	Já são estáticos	Mantenha inalterado

Percorra o grafo em profundidade (depth-first) e rastreie quais domínios você já visitou, para poder detectar includes circulares — se um include aponta de volta para um domínio já na sua pilha de resolução, pare e mantenha-o como um include em vez de entrar em loop para sempre.

Passo 4: Deduplique e agregue CIDRs

A expansão recursiva produz sobreposições. Dois fornecedores podem compartilhar um IP, ou você pode coletar vários blocos /25 adjacentes que se combinam de forma limpa em um /24. Deduplique cada endereço e, em seguida, agregue faixas adjacentes em supernets somente quando a união permanecer inteiramente dentro do espaço autorizado de um provedor. Superagregar entre provedores não relacionados autoriza IPs que você não controla — uma regressão de segurança, não uma otimização.

Passo 5: Fique de olho no tamanho do registro

As strings TXT do DNS são limitadas a 255 caracteres por segmento entre aspas; registros mais longos precisam ser divididos em várias strings concatenadas dentro do mesmo registro. Como regra prática, mantenha a resposta total abaixo de aproximadamente 450-900 bytes para evitar fragmentação de UDP e problemas com middleboxes. Se a lista achatada for grande demais, divida os IPs em rótulos auxiliares (por exemplo, spf-a.example.com, spf-b.example.com) que contenham apenas entradas ip4/ip6 e inclua-os a partir do registro principal — cada auxiliar custa uma consulta, então mantenha o total ≤ 10.

Passo 6: Reanexe o qualificador all e valide

Adicione seu mecanismo terminador original — -all para aplicação rígida é recomendado para remetentes de produção. Depois, rode o registro novamente por um validador de SPF para confirmar que a sintaxe está limpa, que ainda há apenas um registro e que a contagem de consultas está onde você espera. Se estiver migrando com cautela, você pode publicar com ~all brevemente e depois mudar para -all assim que o monitoramento mostrar taxas de aprovação estáveis.

Passo 7: Publique com um TTL baixo e depois aumente-o

Antes de publicar, reduza o TTL do registro para 60-300 segundos, para que qualquer erro possa ser corrigido rapidamente. Publique o novo registro achatado, verifique se ele resolve corretamente a partir de vários resolvers públicos (Google, Cloudflare, Quad9) e acompanhe seus relatórios agregados de DMARC em busca de qualquer queda nas taxas de aprovação do SPF. Assim que as coisas estiverem estáveis, aumente o TTL de volta para 1-4 horas.

O detalhe: registros achatados ficam desatualizados

Aqui está o problema que engana a maioria das pessoas que achatam à mão. No momento em que você achata, seu registro é um instantâneo. Quando Google, Mailchimp, Amazon SES ou qualquer outro provedor rotaciona seus IPs de envio — e grandes ESPs fazem isso constantemente — sua lista fixa não corresponde mais à realidade. O e-mail dos novos IPs falha silenciosamente no SPF, e você volta às faturas perdidas e às redefinições de senha que falham, exceto que agora a causa é invisível porque o registro parece correto.

Remetentes apoiados em CDN e de marketing são os piores infratores: dados internos do AutoSPF em mais de 1.200 domínios mostram remetentes apoiados em CDN rotacionando 8-15% de seu conjunto de IPs mensalmente, contra menos de 0,5% para servidores de e-mail internos. Achatar um provedor de alta rotatividade às cegas é pedir por problemas.

Os pontos práticos a levar:

• Achate fontes estáveis (relays on-prem, IPs estáticos de nuvem) de forma agressiva.
• Deixe ESPs voláteis como includes, ou isole-os atrás de um subdomínio delegado como mail-out.example.com, que a raiz inclui com uma única consulta.
• Nunca trate o flattening como algo feito de uma vez por todas — ele precisa de re-resolução contínua.

Automatize o re-flattening com o AutoSPF

Fazer os passos 1-7 à mão toda vez que um fornecedor muda os IPs não é realista. É exatamente para isso que o serviço de SPF flattening automatizado do AutoSPF foi criado. Ele executa o algoritmo determinístico de flattening acima de forma contínua: ele reexamina seus includes a cada 15 minutos e, quando os IPs de um provedor upstream mudam, ele atualiza automaticamente seu registro publicado por meio da API do seu provedor de DNS — com trocas atômicas, TTLs escalonados e rollback em um clique se uma verificação canary falhar.

Criticamente, o AutoSPF resolve exatamente para os mesmos IPs para os quais seus includes resolvem — ele nunca amplia a autorização com mesclagens de CIDR excessivamente abrangentes, então você não autoriza acidentalmente remetentes que não pretendia. Você mantém um registro pequeno e estável na raiz; o AutoSPF o mantém correto em segundo plano.

Para decidir quais das suas fontes achatar em vez de delegar, veja nosso guia sobre as melhores ferramentas de SPF flattening. Se você preferir evitar fixar IPs por completo, compare as abordagens em SPF flattening vs macros. E antes de achatar, vale a pena confirmar que a mudança não perturbará seus outros registros de autenticação — veja o SPF flattening afeta DKIM e DMARC.

Perguntas Frequentes

Achatar um registro SPF quebra o DKIM ou o DMARC?

Não, quando feito corretamente. O flattening só muda quais IPs o SPF autoriza — ele não toca nas assinaturas DKIM nem no alinhamento do DMARC. O risco é indireto: se um registro achatado desatualizado começar a falhar no SPF para e-mails legítimos, isso pode arrastar para baixo as taxas de aprovação do DMARC. Mantenha o registro re-resolvido e ambos permanecem saudáveis.

Quantas consultas DNS um registro SPF achatado usa?

Um registro totalmente achatado usa zero consultas DNS no momento da avaliação, porque cada IP autorizado está listado explicitamente como ip4:/ip6:. Se você mantiver alguns includes voláteis ou dividir os IPs em rótulos auxiliares, cada um deles adiciona uma consulta — apenas mantenha o total igual ou abaixo do limite de 10 da RFC 7208.

Posso achatar os mecanismos ptr e exists?

Geralmente não. O ptr está obsoleto, é lento e deve simplesmente ser removido. O exists: normalmente depende de macros em tempo de execução (avaliando MAIL FROM ou HELO no momento da verificação), então ele não pode ser reduzido a uma lista estática de IPs. Mantenha exists como está ou isole-o em um subdomínio delegado para limitar seu impacto de consultas.

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

Com a mesma frequência com que seus remetentes mudam seus IPs. Servidores de e-mail internos podem ser estáveis por semanas, mas grandes ESPs e CDNs podem mudar de endereço diariamente. É por isso que o flattening manual é frágil e o AutoSPF reexamina a cada 15 minutos, publicando um registro atualizado automaticamente sempre que um conjunto de IPs upstream muda.

O que acontece se meu registro achatado ficar grande demais?

Registros TXT do DNS são limitados a 255 caracteres por string, e registros grandes demais correm risco de fragmentação de UDP. Se a lista achatada de IPs for muito grande, divida-a em rótulos auxiliares (cada um contendo apenas entradas ip4/ip6) e inclua-os a partir do registro principal, ou delegue provedores voláteis a um subdomínio. Procure manter a resposta total abaixo de ~900 bytes e as consultas ≤ 10.

Devo achatar meu registro SPF manualmente ou usar uma ferramenta?

O flattening manual funciona para uma correção única, mas não consegue acompanhar os provedores rotacionando IPs — um registro achatado à mão desautoriza silenciosamente remetentes assim que uma faixa upstream muda. Uma ferramenta gerenciada como o AutoSPF cuida da resolução recursiva, da deduplicação, do gerenciamento de tamanho e do re-flattening contínuo por você, e é por isso que ela é a abordagem recomendada para qualquer coisa além de um único remetente estático.