Email spoofing é um dos vetores de ataque mais comuns na internet. Alguém envia um e-mail que parece vir do seu domínio, mas na verdade sai de um servidor completamente diferente. O destinatário vê o nome da sua empresa no campo "De" e confia. O SPF (Sender Policy Framework) é a primeira linha de defesa contra isso, e configurá-lo corretamente é uma das coisas mais importantes que você pode fazer pela segurança do e-mail do seu domínio.

Este guia mostra tudo o que você precisa saber sobre registros SPF: o que são, como funcionam e exatamente como configurar um para o seu domínio.

O que é SPF e por que ele importa?#

SPF, ou Sender Policy Framework, é um protocolo de autenticação de e-mail definido na RFC 7208. Ele permite que donos de domínio especifiquem quais servidores de correio estão autorizados a enviar e-mail em nome do domínio. Quando um servidor de e-mail receptor recebe uma mensagem alegando vir do seu domínio, ele consulta seu registro SPF para verificar se o servidor remetente está realmente autorizado.

Por que SPF importa#

Sem um registro SPF, qualquer pessoa pode enviar e-mail que parece vir do seu domínio. Isso cria vários problemas sérios:

Email spoofing e phishing: atacantes podem se passar pela sua marca para enganar seus clientes, parceiros ou funcionários, fazendo com que revelem informações sensíveis ou cliquem em links maliciosos.
Problemas de deliverability: grandes provedores de e-mail como Gmail, Outlook e Yahoo usam SPF como sinal ao decidir se um e-mail vai para a caixa de entrada ou para o spam. Domínios sem registro SPF têm mais chance de ter seus e-mails legítimos filtrados.
Dano à reputação da marca: se spammers usam seu domínio para enviar lixo eletrônico em massa, a reputação do seu domínio cai nas redes dos provedores de e-mail. Isso afeta a entregabilidade de todo o e-mail que você envia, incluindo comunicações comerciais legítimas.
Exigências de conformidade: muitos padrões e regulamentações do setor esperam que as organizações implementem autenticação de e-mail. SPF é o mínimo.

Como o SPF funciona#

Entender a mecânica do SPF ajuda você a configurá-lo corretamente e a resolver problemas quando aparecerem.

O processo de verificação SPF#

Sua organização envia um e-mail de you@yourdomain.com usando seu servidor de correio autorizado.
O servidor de e-mail receptor extrai o domínio do envelope do remetente (o cabeçalho Return-Path, não o cabeçalho From).
O servidor receptor faz um lookup DNS TXT em yourdomain.com para obter o registro SPF.
O servidor compara o endereço IP do servidor remetente com a lista de IPs e hostnames autorizados no registro SPF.
Com base na comparação, o servidor retorna um destes resultados:
- Pass: o servidor remetente está autorizado. O e-mail segue normalmente.
- Fail: o servidor remetente não está autorizado, e o dono do domínio disse explicitamente para rejeitar remetentes não autorizados.
- SoftFail: o servidor remetente não está autorizado, mas o dono do domínio não tem confiança suficiente para pedir rejeição direta. O e-mail normalmente é aceito, mas marcado.
- Neutral: o dono do domínio não faz nenhuma afirmação sobre o servidor remetente.

O formato do registro SPF#

Um registro SPF é um registro DNS TXT publicado no seu domínio. Ele segue uma sintaxe específica:

v=spf1 [mechanisms] [qualifier]

v=spf1 é obrigatório e identifica o registro como SPF versão 1.
Os mecanismos definem quais servidores estão autorizados.
O qualifier no final define a política padrão para servidores que não correspondem a nenhum mecanismo.

Aqui vai um exemplo real:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all

Esse registro diz: permita que os servidores de correio do Google, do SendGrid e o endereço IP específico 203.0.113.50 enviem e-mail por este domínio. Rejeite todo o resto.

Configuração SPF passo a passo#

Siga estes passos para criar e publicar um registro SPF para o seu domínio.

Passo 1: identifique todos os seus serviços de envio de e-mail#

Antes de escrever seu registro SPF, você precisa de uma lista completa de cada serviço e servidor que envia e-mail em nome do seu domínio. Esse é o passo mais frequentemente esquecido, e deixar uma fonte de envio de fora vai fazer com que esses e-mails falhem nas verificações SPF.

Fontes comuns de envio de e-mail incluem:

