Construtor de Registro SPF
Construa registros SPF com sintaxe apropriada
Generated SPF Record
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:
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
- Comece com a tag de versão obrigatória
v=spf1 - Adicione mecanismos ip4 ou ip6 para seus endereços IP de servidor de mail
- Adicione mecanismos include para serviços de email de terceiros (Google Workspace, Microsoft 365, Mailchimp, etc.)
- Adicione mecanismos a ou mx se seus registros A ou MX do domínio apontarem para servidores de envio
- Configure o mecanismo all no final para definir a política padrão para remetentes não autorizados
- Revise o registro gerado quanto ao comprimento e limites de lookup
- Copie o registro e publique-o como um registro DNS TXT no seu domínio
Exemplos de Registro SPF
| Cenário | Registro SPF |
|---|---|
| Google Workspace apenas | v=spf1 include:_spf.google.com ~all |
| Microsoft 365 apenas | v=spf1 include:spf.protection.outlook.com -all |
| Google + Mailchimp | v=spf1 include:_spf.google.com include:servers.mcsv.net ~all |
| IP direto + serviço | v=spf1 ip4:203.0.113.5 include:_spf.google.com -all |
| Múltiplos IPs com intervalo | v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.10 -all |
| Autorização baseada em MX | v=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:
| Qualificador | Símbolo | Significado |
|---|---|---|
| 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ço | Mecanismo Include |
|---|---|
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| Amazon SES | include:amazonses.com |
| SendGrid | include:sendgrid.net |
| Mailchimp | include:servers.mcsv.net |
| Postmark | include:spf.mtasv.net |
| Zendesk | include: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
- SPF Record Length Checker - Verifique o comprimento do registro SPF e limites de lookup
- DKIM TXT Record Formatter - Formatar registros DKIM com aspas apropriadas
- DMARC Record Builder - Construir registros DMARC com todas as tags de política
- DNS Record Set Deduper - Encontre e remova registros DNS duplicados
- Zone File Linter - Verifique arquivos de zona para erros de sintaxe e duplicatas