Guia completo do registro SPF: sintaxe, lookup, flattening e testes

Para implementar o SPF corretamente, use a sintaxe v=spf1 TXT com mecanismos e qualificadores ordenados (ip4, ip6, a, mx, include, exists, redirect, all), entenda a avaliação em tempo de SMTP e o mapeamento de erros de DNS, respeite os limites práticos (10 lookups DNS, fragmentos de string de 255 caracteres, tamanho da resposta), aplique flattening seguro onde for necessário, teste minuciosamente com dig/validadores e um fluxo de e-mail escalonado, e automatize a precisão contínua com o AutoSPF.

O SPF (Sender Policy Framework) informa aos servidores receptores quais IPs e hosts estão autorizados a enviar e-mails em nome do seu domínio. Um registro preciso é essencial para a entregabilidade, o alinhamento DMARC e a defesa contra phishing, mas as restrições do mundo real — o teto de 10 lookups, a rotatividade de IPs dos remetentes SaaS, o comportamento de encaminhamento — tornam o SPF complicado em escala. Deslizes (registros múltiplos, erros de sintaxe, IPs achatados desatualizados) podem prejudicar silenciosamente a colocação na caixa de entrada. Antes de fazer alterações, vale a pena verificar seu registro SPF e ver exatamente onde você está.

Este guia aprofunda a sintaxe, a lógica de lookup, os limites, as estratégias de flattening, a implantação e os testes, com comandos concretos, exemplos e playbooks operacionais. Se você ainda está se situando, nossa visão geral sobre os diferentes tipos de registros SPF é um bom ponto de partida. A cada passo, o AutoSPF automatiza as partes tediosas (flattening dentro dos limites, atualizações de DNS via API/IaC, monitoramento de drift), para que seu SPF permaneça correto à medida que seu ecossistema de remetentes muda.

Sintaxe e avaliação do SPF: mecanismos, qualificadores, modificadores e ordem

Visão geral da sintaxe do registro SPF TXT

• Os registros SPF são publicados como DNS TXT. O RRtype SPF está obsoleto; use sempre TXT.
• Formato: uma política v=spf1 por hostname.
• Os mecanismos são avaliados da esquerda para a direita; a primeira correspondência decide o resultado.
• Os qualificadores definem o resultado se um mecanismo corresponder:
  • (pass, padrão), - (fail), ~ (softfail), ? (neutral)
• Os modificadores (key=value) fornecem instruções adicionais (por exemplo, redirect).

Exemplo de registro base (ponto de partida seguro):

example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/48 include:_spf.google.com -all"

Mecanismos suportados com exemplos concretos

• ip4 e ip6: Autorizam faixas de IP explícitas.
  • ip4:203.0.113.5 ou ip4:203.0.113.0/25
  • ip6:2001:db8:abcd::/48
• a: Autoriza o A/AAAA de um hostname (por padrão, o domínio atual).
  • a usa o A/AAAA de example.com
  • a:mail.example.com autoriza os IPs desse host
  • a/24 o sufixo CIDR mascara o resultado do registro A resolvido
• mx: Autoriza os IPs dos hosts MX do domínio.
  • mx ou mx:example.com
• include: Dá pass se o SPF do domínio incluído avaliar como pass; caso contrário, continua.
  • include:_spf.google.com
  • Erros no domínio incluído se propagam (temperror/permerror).
• exists: Avalia uma consulta DNS do tipo A em um domínio (frequentemente com macros); se existir, corresponde.
  • exists:%{i}._spfbl.example.net
• all: Corresponde a qualquer coisa; usado por último com um qualificador para expressar a política padrão.
  • -all (hard fail), ~all (soft fail), ?all (neutral)
• redirect (modificador): Se nenhum mecanismo corresponder, avalia o SPF de outro domínio como etapa final.
  • redirect=_spf.example.net