Seu provedor de e-mail: Google Workspace, Microsoft 365, Zoho Mail, ProtonMail, etc.
Serviços de e-mail transacional: SendGrid, Mailgun, Amazon SES, Postmark, Resend, etc.
Plataformas de e-mail marketing: Mailchimp, HubSpot, ActiveCampaign, ConvertKit, etc.
Seu servidor web: se o seu site envia e-mails diretamente (envios de formulário de contato, redefinições de senha, confirmações de pedido).
Ferramentas de CRM e suporte: Zendesk, Freshdesk, Intercom, Salesforce, etc.
Outras ferramentas SaaS: qualquer aplicação que envie e-mail usando seu domínio.

Anote cada serviço. Verifique com diferentes departamentos da sua organização. O marketing pode usar uma plataforma que a engenharia desconhece, e vice-versa.

Passo 2: reúna os valores de include do SPF#

Cada provedor de serviço de e-mail publica o próprio domínio de include SPF. Aqui estão os valores de include para provedores comuns:

Provedor	SPF Include
Google Workspace	`include:_spf.google.com`
Microsoft 365	`include:spf.protection.outlook.com`
SendGrid	`include:sendgrid.net`
Mailgun	`include:mailgun.org`
Amazon SES	`include:amazonses.com`
Mailchimp	`include:servers.mcsv.net`
Postmark	`include:spf.mtasv.net`
Zoho Mail	`include:zoho.com`
HubSpot	`include:hubspot-email.com`
Freshdesk	`include:email.freshdesk.com`

Consulte a documentação do seu provedor para obter o valor exato de include. Os provedores atualizam isso de tempos em tempos, então sempre verifique com a documentação atual.

Passo 3: monte seu registro SPF#

Combine a tag de versão, todos os seus mecanismos de include e um qualifier em um único registro.

Modelo:

v=spf1 [include:provider1] [include:provider2] [ip4:your.server.ip] [qualifier]

Exemplo para uma empresa que usa Google Workspace e SendGrid:

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

Exemplo para uma empresa que usa Microsoft 365, Mailchimp e um servidor de correio próprio:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:198.51.100.25 -all

Passo 4: escolha seu qualifier#

O qualifier no final do seu registro SPF define o que acontece quando um e-mail vem de um servidor que não está listado no seu registro:

-all (Fail): servidores não autorizados devem ser rejeitados. Esta é a configuração recomendada para proteção máxima. Diz aos servidores receptores que você confia na sua lista e que qualquer e-mail vindo de um servidor não listado é fraudulento.
~all (SoftFail): servidores não autorizados devem ser tratados com suspeita, mas não rejeitados de imediato. Use isso durante a configuração inicial ou em testes, quando você ainda não tem certeza de que listou todas as fontes legítimas de envio.
?all (Neutral): nenhuma afirmação é feita. Isso oferece quase nenhuma proteção e não é recomendado.
+all (Pass): todo mundo está autorizado. Isso anula completamente o propósito do SPF. Nunca use isso.

Recomendação: comece com ~all durante o lançamento inicial e o período de testes. Depois de confirmar que todo o e-mail legítimo está passando pelas verificações SPF, mude para -all para proteção total.

Passo 5: publique o registro no DNS#

Faça login no seu provedor de DNS (Cloudflare, Route53, GoDaddy, Namecheap, etc.) e adicione ou atualize o registro TXT:

Vá para a página de gerenciamento de DNS do seu domínio.
Adicione um novo registro TXT (ou edite o registro SPF existente, se houver um).
Defina o Host/Name como @ (isso representa o seu domínio raiz).
Defina o Value/Content como a string completa do seu registro SPF.
Defina o TTL como 3600 (1 hora) ou o padrão do seu provedor.
Salve o registro.

Mudanças de DNS podem levar até 48 horas para se propagar globalmente, embora a maioria das alterações fique visível em 15 minutos a uma hora.

Passo 6: verifique seu registro SPF#

Após a publicação, verifique se o registro foi configurado corretamente. Você pode usar o Email Health Checker do Nova Uptime para fazer uma verificação completa da configuração de e-mail do seu domínio, incluindo a validação do SPF. A ferramenta confere a sintaxe do seu registro SPF, avalia sua política de qualifier, conta os lookups de DNS e identifica possíveis problemas.

Você também pode verificar pela linha de comando:

dig TXT yourdomain.com +short

nslookup -type=TXT yourdomain.com

Procure pelo registro TXT que começa com v=spf1. Confirme que todos os seus mecanismos de include esperados estão presentes e que o qualifier está correto.

Entendendo os mecanismos do SPF#

Os registros SPF aceitam vários tipos de mecanismos que dão flexibilidade na hora de definir remetentes autorizados.

`include`

