SPF: a primeira linha de defesa contra o spoofing
O Sender Policy Framework (SPF) é um mecanismo de autenticação de e-mail que permite ao proprietário de um domínio especificar quais servidores estão autorizados a enviar e-mail em seu nome. Sem SPF, qualquer pessoa pode enviar e-mails fazendo seu domínio aparecer como remetente — uma técnica chamada spoofing que é a base da maioria dos ataques de phishing. O SPF foi padronizado na RFC 7208 e representa o primeiro dos três pilares da autenticação moderna de e-mail, juntamente com DKIM e DMARC.
Quando um servidor recebe um e-mail, ele verifica o registro SPF do domínio remetente. Se o IP do servidor que enviou o e-mail está na lista de IPs autorizados pelo registro SPF, a verificação é aprovada. Caso contrário, o e-mail é sinalizado como potencialmente fraudulento. A decisão final (aceitar, rejeitar ou sinalizar) depende da política especificada no registro e da configuração DMARC do domínio.
Anatomia de um registro SPF
Um registro SPF é um registro TXT no DNS do domínio que começa com v=spf1 seguido de uma série de mecanismos e qualificadores. Os mecanismos definem quem está autorizado a enviar, enquanto o qualificador final (tipicamente ~all ou -all) define o que fazer com os e-mails que não correspondem a nenhum mecanismo autorizado.
O limite de 10 consultas DNS
Um dos aspectos mais críticos e menos compreendidos do SPF é o limite de 10 consultas DNS. Toda vez que o registro SPF usa um mecanismo que requer uma consulta DNS adicional (include, a, mx, redirect, exists), isso conta como uma consulta. Ultrapassar o limite de 10 causa um permerror: o registro SPF é considerado inválido e a autenticação falha para todos os e-mails.
Esse limite se torna problemático quando se utilizam muitos serviços de terceiros para o envio de e-mail. Um único include pode conter outros includes aninhados, e cada um conta para o limite. Por exemplo, include:_spf.google.com sozinho já consome 3-4 consultas. Adicione Mailchimp, SendGrid e HubSpot e o limite se esgota rapidamente. O nosso SPF Lookup analisa seu registro SPF e conta automaticamente as consultas DNS, alertando você caso esteja próximo do limite.
Como resolver os problemas SPF mais comuns
O problema mais frequente é ultrapassar o limite de 10 consultas. As soluções incluem: substituir os mecanismos include por entradas diretas ip4/ip6 (que não contam como consultas), usar serviços de SPF flattening que resolvem os includes em IPs estáticos, ou consolidar os serviços de e-mail para reduzir o número de includes necessários. Outra estratégia é usar subdomínios dedicados para diferentes serviços: marketing@news.exemplo.com pode ter seu próprio registro SPF independente.
Outro erro comum é ter múltiplos registros SPF para o mesmo domínio. As RFCs especificam claramente que um domínio deve ter apenas um registro TXT iniciando com v=spf1. Registros múltiplos causam um permerror. Se você precisa autorizar múltiplas origens, combine tudo em um único registro. Verifique a presença de registros duplicados com o TXT Lookup, que lista todos os registros TXT do domínio.
SPF sozinho não basta: o trio SPF + DKIM + DMARC
O SPF tem uma limitação importante: ele verifica apenas o IP do servidor remetente, não o conteúdo do cabeçalho From que o usuário vê. Um atacante poderia usar um servidor autorizado pelo seu próprio SPF para enviar e-mails com o seu domínio no cabeçalho From. Por isso, o SPF deve ser acompanhado do DKIM e do DMARC. O DKIM assina criptograficamente o e-mail, enquanto o DMARC verifica se o domínio no cabeçalho From está alinhado com o domínio autenticado pelo SPF ou DKIM.
Use o DMARC Lookup para verificar se seu domínio possui uma política DMARC ativa. Sem DMARC, mesmo um SPF perfeito não impede que e-mails falsificados sejam entregues. A combinação dos três protocolos cria uma defesa em camadas que torna o spoofing do seu domínio extremamente difícil, protegendo sua reputação e seus destinatários.
A configuração ideal inclui: SPF com ~all ou -all para autorizar apenas os servidores legítimos, DKIM com chave de 2048 bits para assinar todos os e-mails enviados, e DMARC com política progressiva (de p=none para monitoramento até p=reject para bloqueio total). Esse trio é hoje considerado o requisito mínimo para qualquer domínio que envie e-mail.