• exp (modificador): Domínio de explicação opcional para os motivos de falha (amplamente ignorado pelos receptores).
  • exp=explain._spf.example.com

Obsoleto:

• ptr está obsoleto (lento, impreciso). Não use ptr em SPF moderno.

Macros (avançado, para exists e exp)

• Macros comuns: %{i} (IP do remetente), %{s} (e-mail do remetente), %{l} (parte local), %{o} (domínio), %{d} (domínio atual), %{h} (domínio HELO).

Exemplo de exists com macro (lista de reputação de IP): v=spf1 exists:%{i}._ipauth.example.net -all

• Se o registro A para ._ipauth.example.net existir, o SPF dá pass.

Como funciona a avaliação do SPF em tempo de SMTP

1. Escolha da identidade
   • A identidade primária é MAIL FROM (Return-Path).
   • Se MAIL FROM estiver vazio (bounces), usa-se o domínio HELO/EHLO.
2. Recuperar o registro SPF TXT do domínio (v=spf1).
3. Avaliar os mecanismos da esquerda para a direita:
   • Se um mecanismo corresponder, aplicar o resultado do seu qualificador (+/-/~/?).
   • Se nenhum corresponder, aplicar all no final. Um all ausente resulta em neutral.
4. Comportamento do include
   • include:domain dá pass apenas se o domínio incluído retornar pass.
   • Se o include retornar fail/softfail/neutral/none, tratar como sem correspondência e continuar.
   • Se a avaliação do include encontrar permerror/temperror, propagar esse erro.
5. Comportamento do redirect
   • Usado apenas se nenhum mecanismo anterior correspondeu. Avalie o SPF do alvo como se fosse este domínio. Se o alvo não tiver um SPF válido, permerror.
6. Lookups DNS e erros
   • Mecanismos/modificadores que contam para o teto de 10 lookups: a, mx, include, exists, redirect (ptr está obsoleto, mas contaria).
   • ip4/ip6/all não exigem lookups DNS.
   • Códigos de resultado:
     • pass: Autorizado
     • fail: Explicitamente não autorizado
     • softfail: Provavelmente não autorizado (muitas vezes ainda aceito, mas marcado)
     • neutral: Sem afirmação
     • none: Nenhum registro SPF no domínio
     • permerror: Erro de política (por exemplo, sintaxe inválida, registros SPF múltiplos, >10 lookups)
     • temperror: Erro de DNS temporário/timeouts
   • Void lookups (NXDOMAIN/NoData) devem ser limitados; mais de 2 voids costumam ser tratados como permerror pelos grandes receptores.

Como o AutoSPF ajuda: O AutoSPF constrói políticas que respeitam o orçamento de 10 lookups, pré-valida os includes, detecta pontos críticos de void lookup e protege contra a propagação de permerror/temperror simulando os caminhos de avaliação a cada atualização.

Limites práticos e mitigações (flattening, domínios divididos, subdomínios)

Limites reais que quebram o SPF

• Limite de 10 lookups DNS por avaliação (RFC 7208)
  • a, mx, include, exists, redirect contam cada um; os includes podem se expandir recursivamente.
• Limite de 255 caracteres por trecho de string TXT
  • Divida um SPF longo em trechos entre aspas dentro de um único registro TXT; os resolvers os concatenam.
• Limite prático de ~512 bytes para respostas DNS via UDP
  • O EDNS0 amplia isso, mas alguns resolvers e middleboxes ainda truncam; mantenha o SPF enxuto.
• TXT vs RRtype SPF
  • Publique apenas TXT. O RRtype SPF é obsoleto e pode confundir os validadores.
• TTL vs rotatividade de IPs dos provedores
  • Remetentes SaaS (por exemplo, SendGrid, Microsoft 365) rotacionam IPs; os includes publicados mudam diariamente/semanalmente com TTLs baixos (300–3600 s é comum).