Faz referência ao registro SPF de outro domínio. Esse é o mecanismo mais comum, porque é assim que os provedores de e-mail publicam seus intervalos de IPs autorizados.

include:_spf.google.com

Quando o servidor receptor encontra isso, ele faz um lookup DNS adicional para obter o registro SPF do Google e verifica o IP de envio contra os intervalos autorizados do Google.

`ip4` e `ip6`

Especifica endereços IP individuais ou intervalos CIDR autorizados a enviar e-mail.

ip4:203.0.113.50
ip4:198.51.100.0/24
ip6:2001:db8::/32

Use isso para os seus próprios servidores de correio ou qualquer serviço em que você conheça os endereços IP específicos.

`a`

Autoriza o endereço IP para o qual o registro A do seu domínio aponta. Se o seu servidor web também envia e-mail, essa é uma forma concisa de autorizá-lo.

`mx`

Autoriza os endereços IP dos servidores MX (mail exchange) do seu domínio. Como seus servidores MX recebem e-mail, eles muitas vezes precisam enviar e-mail também (respostas, bounces, encaminhamentos).

mx

`redirect`

Aponta para o registro SPF de outro domínio inteiramente, substituindo o seu. Diferente do include porque substitui em vez de complementar.

redirect=_spf.example.com

Erros comuns de SPF e como evitá-los#

Erro 1: ultrapassar o limite de 10 lookups DNS#

A especificação SPF (RFC 7208) limita o número total de lookups DNS a 10. Cada mecanismo include, a, mx e redirect conta como um lookup. Includes aninhados (um include que contém outros includes) também contam para esse limite.

Se o seu registro ultrapassar 10 lookups, a verificação SPF retorna um resultado PermError, e muitos servidores receptores tratam isso da mesma forma que se você não tivesse registro SPF nenhum.

Como corrigir:

Substitua mecanismos include por ip4/ip6 quando possível (mecanismos de IP não contam como lookups DNS).
Use ferramentas de SPF flattening para resolver os includes nos endereços IP subjacentes.
Consolide serviços de e-mail quando viável.
Remova includes de serviços que você não usa mais.

Erro 2: publicar múltiplos registros SPF#

Um domínio precisa ter exatamente um registro SPF. Se você publicar dois registros TXT que comecem com v=spf1, a verificação SPF retorna um PermError. Isso costuma acontecer quando alguém adiciona um novo registro SPF sem remover ou atualizar o existente.

Como corrigir: Junte todos os seus remetentes autorizados em um único registro SPF.

Errado:

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

Correto:

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

Erro 3: usar `+all`

Definir +all como qualifier significa que todo servidor no mundo está autorizado a enviar e-mail como sendo do seu domínio. Isso anula completamente o propósito do SPF e é um risco sério de segurança.

Erro 4: esquecer de atualizar após trocar de provedor#

Quando você troca de provedor de e-mail, migra plataformas de marketing ou adiciona novas ferramentas SaaS, seu registro SPF precisa ser atualizado. Includes antigos de serviços que você não usa mais desperdiçam lookups DNS, e includes faltando para novos serviços fazem o e-mail legítimo falhar.

Erro 5: não testar após mudanças#

Toda vez que você modificar seu registro SPF, teste-o. Envie e-mails de teste a partir de todos os seus serviços e verifique se eles passam nas verificações SPF. Use ferramentas como o Email Health Checker do Nova Uptime para validar a sintaxe e a configuração do seu registro.

SPF e o panorama maior da autenticação de e-mail#

SPF é um dos três principais protocolos de autenticação de e-mail. Para proteção completa, você deve implementar os três:

SPF + DKIM + DMARC#

SPF verifica se o servidor remetente está autorizado para o domínio.
DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica aos e-mails enviados, verificando que a mensagem não foi alterada em trânsito e foi enviada por uma parte autorizada.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) une SPF e DKIM com uma política que diz aos servidores receptores o que fazer quando a autenticação falha. Também fornece relatórios para que você veja quem está enviando e-mail como sendo do seu domínio.

Juntos, esses três protocolos oferecem proteção robusta contra email spoofing e phishing. SPF sozinho é um bom começo, mas é mais eficaz quando combinado com DKIM e DMARC.

Testando seu registro SPF#

Depois de configurar seu registro SPF, um teste minucioso é essencial. Aqui vai uma checklist de teste:

Verificação de DNS: confirme que o registro existe e está sintaticamente correto usando ferramentas de lookup DNS.
Envie e-mails de teste: envie e-mails de cada serviço autorizado e confira nos cabeçalhos do e-mail recebido por spf=pass.
Confira a contagem de lookups: garanta que seu total de lookups DNS é de 10 ou menos.
Verifique se existe apenas um registro SPF: confirme que você não tem registros SPF TXT duplicados.
Teste com um servidor não autorizado: se possível, envie um e-mail de uma fonte não autorizada e confirme que ele falha ou tem soft-fail no SPF.

