Verificador de Registro SPF Grátis

O que é SPF e por que isso importa em 2026

Sender Policy Framework (SPF) é um dos três pilares da autenticação moderna de e-mail, junto com DKIM e DMARC. Definido na RFC 7208, ele permite a um dono de domínio publicar uma lista de servidores remetentes autorizados no DNS para que provedores receptores possam verificar que mensagens recebidas realmente vêm de onde dizem vir. Sem SPF, qualquer um pode enviar e-mail fingindo ser seu domínio — e provedores modernos como Gmail e Yahoo silenciosamente derrubam e-mails não autenticados direto no spam.

Em 2026, SPF não é mais opcional. Os requisitos de bulk sender do Gmail e do Yahoo (lançados em 2024 e apertados desde então) exigem SPF e DKIM para qualquer domínio enviando mais de 5.000 mensagens por dia. Microsoft 365 e Apple Mail aplicam padrões similares. Um registro SPF mal configurado ou ausente agora se traduz diretamente em colocação na pasta de spam, perda de receita e dano à marca. A boa notícia: SPF é uma das vitórias de entregabilidade mais baratas e rápidas disponíveis — um único registro TXT bem configurado pode subir a colocação na inbox em 20–40% da noite para o dia.

Anatomia de um registro SPF

Todo registro SPF é um único registro DNS TXT contendo mecanismos separados por espaço. Veja um exemplo típico de um domínio usando Google Workspace e Mailgun:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all

• v=spf1 — a tag de versão. Todo registro SPF precisa começar com isso. Não existe v=spf2; o protocolo não muda há mais de uma década.
• ip4: / ip6: — ip4: e ip6: — endereços IP ou faixas CIDR explicitamente permitidas. ip4:203.0.113.0/24 autoriza uma sub-rede inteira. Esses são os mecanismos mais baratos porque não disparam lookup DNS algum.
• include: — puxa o registro SPF de outro domínio. include:_spf.google.com diz aos receptores para também aceitar e-mail de qualquer servidor que o Google autoriza para seus tenants. Cada include conta como um lookup DNS, e includes aninhados também contam.
• a / mx — a e mx — autorizam os endereços IP do registro A do domínio (servidor do site) ou registros MX (servidores de e-mail de entrada). Use com moderação: muitos domínios têm servidores web que não devem enviar e-mail.
• Qualificadores controlam o resultado. ~all (soft fail) marca e-mails não correspondentes como suspeitos mas aceita — útil durante testes. -all (hard fail) rejeita e-mails não correspondentes diretamente — a configuração recomendada para produção. ?all (neutral) não faz nada e é inútil. +all autoriza explicitamente todo IP da internet — nunca use; é o equivalente a deixar a porta da frente aberta com uma placa dizendo "por favor, se passe por mim."

5 erros SPF comuns e como corrigi-los

Lookups DNS demais (limite RFC 7208: 10)

SPF permite no máximo 10 lookups DNS por avaliação. Cada include:, a:, mx:, exists: e redirect= conta. Includes aninhados também contam — se include:_spf.google.com tem quatro includes dentro, são cinco lookups só nesse mecanismo. Passar do limite dispara PermError e a maioria dos receptores trata como falha dura. Resolva: audite todo include com nosso SPF checker acima, remova fornecedores não usados, troque include: por blocos ip4: onde o fornecedor publica faixas estáticas, ou use um serviço de flattening.

PermError: sintaxe de registro SPF inválida

Erros comuns de sintaxe incluem faltar o prefixo v=spf1, usar ponto e vírgula em vez de espaço, deixar caracteres aleatórios de copy-paste, ou colocar o qualificador (~all) no meio do registro em vez do final. Receptores veem isso como falha de configuração e reprovam o SPF direto. Resolva: cole o registro exato em um validador, procure caracteres Unicode escondidos e garanta que mecanismos sejam separados por espaço com o qualificador all por último.