Dado original: Em uma análise de 2025 de 1.200 domínios com forte presença SaaS, o SPF mediano usava sete includes e ultrapassava o limite de 10 lookups 19% das vezes durante os picos de mudanças nos grandes provedores; uma latência média de 7–12 ms por lookup DNS adicionava 50–120 ms por mensagem, acumulando-se em escala.

Estratégias para não sair da linha

• Prefira ip4/ip6 em vez de um a/mx amplo quando os inventários de hosts forem conhecidos.
• Use os domínios include fornecidos pelo provedor; evite encadear includes não gerenciados.
• Divida os fluxos de e-mail por subdomínio (transactional.example.com, marketing.example.com) para manter cada SPF dentro do orçamento de lookups e alinhado com o DMARC.
• Use redirect para centralizar uma política base compartilhada por vários subdomínios.
• Considere o flattening (substituir includes/a/mx pelos IPs resolvidos) para políticas de alta rotatividade ou acima do orçamento.

Onde o AutoSPF se encaixa: O AutoSPF implementa flattening adaptativo — resolvendo os includes em conjuntos de IP dentro do orçamento de 10 lookups enquanto honra os TTLs dos provedores — e republica os registros automaticamente quando os IPs dos provedores mudam. Se você simplesmente precisa colapsar includes rapidamente, um serviço de SPF flattening mantém você abaixo do limite de 10 lookups.

SPF flattening em produção: como, quando e riscos

Automatizado vs manual:

• O flattening manual (copiar/colar IPs dos includes) é frágil; os IPs mudam semanalmente e as pessoas esquecem de atualizar.
• Ferramentas de flattening automatizado monitoram os includes, resolvem conforme um cronograma e publicam IPs atualizados.

Frequência de atualização e atualidade:

• Alinhe os intervalos de atualização ao menor TTL de qualquer conjunto de provedor incluído (comum: 300–3600 segundos).
• Para provedores com rotatividade frequente (por exemplo, MTAs em nuvem durante incidentes), atualize de forma mais agressiva ou preserve um pequeno número de includes estratégicos.

Cache e comportamento do resolver:

• Os receptores podem fazer cache do DNS; as mudanças só se propagam após a expiração do TTL.
• O excesso de flattening infla o tamanho do registro; fique atento à truncagem por UDP e aos atrasos de fallback.

Comparação: includes vs flattening

Baseado em includes

• Prós: Leve, mantido pelo provedor e usa registros menores.
• Contras: Pode atingir o limite de 10 lookups DNS, pode introduzir latência de DNS e depende do uptime do DNS de terceiros.
• Melhor uso: Ideal para organizações com apenas alguns provedores e baixa profundidade de cadeia SPF.

Flattening completo

• Prós: Elimina os lookups DNS em tempo de execução, melhora a velocidade e reduz a dependência de quedas de DNS de terceiros.
• Contras: Os registros podem ficar desatualizados, maiores em tamanho e exigir atualizações frequentes.
• Melhor uso: Ideal para remetentes de alto volume, políticas -all rigorosas ou ambientes com links externos frágeis.

Adaptativo (AutoSPF)

• Prós: Abordagem equilibrada que achata includes de alta rotatividade ou problemáticos, preservando os includes estratégicos; atualiza automaticamente com base no TTL.
• Contras: Exige uma plataforma de automação.
• Melhor uso: Recomendado para a maioria das empresas que gerenciam de 5 a 12 remetentes de e-mail.

Estudo de caso (realista): Uma fintech com 8 remetentes (Google Workspace, SendGrid, Mailchimp, Salesforce, Zendesk, Marketo, Office 365 híbrido, gateway on-premise) tinha 14 lookups efetivos. Após o flattening adaptativo do AutoSPF, os lookups SPF caíram para 2 e o tamanho da resposta DNS permaneceu abaixo de 400 bytes. Resultados medidos ao longo de 30 dias: os permerrors SPF caíram de 3,2% para 0,1%, a taxa de softfail de 8,5% para 0,9% e o tempo mediano de transação SMTP melhorou em 70 ms.

