Digite qualquer domínio para obter e validar o registro SPF. Veja o valor completo do registro, cada mecanismo explicado e se a configuração está correta.
Um registro SPF (Sender Policy Framework) é um registro DNS TXT que autoriza servidores de e-mail específicos a enviar e-mail em nome de um domínio. É um dos três protocolos principais de autenticação de e-mail, juntamente com DKIM e DMARC. Quando uma mensagem chega, o servidor de e-mail destinatário consulta o registro SPF do domínio remetente para verificar se o endereço IP de entrega está autorizado.
O SPF é fundamental para a entregabilidade de e-mail. Sem um registro SPF válido, os e-mails do seu domínio têm maior probabilidade de ser marcados como spam ou rejeitados por completo. A maioria dos principais provedores de caixa de entrada — Gmail, Outlook, Yahoo — considera os resultados SPF como um sinal primário de confiança. Google e Yahoo agora exigem SPF como parte dos requisitos para remetentes em massa.
Um registro SPF usa um conjunto de mecanismos para descrever os remetentes autorizados. Os mecanismos comuns incluem ip4 e ip6 (endereços IP específicos ou intervalos), mx (os servidores de e-mail do domínio) e include (delegação ao registro SPF de outro domínio). O registro termina com um mecanismo all que define o que fazer com remetentes não listados explicitamente: ~all (softfail), -all (hardfail) ou ?all (neutral).
Autoriza um endereço IPv4 específico ou um intervalo CIDR. Exemplo: ip4:203.0.113.1 ou ip4:203.0.113.0/24.
Autoriza um endereço IPv6 específico ou um intervalo. Exemplo: ip6:2001:db8::1.
Autoriza os servidores de e-mail listados nos registros MX do domínio. Útil quando os servidores de envio e de recebimento são os mesmos.
Importa e avalia o registro SPF de outro domínio. Usado para autorizar remetentes de terceiros, como Google Workspace ou SendGrid.
Autoriza os endereços IP dos registros A ou AAAA do domínio. Útil para servidores web que também enviam e-mail.
Um Catch-All que se aplica a remetentes não correspondidos por nenhum outro mecanismo. Prefixo ~(softfail), -(hardfail) ou ?(neutral).
Evidência DNS em tempo real
O verificador SPF obtém a política TXT pública e expõe as regras de autorização que os destinatários podem avaliar. É um diagnóstico de configuração, não uma garantia de que todas as mensagens reais passarão.
Um domínio sem política SPF não fornece evidência de autorização SPF. Um domínio com vários registros TXT v=spf1 produz um erro permanente de SPF em vez de os combinar automaticamente.
Leia o registro retornado exatamente como o DNS o publica. Includes de provedores antigos, espaços em branco acidentais e uma política colocada no subdomínio errado podem alterar o resultado.
ip4 e ip6 identificam redes diretamente. include, a, mx, exists e redirect podem desencadear trabalho DNS adicional e podem depender de registros controlados por outro provedor.
Uma política pode ser sintaticamente válida e mesmo assim autorizar os sistemas errados. Compare cada mecanismo com o inventário atual de remetentes, em vez de tratar uma análise verde como aprovação da configuração empresarial.
Leia a política
A pergunta útil não é apenas se existe um registro. É se o registro pode ser avaliado e se o seu limite de autorização corresponde ao fluxo real de e-mail.
O SPF avalia o domínio usado em MAIL FROM ou HELO, não necessariamente o cabeçalho From visível. Uma origem que passa pode, portanto, estar tecnicamente autorizada e mesmo assim falhar o alinhamento DMARC com o endereço que o destinatário vê.
~all e -all comunicam forças de política diferentes para origens sem correspondência. ?all não faz nenhuma afirmação positiva. Sintaxe inválida, políticas duplicadas ou avaliação DNS excessiva podem produzir permerror e devem ser corrigidas, não interpretadas como um fail comum.
Conte os mecanismos que disparam DNS em toda a cadeia de include. O registro de nível superior pode conter apenas dois includes, enquanto esses provedores se expandem em operações a, mx, include, exists ou redirect suficientes para exceder o limite do RFC.
+all autoriza todos os remetentes. Intervalos IP grandes ou includes desnecessários também podem facilitar o spoofing. Um verificador SPF deve ajudar a restringir a autorização, não apenas confirmar que uma string TXT começa com v=spf1.
Fluxo de diagnóstico
Uma verificação disciplinada liga a política publicada às identidades reais de envio.
Inspecione uma mensagem realmente enviada ou as configurações do provedor para encontrar o domínio do return-path e consulte esse domínio, em vez de assumir que a raiz organizacional é avaliada.
Identifique o proprietário de cada autorização include, intervalo IP, a e mx. Remova origens obsoletas somente depois de confirmar que não enviam mais e-mail legítimo.
Envie por cada plataforma de produção e inspecione spf=, smtp.mailfrom e o alinhamento DMARC nos cabeçalhos recebidos. Isso detecta desalinhamentos de identidade que uma consulta DNS isolada não observa.
Se o registro estiver ausente ou estruturalmente errado, use o Gerador de Registro SPF para redigir uma política combinada, publique-a e execute este verificador novamente após as caches DNS expirarem.
Limites do resultado
O SPF é um sinal no nível do domínio. Sozinho, não responde a questões de destinatário, conteúdo ou autenticação completa.
O DMARC exige uma identidade SPF ou DKIM alinhada. Um domínio return-path separado pode passar no SPF enquanto o domínio From visível permanece desprotegido.
Use o Verificador DKIM e o Verificador DMARC para esses registros DNS e políticas distintos.
Os destinatários combinam autenticação com reputação de envio, taxas de reclamação, conteúdo, engajamento e os próprios filtros. Passar no SPF é evidência necessária para muitos remetentes, não uma garantia de caixa de entrada.
O registro descreve quem pode enviar por um domínio. Use o Verificador de E-mail para verificar se um endereço de destino pode receber e-mail.
Referência do protocolo
Os painéis dos provedores simplificam o SPF, mas os destinatários avaliam a política publicada de acordo com o protocolo.
O RFC 7208 da IETF define identidades SPF, registros TXT, mecanismos, qualificadores, limites DNS e códigos de resultado. É a referência autoritativa para registros duplicados e o comportamento de permerror.
Depois de corrigir o SPF, adicione a assinatura de mensagens com o Gerador DKIM e publique uma política alinhada com o Gerador DMARC.
Escolha a próxima ferramenta pelo tipo de evidência: destinatário, descoberta, DNS e infraestrutura, ou fluxo do remetente.
Ferramentas gratuitas
Gere um registro DNS SPF válido para o seu domínio em segundos. Adicione servidores de email, diretivas include e escolha a política. Grátis, sem cadastro.
Evidência de domínio ou infraestrutura — não prova da caixa de correio.
Ferramentas gratuitas
Verifique o registro DKIM de qualquer domínio e seletor. Veja a chave pública completa e se a assinatura DKIM está bem configurada. Grátis, sem cadastro.
Evidência de domínio ou infraestrutura — não prova da caixa de correio.
Ferramentas gratuitas
Verifique o registro DMARC de qualquer domínio. Veja a política, o alinhamento, os endereços de relatórios e se o DMARC está correto. Grátis, sem cadastro.
Evidência de domínio ou infraestrutura — não prova da caixa de correio.
Ferramentas gratuitas
Consulte registros A, AAAA, MX, TXT, NS ou CNAME de qualquer domínio. Faça uma consulta DNS em tempo real com resultados imediatos. Grátis, sem cadastro.
Evidência de domínio ou infraestrutura — não prova da caixa de correio.
Ferramentas de email
Execute um teste de entregabilidade em uma amostra real. Revise evidências de SPF, DKIM, DMARC, DNS, blacklist, filtro de spam, cabeçalhos e conteúdo.
Diagnóstico do remetente ou da mensagem — não descoberta de endereços.
Ferramentas de verificação de email
Verifique se um e-mail é válido com um verificador grátis de sintaxe, MX, SMTP da caixa, descartável, role e catch-all.
Evidência do destinatário — não do remetente nem da configuração DNS.
Um domínio sem registro SPF falha nas verificações SPF. Os servidores destinatários tratam isso como um resultado neutro, mas, combinado com outros sinais, aumenta a probabilidade de spam. Google e Yahoo agora exigem registros SPF para todos os remetentes em massa. Qualquer domínio que envie e-mail deve ter um registro SPF publicado.
Ter dois ou mais registros TXT que começam com v=spf1 no mesmo domínio causa um erro permanente de SPF (permerror). A avaliação SPF falha por completo e todos os e-mails desse domínio falharão no SPF. É preciso combinar todas as regras em um único registro SPF.
SPF fail significa que o endereço IP de entrega não está autorizado no registro SPF do domínio. O resultado depende do mecanismo all: ~all causa um softfail (suspeito, mas normalmente ainda entregue), enquanto -all causa um hardfail (geralmente rejeitado ou enviado para o spam). Um resultado neutro ?all não tem efeito em nenhum sentido.
Um permerror (erro permanente) ocorre quando o SPF não pode ser avaliado devido a um problema de configuração — na maioria das vezes porque o domínio tem mais de um registro SPF, ou o registro tem mecanismos demais de consulta DNS (acima de 10). Corrija os permerrors imediatamente, pois eles fazem com que todos os e-mails do seu domínio falhem no SPF.
O SPF permite no máximo 10 consultas DNS durante a avaliação. Cada mecanismo include, a, mx, ptr e exists conta como uma consulta, e os includes aninhados também contam. Ultrapassar 10 consultas no total resulta em um permerror.
Se o seu registro SPF está se aproximando do limite de 10 consultas, considere o SPF flattening — resolver todos os includes para os endereços IP reais e substituir os mecanismos include por entradas diretas ip4/ip6. Isso reduz a contagem de consultas a zero para essas entradas, mas você precisará atualizar o registro sempre que o provedor alterar os intervalos de IP.
O SPF é o primeiro passo. Combine-o com DKIM e DMARC para proteger totalmente o seu domínio. Depois, mantenha a lista limpa com a verificação de e-mail da BillionVerify.
600 créditos/mês + 20/dia de bônus de login · 99,9% de precisão SMTP · Acesso imediato à API · Sem cartão de crédito