Múltiplos registros SPF (precisam ser fundidos)

A RFC 7208 proíbe explicitamente mais de um registro TXT v=spf1 no mesmo domínio. Geralmente acontece quando um time adiciona Google Workspace e outro adiciona SendGrid sem coordenar. Receptores que veem dois registros lançam PermError. Resolva: combine em um único registro. v=spf1 include:_spf.google.com include:sendgrid.net ~all substitui os dois individuais.

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Encaminhamento quebra o SPF

Quando um destinatário encaminha sua mensagem para outro endereço, o IP de conexão muda mas o Return-Path continua sendo o seu — e o SPF falha no salto de encaminhamento. Isso é por design mas causa falsos negativos. Resolva: confie em DKIM para alinhamento (DKIM sobrevive ao encaminhamento), implemente SRS em encaminhadores que você controla e aceite que SPF sozinho não basta — exatamente por isso o DMARC exige SPF ou DKIM, não os dois.

Confusão de herança em subdomínios

SPF não é herdado. mail.example.com e example.com são hosts separados e precisam de registros SPF separados. Bug comum: empresa publica SPF no apex mas uma ferramenta de marketing envia de updates.example.com — receptores não veem registro SPF no subdomínio e seu e-mail falha no alinhamento. Resolva: publique v=spf1 -all em todo subdomínio que nunca deve enviar e-mail e uma política real em todo subdomínio que envia.

Configuração SPF passo a passo

1. Inventarie todos os serviços de envio

Liste todo sistema que envia e-mail usando seu domínio: plataformas de marketing (Mailchimp, HubSpot), provedores transacionais (SendGrid, Postmark, Resend), CRMs, mesas de suporte (Zendesk, Intercom), folha de pagamento, processadores de pagamento e seus próprios servidores. Esquecer um significa que e-mail legítimo será rejeitado depois que você publicar o registro.

2. Escolha uma política de falha (~all vs -all)

Comece com ~all (soft fail) nas primeiras 1–2 semanas enquanto monitora relatórios DMARC para fontes inesperadas. Quando confirmar que todo remetente legítimo está no registro e os relatórios DMARC mostrarem 100% de aprovação, mude para -all para proteção máxima.

3. Construa o registro

Use mecanismos include: publicados pelo fornecedor sempre que possível (ex.: include:_spf.google.com). Para serviços sem include, use ip4: com as faixas IP publicadas. Mantenha o registro abaixo do limite de 10 lookups contando todo include e seus lookups aninhados. Termine com um único qualificador — ~all ou -all — nunca os dois.

4. Adicione o registro TXT no DNS

No painel do seu provedor de DNS, crie um novo registro TXT com host = @ (ou o apex do seu domínio) e value = a string SPF completa entre aspas. TTL de 3600 (1 hora) é um bom padrão. Se seu provedor de DNS adiciona aspas automaticamente, não coloque aspas duplas.

5. Valide e monitore

Use o checker acima para verificar que o registro tem parse limpo, contagem de lookup abaixo de 10 e política bem definida. Depois envie e-mails de teste para mail-tester.com e para suas próprias contas Gmail/Outlook. Configure DMARC com relatórios rua= para pegar fontes que você esqueceu. Monitore continuamente — IPs de fornecedor mudam, includes são adicionados, e um registro SPF que estava limpo seis meses atrás pode quebrar silenciosamente.

Como ficar abaixo do limite de 10 lookups DNS

O limite de 10 lookups é a causa mais comum de falhas de SPF em escala. Cada include: dispara uma consulta DNS, e qualquer include que contenha includes dispara mais — o SPF do Salesforce, por exemplo, pode resolver para 8+ lookups sozinho. Três estratégias mantêm você abaixo do limite. Primeiro, audite sem dó: qualquer fornecedor que você não usa mais precisa sair do registro. Rode nosso checker mensalmente e remova includes mortos.