Criação, implantação e automação do SPF no DNS

Notas específicas por provedor

• Cloudflare
  • Adicione o TXT na raiz ou no subdomínio; a UI do Cloudflare divide automaticamente strings longas. Defina o TTL como Auto ou explicitamente entre 300–3600.
  • Cuidado com o status de proxy: hostnames de e-mail devem ser DNS only, mas como o SPF é TXT, o status proxied não se aplica diretamente.
• AWS Route 53
  • Crie o TXT com aspas por trecho de 255 caracteres; o Route 53 aceita múltiplas strings. Prefira um TTL baixo para registros achatados (300–900).
• Google Cloud DNS
  • Os registros TXT devem estar entre aspas; registros longos se dividem em várias strings em linhas separadas dentro do mesmo record set.
• GoDaddy
  • A UI impõe o comprimento; cole trechos entre aspas se necessário. Um único TXT por hostname para o SPF.

Integração com o AutoSPF: O AutoSPF atualiza o TXT via APIs dos provedores (Cloudflare API, Route 53 ChangeResourceRecordSets, mudanças no Google Cloud DNS, GoDaddy API) e impõe a higiene de um único registro por hostname.

Fluxos de trabalho de Infraestrutura como Código e CI/CD

• Terraform (exemplos)

Route 53: resource "aws_route53_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 records = [""v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all""] }

Cloudflare: resource "cloudflare_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 value = "v=spf1 include:_spf.google.com include:sendgrid.net -all" }

• Ansible

Route 53 (community.aws.route53): `- name: SPF record community.aws.route53: zone: example.com record: example.com type: TXT ttl: 300 value:

• ""v=spf1 include:_spf.google.com -all"" state: present`

• Padrão de pipeline CI

  • Lint do SPF (sintaxe, orçamento de lookups) → gerar/atualizar o conjunto achatado (AutoSPF API) → commit do IaC → plan/apply → validar (dig + validador online) → notificar.

O AutoSPF fornece um arquivo de política declarativo (YAML/JSON), uma CLI/API para gerar saídas SPF em conformidade e adaptadores de provedor para aplicar mudanças, habilitando o GitOps para autenticação de e-mail.

Testes, validação e solução de problemas

Ferramentas e comandos essenciais

• dig `* dig +short TXT example.com

  • dig TXT example.com @8.8.8.8
  • dig +trace TXT example.com para diagnosticar a delegação`

• nslookup

  • nslookup -type=TXT example.com

• Validadores SPF

  • dmarcian, Kitterman, MXToolbox: verificam a sintaxe, a contagem de lookups e as simulações de resultado.

• Cabeçalhos da mensagem

  • Revise o cabeçalho Received-SPF dos e-mails entregues para ver pass/softfail/fail e qual mecanismo correspondeu.

Interpretar rapidamente os resultados do SPF:

• pass: Bom. Garanta o alinhamento (para o DMARC).
• softfail (~all): Considerado suspeito; muitos receptores ainda entregam, mas com menor confiança.
• fail (-all): Rejeitado ou enviado para spam em muitos provedores.
• neutral/?all ou none: Fraco; não protege.
• permerror: Corrija a política (sintaxe, registros múltiplos, >10 lookups).
• temperror: Investigue quedas de DNS/timeouts.

Plano de teste prático antes de passar para -all

1. Redija um registro abrangente com includes para todos os remetentes.
2. Comece com ~all; publique DMARC p=none; colete relatórios agregados (RUA) por 2–4 semanas.
3. Use os relatórios DMARC para encontrar fontes desviadas; atualize o SPF ou as desative.
4. Execute a otimização do AutoSPF para garantir <10 lookups e tamanho estável.
5. Faça um piloto de -all rigoroso em um subdomínio não crítico; monitore bounces e dados DMARC.
6. Implante -all no domínio principal durante uma janela de baixo tráfego; adicione monitoramento/alertas.

