Construtor de Registro SPF

Construa registros SPF com sintaxe apropriada

Generated SPF Record

16/255 chars
v=spf1 mx a ~all

Mail Server Authorization

Include Domains

Common includes: _spf.google.com, spf.protection.outlook.com

IPv4 Addresses/CIDRs

IPv6 Addresses/CIDRs

Default Policy (all)

DNS Setup

Add this as a TXT record for your domain:

Type: TXT
Host: @ (or domain)
TTL: 3600

O SPF Record Builder gera registros DNS TXT de Sender Policy Framework (SPF) sintaticamente corretos que autorizam servidores de mail específicos a enviar email em nome do seu domínio. Digite seus IPs de servidor de mail, inclusões de serviços de terceiros e preferências de política para produzir um registro pronto para publicar como v=spf1 ip4:203.0.113.5 include:_spf.google.com -all.

Entendendo Registros SPF

Se você executa um domínio que envia email, SPF é uma das primeiras coisas que você precisa configurar corretamente. Sem um registro SPF, qualquer servidor na internet pode enviar mensagens que pareçam vir do seu domínio, e servidores de mail receptores não têm forma de distinguir seu mail legítimo de mensagens de phishing falsificadas. SPF oferece uma forma de declarar quais endereços IP e serviços estão autorizados a enviar em seu nome, e oferece aos receptores uma forma de verificar essa declaração antes de aceitar uma mensagem.

Um registro SPF é um registro DNS TXT publicado na raiz do seu domínio. Quando um servidor de mail receptor recebe uma mensagem alegando ser do seu domínio, ele procura seu registro SPF e verifica se o endereço IP do servidor de envio corresponde a algum dos mecanismos autorizados que você listou. Se corresponder, a mensagem passa SPF. Se não corresponder, o servidor receptor aplica qualquer política que você especificou no mecanismo all no final do registro -- geralmente soft-failing ou hard-failing a mensagem.

A parte complicada é acertar o registro. SPF tem uma sintaxe específica, limites rígidos em lookups DNS e regras sobre como mecanismos são avaliados. Um include faltante significa que um serviço legítimo fica bloqueado. Um erro de digitação em um intervalo de IP significa que seu próprio servidor de mail falha autenticação. Este construtor orienta você através de cada mecanismo interativamente, valida suas entradas e produz um registro que você pode copiar diretamente para sua configuração DNS.

Como Construir um Registro SPF

  1. Comece com a tag de versão obrigatória v=spf1
  2. Adicione mecanismos ip4 ou ip6 para seus endereços IP de servidor de mail
  3. Adicione mecanismos include para serviços de email de terceiros (Google Workspace, Microsoft 365, Mailchimp, etc.)
  4. Adicione mecanismos a ou mx se seus registros A ou MX do domínio apontarem para servidores de envio
  5. Configure o mecanismo all no final para definir a política padrão para remetentes não autorizados
  6. Revise o registro gerado quanto ao comprimento e limites de lookup
  7. Copie o registro e publique-o como um registro DNS TXT no seu domínio

Exemplos de Registro SPF

CenárioRegistro SPF
Google Workspace apenasv=spf1 include:_spf.google.com ~all
Microsoft 365 apenasv=spf1 include:spf.protection.outlook.com -all
Google + Mailchimpv=spf1 include:_spf.google.com include:servers.mcsv.net ~all
IP direto + serviçov=spf1 ip4:203.0.113.5 include:_spf.google.com -all
Múltiplos IPs com intervalov=spf1 ip4:198.51.100.0/24 ip4:203.0.113.10 -all
Autorização baseada em MXv=spf1 mx ip4:192.0.2.1 ~all

Qualificadores de Mecanismo SPF

Cada mecanismo pode ser prefixado com um qualificador que diz aos servidores receptores como interpretar uma correspondência:

QualificadorSímboloSignificado
Pass+ (padrão)Remetente autorizado
Fail-Não autorizado -- rejeite a mensagem
SoftFail~Provavelmente não autorizado -- aceite mas marque
Neutral?Sem afirmação -- trate como se não houvesse SPF

O qualificador -all oferece a proteção mais rígida, instruindo receptores a rejeitar mensagens de servidores não listados. Use ~all durante implantação inicial para monitorar sem bloquear mail legítimo.

Quando Usar o SPF Record Builder

  • Configurar autenticação de email para um novo domínio pela primeira vez
  • Adicionar um serviço de email de terceiros como SendGrid, Amazon SES ou Postmark que envia em seu nome
  • Consolidar múltiplos mecanismos SPF de diferentes equipes ou departamentos em um único registro válido
  • Troubleshooting de entregabilidade de email quando mensagens caem em spam devido a falhas SPF
  • Migração de infraestrutura de email e atualização de listas de remetentes autorizados
  • Fortalecer sua política DMARC garantindo que SPF esteja configurado corretamente antes de passar para p=reject

Como Registros SPF Funcionam

Registros SPF são publicados como registros DNS TXT na raiz do seu domínio. Quando um servidor de mail receptor recebe um email alegando ser do seu domínio, ele consulta DNS para seu registro SPF e verifica se o endereço IP do servidor de envio corresponde a algum mecanismo autorizado.

Ordem de Avaliação SPF

O servidor receptor avalia mecanismos da esquerda para a direita. O primeiro mecanismo que corresponde ao IP de envio determina o resultado. Se nenhum mecanismo corresponder, o qualificador all no final fornece a ação padrão.

Limites de Lookup DNS