Segundo, troque include: por ip4: onde fornecedores publicam faixas IP estáveis. SendGrid, Mailgun e Amazon SES publicam blocos estáticos; usar ip4:198.61.254.0/24 em vez de include:sendgrid.net custa zero lookups em vez de dois. O trade-off é manutenção — quando o fornecedor adicionar novos IPs você precisa atualizar manualmente.

Terceiro, use serviços de flattening de SPF (ex.: easydmarc.com, dmarcian) para includes aninhados inevitáveis. Esses serviços resolvem todos os seus includes em uma lista plana de blocos ip4: e republicam como um único registro SPF hospedado que você referencia com um include. A desvantagem é dependência operacional de um terceiro — escolha com cuidado e monitore por outages.

SPF, DKIM e DMARC: como funcionam juntos

SPF sozinho não basta. Os três protocolos formam uma defesa em camadas: SPF autentica o IP do servidor remetente, DKIM assina criptograficamente o conteúdo da mensagem, e DMARC une os dois ao endereço From visível e diz aos receptores o que fazer quando a autenticação falha. SPF quebra com encaminhamento; DKIM sobrevive ao encaminhamento mas é mais difícil de implantar porque exige gerar um par de chaves e adicionar a chave pública no DNS. Juntos, o alinhamento DMARC passa se SPF OU DKIM passar — então implantar os dois te dá redundância e cobertura completa em cenários reais de entrega onde encaminhamento, listas de discussão e cadeias de confiança ARC são comuns. Sem DMARC, SPF e DKIM são apenas ferramentas de diagnóstico; receptores podem usar os resultados de forma frouxa ou ignorá-los. Com DMARC em p=reject, você se compromete publicamente com sua política de autenticação e instrui todo receptor do planeta a derrubar e-mails falsificados na hora. Esse é o padrão moderno de segurança de e-mail, e ele começa com um registro SPF limpo. A ordem recomendada de implantação é: SPF primeiro (um registro TXT, impacto imediato), depois DKIM (geração de chave + DNS), depois DMARC em p=none com relatórios rua= por duas semanas de monitoramento, depois apertando progressivamente para p=quarantine e finalmente p=reject. Pular o monitoramento é a causa mais comum de e-mail legítimo ser derrubado durante o rollout do DMARC.

Requisitos do Gmail e Yahoo em 2026

Desde fevereiro de 2024, Gmail e Yahoo exigem que todos os bulk senders (5.000+ mensagens por dia para seus usuários) publiquem SPF, DKIM e DMARC, mantenham um cabeçalho de unsubscribe em um clique (List-Unsubscribe com Post URL) e mantenham taxas de reclamação de spam abaixo de 0,3% medidas no Postmaster Tools. Microsoft 365 aplica regras similares via SmartScreen, e Apple Mail segue DMARC à risca em iCloud e Apple IDs gerenciados. Em 2026, esses padrões apertaram ainda mais: DMARC precisa estar em p=quarantine ou mais rigoroso para tráfego em massa não autenticado, confiança ARC foi adicionada à cadeia de avaliação para e-mail encaminhado, e taxas de reclamação acima de 0,1% disparam entrega reduzida mesmo antes do limite duro de 0,3%. Falha não é um aviso suave — seu e-mail vai para spam ou é rejeitado direto na camada SMTP. Mesmo remetentes não-bulk são cada vez mais afetados porque os filtros generalizam: um remetente B2B com 200 e-mails por dia ainda se beneficia de SPF, DKIM e DMARC limpos porque os classificadores de machine learning do Gmail reaproveitam os mesmos sinais de autenticação para pontuar toda mensagem. Resumo: SPF não é mais best-practice — é pré-requisito de entregabilidade. Rode o checker acima hoje para confirmar que seu SPF passa, depois siga para DKIM e DMARC para completar a stack.

Guias relacionados

• DMARC Policy Setup Guide — How SPF fits into the full email authentication stack