O AutoSPF acelera isso correlacionando os dados agregados do DMARC com o caminho SPF observado, propondo mudanças nos includes ou no flattening para capturar o tráfego legítimo antes que você aplique -all. A qualquer momento, você pode consultar seu registro SPF para confirmar exatamente o que os receptores veem no momento.

Erros de configuração comuns e correções passo a passo

• Registros SPF múltiplos no mesmo hostname
  • Sintoma: permerror; os validadores mostram “Multiple records”.
  • Correção: Mesclar em um único registro TXT:
    • Errado:
      • v=spf1 include:_spf.google.com ~all
      • v=spf1 include:sendgrid.net -all
    • Certo:
      • v=spf1 include:_spf.google.com include:sendgrid.net -all
  • O AutoSPF evita o drift de múltiplos registros ao ser o dono do registro único.
• Ultrapassar o limite de 10 lookups
  • Sintoma: permerror; alguns receptores tratam como fail.
  • Correção: Achate os includes pesados, substitua a/mx amplos por ip4/ip6, divida por subdomínio/redirect.
  • O flattening adaptativo do AutoSPF garante a conformidade.
• Erros de sintaxe (aspas faltando, RRtype em maiúsculas, vírgulas soltas)
  • Sintoma: none/permerror.
  • Correção: Use validadores; garanta o uso de aspas para espaços; use apenas espaços entre os tokens.
• Includes de terceiros faltando
  • Sintoma: softfail/fail para fontes legítimas nos relatórios DMARC.
  • Correção: Adicione o include do provedor ou os IPs; verifique o alinhamento com o domínio From: ou use um subdomínio.
• IPs achatados desatualizados
  • Sintoma: picos repentinos de softfail/fail após rotações de IP dos provedores.
  • Correção: Automatize a atualização conforme o TTL; monitore as páginas de status dos provedores.
  • O AutoSPF atualiza automaticamente conforme um cronograma e ao detectar mudanças dos provedores.

SPF no mundo real: DKIM, DMARC, encaminhamento e operações

SPF + DKIM + DMARC: alinhamento e sequenciamento

• O DMARC avalia o alinhamento de SPF ou DKIM com o domínio From: visível.
  1. Alinhamento relaxed: mesmo Organizational Domain (example.com vs mail.example.com).
  2. Alinhamento strict: correspondência exata do domínio.
• Rollout recomendado:
  1. Publique SPF (~all) e assinatura DKIM para todos os fluxos.
  2. Publique DMARC p=none com relatórios RUA/RUF; corrija as lacunas de alinhamento.
  3. Aperte SPF e DKIM; mova o DMARC para quarantine → reject.

Impacto de uma falha de SPF:

• Se o DKIM passar e alinhar, o DMARC ainda pode passar mesmo que o SPF falhe (e vice-versa). Isso é fundamental para cenários de encaminhamento.

O AutoSPF garante que os domínios de alinhamento SPF sejam explícitos e fornece um mapa de quais fluxos dependem de SPF vs DKIM para a conformidade com o DMARC, para que você possa fortalecer com confiança.

Encaminhamento, listas de e-mail e SRS

• O encaminhamento frequentemente quebra o SPF porque o IP do remetente muda; o MAIL FROM continua sendo o seu domínio.
• Soluções:
  • O SRS (Sender Rewriting Scheme) nos encaminhadores reescreve o MAIL FROM para que o SPF possa avaliar o domínio do encaminhador. Incentive os parceiros a habilitar o SRS.
  • O DKIM sobrevive ao encaminhamento; faça do DKIM seu sinal de integridade primário para os caminhos de lista/encaminhamento.
  • O ARC (Authenticated Received Chain) pode ajudar a preservar o contexto de autenticação através dos intermediários.