Avaliação SPF é limitada a 10 lookups DNS por RFC 7208. Esses mecanismos consomem um lookup cada: include, a, mx, ptr, exists e redirect. Mecanismos de IP literal (ip4, ip6) não contam. Includes aninhados também contam contra esse limite -- se um domínio incluído tem 3 includes adicionais, esses somam 4 lookups totais.

Valores Include Comuns de Terceiros

ServiçoMecanismo Include
Google Workspaceinclude:_spf.google.com
Microsoft 365include:spf.protection.outlook.com
Amazon SESinclude:amazonses.com
SendGridinclude:sendgrid.net
Mailchimpinclude:servers.mcsv.net
Postmarkinclude:spf.mtasv.net
Zendeskinclude:mail.zendesk.com

Restrições de Comprimento de Registro

Uma string DNS TXT única não pode exceder 255 caracteres. Registros mais longos devem ser divididos em múltiplas strings entre aspas dentro de um único registro TXT. O construtor rastreia a contagem de caracteres e avisa ao se aproximar desse limite.

Configuração de SPF na Prática

A decisão mais importante em seu registro SPF é o mecanismo all no final. Muitos administradores o deixam em ~all (softfail) indefinidamente porque se preocupam em bloquear email legítimo. Enquanto ~all é apropriado durante o período de implantação inicial, você deve planejar passar para -all (hard fail) uma vez confirmado que todos seus remetentes autorizados estão listados. Um softfail diz aos receptores que a mensagem é suspeita mas não instrui para rejeitar, o que oferece uma janela para spoofers abusarem seu domínio. Um hard fail oferece aos receptores um sinal claro para rejeitar mensagens não autorizadas, que é o objetivo inteiro de implantar SPF.

A segunda coisa a observar é contagem de lookup. Toda vez que você adiciona uma nova ferramenta SaaS que envia email -- uma plataforma de marketing, um helpdesk, um CRM, um serviço de email transacional -- você adiciona pelo menos um mecanismo include, e cada include consome um ou mais lookups DNS. É surpreendentemente fácil atingir o limite de 10 lookups, especialmente quando o registro SPF de cada serviço contém includes aninhados. Google Workspace sozinho consome 4 lookups (1 direto mais 3 aninhados). Adicione Microsoft 365, SendGrid e Mailchimp, e você pode já estar em 10. Quando você excede o limite, SPF retorna um erro permanente e seu email legítimo começa a falhar autenticação.

Para manter-se dentro do limite, considere aplanar includes em mecanismos ip4 e ip6 onde possível. O aplainamento substitui um include dinâmico pelos endereços IP estáticos que ele atualmente resolve, eliminando o lookup DNS. O trade-off é manutenção: se o provedor mudar seus intervalos IP, seu registro aplainado fica desatualizado. Serviços de aplainamento SPF automatizam esse processo resolvendo periodicamente os includes e atualizando seu registro. Use o SPF Record Length Checker para auditar sua contagem de lookup atual antes de fazer mudanças.

Perguntas Frequentes

Posso ter múltiplos registros SPF em um domínio?

Não. Um domínio deve ter exatamente um registro SPF TXT. Múltiplos registros SPF causam um permerror durante avaliação, que geralmente significa que SPF falha completamente. Se você precisa autorizar muitos serviços, combine todos os mecanismos em um único registro. Se você está ficando sem espaço ou lookups, use aplainamento ou o mecanismo redirect para apontar para um domínio de política SPF dedicado.

Qual é a diferença entre -all e ~all?

O -all (hard fail) instrui receptores a rejeitar emails de servidores não autorizados. O ~all (soft fail) diz aos receptores que a mensagem é suspeita mas ainda deve ser aceita, tipicamente marcada para escrutínio adicional. Comece com ~all durante testes, então mude para -all uma vez confirmado que todos os remetentes legítimos estão incluídos.

Como adiciono Google Workspace ao meu registro SPF existente?

Adicione include:_spf.google.com antes do mecanismo all em seu registro existente. Por exemplo, se seu registro atual for v=spf1 ip4:203.0.113.5 -all, mude para v=spf1 ip4:203.0.113.5 include:_spf.google.com -all.

O que acontece se eu exceder o limite de 10 DNS lookups?

A avaliação SPF retorna um erro permanente (permerror). A maioria dos servidores receptores trata isso como uma falha SPF, o que significa que seus emails podem ser marcados como spam ou rejeitados completamente -- especialmente se você também tem uma política DMARC rígida. Use o SPF Record Length Checker para auditar sua contagem de lookup.

Devo usar o mecanismo a ou mx?

O mecanismo a autoriza o endereço IP que seu registro A do domínio aponta para. O mecanismo mx autoriza os endereços IP de seus registros MX. Ambos consomem um lookup DNS cada. Se os mesmos IPs já estão cobertos por mecanismos ip4, pule a e mx para economizar lookups. Eles são mais úteis quando seu IP de servidor de envio muda frequentemente e é sempre refletido em seus registros A ou MX.

Como SPF se relaciona com DKIM e DMARC?

SPF, DKIM e DMARC trabalham juntos como um sistema em camadas de autenticação de email. SPF verifica se o servidor de envio está autorizado. DKIM verifica que o conteúdo da mensagem não foi adulterado usando uma assinatura criptográfica. DMARC os une definindo uma política para mensagens que falham em ambos os testes e exigindo alinhamento de domínio. Você precisa de todos os três para autenticação de email robusta.

Ferramentas Relacionadas

IPparse•Ferramentas Gratuitas de Rede e Calculadora de Sub-redes

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected