Em 2014, uma pequena empresa de e‑commerce acordou e descobriu que alguém havia enviado 50.000 e‑mails de phishing para seus clientes — todos parecendo vir do domínio oficial. Os e‑mails pareciam legítimos. O endereço de remetente estava correto. Os clientes clicaram, inseriram seus dados de cartão de crédito, e a empresa passou os seis meses seguintes reconstruindo a confiança que levou anos para conquistar.
O ataque foi possível por causa de um único registro DNS ausente: SPF.
SPF — Sender Policy Framework — é uma daquelas coisas que soa técnica e entediante até você entender o que ela realmente faz. É a diferença entre qualquer um poder enviar e‑mail como se fosse você e apenas seus servidores autorizados terem esse privilégio. É o equivalente digital de um segurança conferindo documentos na porta.
O problema que o SPF resolve
Eis uma verdade desconfortável sobre e‑mail: o 'From' que você vê é basicamente autoinformado. Quando você recebe um e‑mail de [email protected], não há nada inerente ao protocolo de e‑mail que prove que ele realmente veio dos servidores da Big Company. O remetente simplesmente... afirma que veio.
É como se qualquer pessoa pudesse escrever qualquer endereço de remetente em uma carta física. Você poderia enviar uma carta dizendo que é da Casa Branca, e o serviço postal a entregaria sem questionar. Foi exatamente assim que o e‑mail funcionou por décadas, e é por isso que o phishing se tornou um problema enorme.
O SPF muda isso ao permitir que os proprietários de domínios publiquem uma lista de remetentes autorizados. Quando chega um e‑mail alegando ser do seu domínio, o servidor receptor pode verificar: 'Isso realmente veio de um servidor que tem permissão para enviar por este domínio?' Se não, o e‑mail é sinalizado ou rejeitado.
Como ele realmente funciona
Vamos acompanhar o que acontece quando você envia um e‑mail do domínio da sua empresa, assumindo que o SPF esteja configurado corretamente.
Você redige um e‑mail no Gmail ou no seu cliente de e‑mail e clica em enviar. Seu e‑mail vai para o servidor de e‑mail da sua empresa (ou o servidor do seu provedor), que se conecta ao servidor de e‑mail do destinatário. Nesse momento, o servidor do destinatário vê duas coisas: o endereço IP do servidor que está tentando entregar o e‑mail e o domínio no endereço 'From'.
O servidor do destinatário então realiza uma consulta DNS para o registro SPF do seu domínio. Esse registro contém uma lista de endereços IP e domínios autorizados a enviar e‑mail em seu nome. Se o IP do servidor que está se conectando corresponder a algo nessa lista, o e‑mail passa no SPF. Caso contrário, falha.
Toda a verificação leva milissegundos. O remetente nem sabe que aconteceu. Mas essa simples consulta é a diferença entre seu e‑mail chegar à caixa de entrada e ser marcado como possível fraude.
Lendo um registro SPF
Registros SPF vivem no seu DNS como registros TXT. Eis um exemplo do mundo real:
Isso parece críptico, mas é bem direto quando você conhece a sintaxe. Vamos decompor parte por parte.
O 'v=spf1' no início declara que isto é um registro SPF (versão 1 — só existiu uma versão). Tudo o que vem depois é uma lista de quem está autorizado a enviar.
'include:_spf.google.com' significa 'procure o registro SPF do Google e confie nos servidores que eles listarem.' É assim que você autoriza o Google Workspace a enviar e‑mail pelo seu domínio sem precisar listar cada IP do Google (o que seria centenas).
'include:amazonses.com' faz o mesmo para o Amazon SES. Se você usa o SES para e‑mails transacionais, isso autoriza os servidores deles.
'ip4:203.0.113.42' autoriza diretamente um endereço IP específico. Talvez seja seu próprio servidor de e‑mail ou um sistema legado que envia relatórios.
O '-all' no fim é crucial. Significa 'rejeite qualquer coisa que não corresponda às regras acima.' Isso é chamado de 'hard fail'. Você também pode ver '~all' (soft fail, que marca falhas como suspeitas mas não as rejeita) ou '?all' (neutral, que essencialmente significa 'não sei, faça o que quiser'). Para segurança de verdade, você quer '-all'.
O limite de 10 consultas
É aqui que o SPF fica complicado, e onde muitas empresas têm problemas.
Cada declaração 'include' dispara uma consulta DNS. E o SPF tem um limite rígido de 10 consultas DNS por verificação. Se você exceder isso, seu registro SPF fica inválido — o que significa que todos os seus e‑mails falham no SPF, até os de servidores legítimos.
Esse limite existe porque as verificações de SPF acontecem em tempo real durante a entrega de e‑mail. Se um agente malicioso pudesse criar um registro SPF que disparasse centenas de consultas DNS, poderia usá‑lo como um ataque de negação de serviço contra a infraestrutura de DNS. O limite de 10 consultas previne isso.
O problema é que empresas modernas usam muitos serviços que enviam e‑mail: Google Workspace, uma plataforma de marketing, um serviço de e‑mail transacional, uma ferramenta de suporte ao cliente, talvez um sistema de RH. Cada um precisa de uma declaração 'include', e cada 'include' pode, por sua vez, conter mais 'includes'. O registro SPF do Google sozinho pode consumir 3–4 consultas.
Se você está batendo no limite, há algumas opções. Você pode usar serviços de SPF flattening que resolvem todos os includes em endereços IP diretos (embora isso exija manutenção conforme os IPs mudam). Pode consolidar o envio de e‑mails em menos provedores. Ou pode usar subdomínios — marketing.suaempresa.com para e‑mails de marketing, support.suaempresa.com para suporte — cada um com seu próprio registro SPF.
Limitações do SPF
SPF é essencial, mas não é uma solução completa. Entender suas limitações ajuda a construir uma estratégia adequada de autenticação de e‑mail.
Primeiro, o SPF verifica o endereço 'envelope from' (o endereço de retorno técnico), não o 'header from' (o que os destinatários veem). Um atacante pode passar no SPF enquanto ainda exibe um endereço falsificado para o destinatário. É por isso que o DMARC existe — ele vincula os resultados de SPF e DKIM ao endereço 'From' visível.
Segundo, o SPF quebra quando os e‑mails são encaminhados. Se alguém encaminha seu e‑mail para outro endereço, o IP do servidor que encaminha não estará no seu registro SPF, então o e‑mail encaminhado falha no SPF. Essa é uma limitação fundamental do protocolo, e é por isso que o DKIM (que assina o conteúdo do e‑mail) é importante como complemento.
Terceiro, o SPF só diz aos servidores de recebimento o que fazer com falhas se você usar '-all'. Muitos domínios usam '~all' ou '?all' porque têm receio de bloquear e‑mails legítimos. Mas isso significa que atacantes ainda podem enviar e‑mails falsificados — eles apenas serão marcados como suspeitos em vez de rejeitados.
Acertando o SPF
Configurar o SPF não é difícil, mas acertar exige algum planejamento. Eis a abordagem que funciona.
Comece auditando todo serviço que envia e‑mail a partir do seu domínio. Geralmente é mais do que você imagina. Seu provedor de e‑mail, obviamente. Mas também sua ferramenta de automação de marketing, seu serviço de e‑mail transacional, seu CRM, sua central de suporte, seu sistema de faturamento, talvez até sua impressora (algumas enviam scan‑to‑email). Faça uma lista completa.
Para cada serviço, encontre a declaração de include de SPF deles. Isso geralmente está na documentação, em 'autenticação de e‑mail' ou 'configuração de DNS'. Adicione cada uma ao seu registro SPF.
Comece com '~all' (soft fail) em vez de '-all' (hard fail). Isso permite monitorar problemas sem bloquear e‑mails legítimos. Acompanhe seus relatórios de DMARC (você está coletando relatórios de DMARC, certo?) em busca de falhas de SPF. Se você vir serviços legítimos falhando, adicione‑os ao seu registro.
Depois de algumas semanas sem falhas inesperadas, mude para '-all'. É aí que o SPF realmente começa a protegê‑lo. Até lá, é apenas consultivo.
Por fim, coloque um lembrete no calendário para revisar seu registro SPF trimestralmente. Os serviços mudam, você adiciona novas ferramentas, os IPs rotacionam. Um registro SPF desatualizado é quase tão ruim quanto não ter registro.
Frequently asked questions
Meu registro SPF está correto, mas os e‑mails ainda vão para o spam. Por quê?
SPF é apenas um dos fatores na entregabilidade. Filtros de spam também consideram a reputação do seu domínio, reputação de IP, conteúdo do e‑mail, taxas de engajamento e se você configurou DKIM e DMARC. Passar no SPF não garante colocação na caixa de entrada — só significa que você superou um obstáculo.
Posso ter vários registros SPF para um único domínio?
Não, e isso é um erro comum. Se você tiver vários registros TXT que começam com 'v=spf1', as verificações de SPF vão falhar. Você precisa de exatamente um registro SPF que inclua todos os seus remetentes autorizados.
O que acontece se eu exceder o limite de 10 consultas?
Seu registro SPF se torna inválido, e todas as verificações de SPF retornam 'permerror'. A maioria dos servidores de recebimento trata isso como uma falha de SPF, o que pode prejudicar sua entregabilidade. Use uma ferramenta de verificação de SPF para contar suas consultas antes de publicar mudanças.
Devo usar -all ou ~all?
Use ~all enquanto estiver configurando e testando. Quando tiver confiança de que seu registro SPF inclui todos os remetentes legítimos, mude para -all. O soft fail (~all) não protege você de spoofing de verdade — ele apenas sinaliza e‑mails suspeitos sem rejeitá‑los.