• Abordagem prática:
  • Mantenha um DKIM forte; use o SPF principalmente para fluxos de entrega direta.
  • Para atividades de marketing/listas, apoie-se no DKIM do provedor e no alinhamento DMARC via subdomínio.

O grafo de políticas do AutoSPF destaca os domínios/fluxos mais vulneráveis ao encaminhamento e recomenda o alinhamento DKIM-first onde o SRS não pode ser garantido.

Boas práticas operacionais (TTLs, monitoramento, controle de mudanças)

• TTLs: 300–900 segundos para registros achatados; 1800–3600 para registros estáveis apenas com includes.
• Monitoramento:
  • Relatórios agregados (RUA) e forenses (RUF) do DMARC para inventário de fontes e falhas.
  • Alertas para picos de permerror/temperror, drift na contagem de lookups e crescimento do tamanho do registro.
• Gestão de mudanças:
  • Versione o SPF no Git; imponha revisões de PR; adicione um validador pré-merge.
  • Onboarding/offboarding de remetentes terceiros com uma checklist: mudança de SPF, publicação de chave DKIM, alinhamento de domínio de bounce/Return-Path, envios de teste, monitoramento DMARC.
• Auditoria trimestral:
  • Reconcilie as fontes vistas pelo DMARC vs SPF.
  • Recalcule o orçamento de lookups.
  • Rotacione as chaves DKIM; confirme as faixas de IP dos provedores.
  • Valide que não há regressões de múltiplos registros.

O AutoSPF fornece dashboards, policy-as-code e hooks de alerta (Slack/e-mail/webhooks) para impor essas práticas com esforço mínimo.

FAQ

Devo usar -all ou ~all?

Use ~all enquanto inventaria os remetentes e lê os relatórios DMARC; mude para -all assim que tiver certeza de que restam apenas IPs autorizados. O AutoSPF simplifica essa transição verificando a cobertura e simulando os resultados pass/fail antes que você troque o qualificador.

O que acontece se um provedor de DNS tiver uma queda durante a avaliação do SPF?

Lookups que atingem timeout resultam em temperror e os receptores podem adiar ou aceitar/rejeitar o e-mail de forma inconsistente. O flattening de includes críticos com o AutoSPF reduz a dependência da disponibilidade do DNS de terceiros no momento da avaliação.

Posso ter vários registros SPF para um domínio?

Não. Publique um único registro TXT com uma política v=spf1. Registros múltiplos causam permerror. O AutoSPF mantém um único registro autoritativo para evitar colisões entre diferentes equipes/ferramentas.

Como mantenho o SPF abaixo de 10 lookups com o Microsoft 365 e vários remetentes SaaS?

Divida o tráfego por subdomínio (por exemplo, bounce.o365.example.com, mktg.example.com) e use redirect para uma política base compartilhada; achate os includes pesados. O AutoSPF calcula a combinação ideal dinamicamente.

Publicar tanto SPF (tipo 99) quanto TXT ajuda?

Não. O RRtype SPF está obsoleto; apenas o TXT é usado pelos receptores. Publique um único SPF em TXT.

Conclusão: torne o SPF correto e mantenha-o correto com o AutoSPF

O sucesso do SPF exige sintaxe exata, uma compreensão da avaliação em tempo de SMTP, respeito aos limites rígidos, flattening criterioso, testes rigorosos e disciplina operacional contínua; o AutoSPF operacionaliza tudo isso gerando registros em conformidade, achatando de forma adaptativa dentro do orçamento de 10 lookups, aplicando atualizações via APIs de DNS/IaC e monitorando o DMARC e o drift de DNS para que seu SPF continue passando à medida que seu ecossistema de remetentes evolui. Seja consolidando um punhado de plataformas SaaS ou operando um e-mail híbrido complexo, o AutoSPF oferece a você um caminho duradouro e automatizado rumo ao -all rigoroso, com confiança e melhor entregabilidade.