O Email Health Checker do Nova Uptime automatiza a maior parte dessas verificações. Digite seu domínio e receba um relatório imediato sobre seu registro SPF, incluindo a força específica da política, eventuais problemas de sintaxe e recomendações de melhoria. Ele também verifica sua configuração de DKIM e DMARC para que você veja o panorama completo da autenticação de e-mail em um só lugar.

Mantendo seu registro SPF#

SPF não é uma configuração "configurou e esqueceu". Programe revisões regulares:

Auditorias trimestrais: revise seu registro SPF comparando com sua lista atual de serviços de envio de e-mail. Remova includes antigos e adicione novos.
Após qualquer mudança de infraestrutura: sempre que adicionar, remover ou trocar um provedor de serviço de e-mail, atualize seu registro SPF imediatamente.
Após problemas de deliverability: se você notar e-mails caindo no spam, verifique seu registro SPF primeiro. Um registro mal configurado é uma das causas mais comuns.
Monitoramento automatizado: use uma ferramenta de monitoramento de email health para checar continuamente sua configuração SPF e te alertar caso ela quebre.

Resumo#

Configurar SPF corretamente é uma das melhorias de maior impacto e menor esforço que você pode fazer pela segurança e deliverability do e-mail do seu domínio. Recapitulando:

Liste cada serviço que envia e-mail como sendo do seu domínio.
Reúna os valores de include SPF para cada serviço.
Monte um único registro SPF combinando todos os remetentes autorizados.
Comece com ~all e evolua para -all depois de confirmar que tudo funciona.
Publique o registro TXT no DNS.
Verifique com o Email Health Checker do Nova Uptime.
Revise e atualize trimestralmente.

Sua reputação de e-mail é construída ao longo de meses e pode ser destruída em dias. Um registro SPF bem configurado é a base que mantém ela protegida.

Perguntas frequentes#

Como faço para verificar meu registro SPF?#

Use uma ferramenta SPF checker gratuita para consultar e validar seu registro SPF. Digite seu domínio e a ferramenta consulta o DNS pelo seu registro TXT, valida a sintaxe, conta os lookups DNS (máximo de 10 permitidos) e verifica sua política de aplicação. Você também pode checar com dig TXT yourdomain.com ou nslookup -type=TXT yourdomain.com.

O que uma verificação SPF faz?#

Uma verificação SPF confirma que o servidor que envia e-mail em nome do seu domínio está autorizado no seu registro SPF do DNS. Os servidores de e-mail receptores fazem essa verificação automaticamente. Se o IP de envio não estiver listado no seu registro SPF, o e-mail pode ser marcado como spam ou rejeitado, dependendo da sua política DMARC.

Como faço para testar meu registro SPF?#

Depois de publicar seu registro SPF, teste-o assim: (1) rodando um SPF check gratuito, (2) enviando um e-mail de teste para o Gmail e checando os cabeçalhos em "Mostrar original" por spf=pass, ou (3) usando nslookup -type=TXT yourdomain.com para verificar se o registro foi publicado corretamente.

O que é o limite de 10 lookups do SPF?#

Os registros SPF são limitados a 10 lookups DNS. Cada mecanismo include:, a:, mx:, ptr: e redirect= conta como um lookup. Ultrapassar esse limite causa uma falha permanente do SPF (permerror), o que significa que todo o seu e-mail falha no SPF. Use o SPF Checker para contar seus lookups atuais.

Devo usar -all ou ~all no meu registro SPF?#

Use -all (hard fail) para proteção máxima — ele diz aos servidores receptores para rejeitarem e-mail vindo de fontes não autorizadas. Use ~all (soft fail) durante a configuração inicial ou migração. Depois de confirmar que todos os remetentes legítimos estão incluídos, mude para -all. Nosso Email Health Checker confere sua política SPF e recomenda a configuração adequada.

Leitura relacionada#

Guia de lookup e validação de registros SPF — Configuração avançada de SPF e troubleshooting
Guia completo de SPF, DKIM e DMARC — Como o SPF se encaixa na stack completa de autenticação
Checklist de deliverability de e-mail — 15 passos, incluindo configuração de SPF
Configuração de DMARC: de none a reject — Configure o DMARC depois que o SPF estiver pronto
SPF Checker grátis — Valide seu registro SPF na hora