Defaults.Exposed › Correções › SPF (Sender Policy Framework)

Como corrigir SPF (Sender Policy Framework)

O SPF é a linha nas definições do seu domínio que indica quais os serviços de correio autorizados a enviar e-mail em nome da sua empresa. Sem ele, qualquer pessoa no mundo pode enviar e-mails que parecem vir de si — e o seu próprio e-mail legítimo tem mais probabilidade de cair no spam dos clientes.

O essencial para o seu negócio: Qualquer pessoa pode enviar e-mails fazendo-se passar pela sua empresa — para os seus clientes, colaboradores e fornecedores — faturas, pedidos de mudança de dados bancários, tudo. Ao mesmo tempo, os seus orçamentos e faturas verdadeiros têm mais probabilidade de ir parar ao lixo, por isso negócios morrem em silêncio.

Quanto isto lhe pode custar

Um burlão envia ao seu cliente uma fatura «sua» com os dados bancários dele e recebe o pagamento. Só descobre semanas depois, quando o cliente pergunta onde está a encomenda — e agora é a sua reputação, e possivelmente a sua responsabilidade.
Os seus orçamentos, faturas e respostas caem em silêncio na pasta de spam dos clientes porque os grandes fornecedores não conseguem confirmar que são mesmo seus. Os negócios arrefecem e nunca percebe porquê.
Um burlão faz-se passar pelo dono ou pela pessoa das finanças e pede aos colaboradores um pagamento urgente ou cartões-presente — a mensagem parece mesmo vir do seu domínio, por isso alguém paga.
A equipa de TI ou de segurança de um cliente maior verifica o seu domínio, não vê proteção do remetente e ou desiste de si ou exige que corrija antes de assinar — custando-lhe o negócio ou semanas de atraso.
Pensa que está protegido porque existe um registo SPF — mas está em «falha suave» sem nada que o imponha, ou está silenciosamente avariado, por isso o e-mail falsificado continua a passar.

Por que importa. Falsificar o endereço «de» de um e-mail é trivialmente fácil e não custa nada ao atacante. O SPF é a forma mais barata e rápida de tornar o seu domínio mais difícil de imitar e de manter o seu correio legítimo fora do spam. O Google e o Yahoo agora mandam ativamente para o lixo ou rejeitam correio de domínios não autenticados, por isto já não é opcional — é o mínimo exigido para que o seu e-mail seja sequer entregue.

A versão curta

Neste momento, a menos que tenha o SPF bem configurado, qualquer pessoa no mundo pode enviar e-mails que parecem vir da sua empresa. Pode enviar aos seus clientes faturas falsas, aos seus colaboradores pedidos de pagamento falsos e aos seus fornecedores e-mails como se fosse você — e as mensagens vão parecer genuínas, porque nada no seu domínio diz o contrário.

O SPF (Sender Policy Framework) é a solução. É uma única linha de texto nas definições do seu domínio que lista quais os serviços de correio realmente autorizados a enviar e-mail em seu nome. Os fornecedores de correio recetores — Gmail, Outlook, todos — verificam essa lista antes de decidir se uma mensagem é real. Sem lista, ou com uma lista fraca, não têm nada em que se basear.

Esta página cobre duas coisas que têm de estar ambas certas: se existe sequer um registo SPF e se está configurado de forma suficientemente estrita para fazer realmente o seu trabalho.

Quanto isto lhe pode custar

Estas são as formas reais e do dia a dia em que um registo SPF em falta ou fraco se traduz em dinheiro e confiança a saírem pela porta. Nunca nomeamos uma empresa real — são os padrões que vemos nos dados.

O desvio da fatura. Um criminoso envia a um dos seus clientes um e-mail que parece exatamente vir de si, com uma fatura realista que tem a conta bancária dele. O seu cliente paga-a. A primeira vez que ouve falar do assunto é num e-mail a perguntar onde está a encomenda. Agora há um cliente furioso, um pagamento que foi parar a um criminoso e uma conversa difícil sobre quem fica com o prejuízo.
A burla do CEO/finanças. Alguém envia um e-mail à sua contabilista «da parte» do dono: «Pequeno favor — consegues processar este pagamento antes do fim do dia?» Como a mensagem parece mesmo vir do seu domínio, não desperta a desconfiança de ninguém. O dinheiro sai da empresa.
O imposto silencioso da entregabilidade. Os seus orçamentos e faturas começam a cair na pasta de spam dos clientes porque o Gmail e o Yahoo não conseguem confirmar que são mesmo seus. Não recebe devolução, não recebe erro — os negócios simplesmente ficam em silêncio. Está a perder negócio e nem consegue ver que está a acontecer.
O contrato perdido. A equipa de compras ou de segurança de um cliente maior faz uma verificação básica ao seu domínio como parte do processo de integração. Não vê autenticação do remetente e sinaliza-o como risco. No melhor dos casos, anda numa correria a corrigir sob pressão de prazo; no pior, escolhem um concorrente que passou.
A onda que envenena a marca. O seu domínio é usado numa campanha de phishing dirigida ao público. As pessoas que foram enganadas passam a desconfiar de todos os e-mails com o seu nome — por isso até as suas ofertas e renovações genuínas são ignoradas ou denunciadas.

O fio comum a tudo isto: o atacante não gasta nada e a sua empresa fica com o custo e a culpa.

O que é na realidade

Quando um e-mail chega, o servidor de correio recetor quer saber uma coisa: isto vem mesmo de quem diz vir? O SPF responde a parte dessa pergunta.

Publica uma linha curta de texto nas definições de DNS do seu domínio — um «registo TXT» — que nomeia os serviços de correio autorizados a enviar em seu nome. Algo como:

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

Em termos simples, lê-se: «O correio genuíno nosso vem dos servidores do Google e do SendGrid — rejeita tudo o resto que diga ser nosso.»

As duas partes que importam para a sua nota:

O registo existe? Esta é a grande questão (tem mais peso do que qualquer outra verificação de e-mail isolada). Sem registo, os recetores não têm lista para verificar, por isso a imitação fica completamente aberta. Há ainda um modo de falha subtil: se o seu domínio tiver dois ou mais registos SPF, as regras dizem que todos são inválidos — por isso, na prática, não tem SPF nenhum, mesmo parecendo que tem.
A política é suficientemente estrita? Um registo pode existir e mesmo assim não ter dentes. O final — o mecanismo «all» — é a instrução para os recetores:
- -all (falha rígida) — rejeita tudo o que não esteja na lista. O mais forte. Pontuação máxima.
- ~all (falha suave) + DMARC em reject — a configuração recomendada atual. Proteção equivalente à falha rígida, sem o risco de o correio legítimo reencaminhado ser devolvido. Pontuação máxima.
- ~all + DMARC em quarantine — aceitável, ligeiramente mais fraco; passe o DMARC para reject para proteção total.
- ~all sozinho (sem imposição por DMARC) — fraco. Diz «provavelmente falso, entrega na mesma». O correio falsificado continua a passar. É a armadilha em que muitas empresas caem julgando-se protegidas.
- ?all (neutro) — não dá proteção nenhuma.
- +all — ativamente perigoso: diz ao mundo que qualquer pessoa pode enviar por si. Nunca use isto.

Há mais uma falha invisível: o SPF só pode desencadear até 10 consultas de DNS quando é avaliado. Empilhe demasiadas entradas include: e o registo ultrapassa esse limite, ponto em que os recetores tratam tudo como avariado — e volta a não ter proteção. É um problema comum e silencioso para empresas que usam muitas ferramentas de marketing e SaaS.

Como é o «bom»: exatamente um registo SPF, listando todos os serviços que enviam legitimamente correio por si, terminando em -all (ou ~all combinado com DMARC em p=reject) e bem dentro do limite das 10 consultas.

Como corrigir (gratuito, ~10 minutos)

Entregue esta secção a quem gere o seu domínio ou site — e note que a correção é gratuita. É uma alteração a uma definição de DNS, não um produto que se compra. Só cobramos para monitorizar que se mantém correto ao longo do tempo, não para fazer a alteração.

Passo 1 — Liste todos os serviços que enviam e-mail por si. É a parte que as pessoas erram. Aponte todos: o seu fornecedor de caixa de correio (Google Workspace, Microsoft 365, etc.), além de qualquer ferramenta de newsletter, CRM, helpdesk, plataforma de comércio eletrónico, aplicação de faturação/contabilidade e sistema de reservas. Se um serviço envia correio com o seu nome e o esquece, o seu SPF vai bloquear esse correio quando apertar a política.

Passo 2 — Publique um registo TXT no seu domínio raiz. Combine as linhas «include» de todos os seus remetentes num único registo. Por plataforma comum:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (ou o domínio adequado à sua região)

Um registo combinado fica assim:

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

Onde o adicionar, por fornecedor:

Cloudflare: DNS → Records → Add record → Tipo TXT, Nome @, Conteúdo = o valor acima.
Microsoft 365 / consola do Google: publicam a string «include» exata a usar no assistente de configuração; copie-a para o registo TXT do seu fornecedor de DNS.
GoDaddy / a maioria dos alojamentos: gestão de DNS → Adicionar → TXT, Host/Nome @, Valor = o registo.

Passo 3 — Comece em segurança, depois imponha. Enquanto confirma que a sua lista de remetentes está completa, publique com ~all (falha suave) para que nada legítimo seja bloqueado por acidente. Depois de confirmar que todo o seu correio genuíno continua a fluir, aperte para -all (falha rígida) — ou, melhor, mantenha ~all e acrescente uma política DMARC de p=reject, que é o emparelhamento moderno recomendado.

Passo 4 — Garanta que tem exatamente UM registo. Se já existir um registo SPF antigo, edite esse em vez de adicionar um segundo. Dois registos v=spf1 anulam-se e deixam-no sem proteção.

Passo 5 — Vigie a contagem de consultas. Se tiver muitos remetentes, pode ultrapassar o limite de 10 consultas. Se isso acontecer, consolide — alguns fornecedores oferecem «achatamento de SPF» (SPF flattening), ou retire remetentes que já não usa.

Passo 6 — Volte a verificar o seu domínio para confirmar que agora passa, com o registo presente e a política estrita.

Erros comuns

Dois registos SPF. A falha silenciosa mais comum. Adicionar um novo registo em vez de editar o existente invalida ambos. Tem de haver exatamente um.
Parar em ~all e dar-se por concluído. A falha suave sem DMARC por trás é o meio-termo fraco — parece configurado mas mal o protege. Ou vai para -all, ou emparelha ~all com DMARC p=reject.
Esquecer um remetente. Apertar para -all antes de listar a sua aplicação de faturação, CRM ou ferramenta de newsletter vai começar a bloquear o seu próprio correio legítimo. Liste tudo primeiro.
Estourar o limite das 10 consultas. Cada include: pode encadear mais consultas. Demasiadas e o registo é tratado como avariado. Mantenha-o enxuto.
Usar +all. Isto autoriza explicitamente toda a internet a enviar por si. É pior do que não ter registo. Nunca o publique.

Onde isto se encaixa

O SPF é a base, mas é uma de três camadas. O DKIM acrescenta uma assinatura criptográfica que prova que a mensagem não foi adulterada, e o DMARC é a instrução que liga o SPF e o DKIM e diz aos recetores o que realmente fazer com o correio que falha — incluindo bloquear a imitação do nome «de» visível que os seus clientes veem. Acerte primeiro no SPF (é a vitória mais rápida e a de maior peso), depois acrescente o DKIM e o DMARC para fechar a porta por completo. As três correções são gratuitas.

Configure no seu fornecedor

Passo a passo para os fornecedores mais populares:

Perguntas frequentes

Não percebo de informática — consigo resolver isto sozinho?

Não precisa de perceber os detalhes. A alteração é uma ou duas linhas adicionadas às definições do seu domínio, feitas por quem gere o seu site ou pelo seu fornecedor de TI. Entregue-lhes a secção «Como corrigir» abaixo — costuma demorar uns minutos e é gratuito. Só cobramos para monitorizar que se mantém correto ao longo do tempo.

Já temos um registo SPF — não significa isso que estamos protegidos?

Não necessariamente. Ter um registo é a primeira metade; tê-lo configurado de forma estrita é a segunda. Um registo que termina em «~all» (falha suave) sem DMARC por trás diz aos servidores recetores «isto pode ser falso, mas entrega na mesma» — o que dá proteção mínima. Dois registos SPF, ou um que faz demasiadas consultas, é tratado como avariado e não lhe dá proteção nenhuma, apesar de parecer existir. As duas metades têm de estar certas.

Corrigir isto pode estragar o meu próprio e-mail por acidente?

Pode, se o registo deixar de fora um remetente legítimo — por exemplo a sua aplicação de faturação ou a ferramenta de newsletter que envia correio em seu nome. É exatamente por isso que a abordagem segura é primeiro listar todos os serviços que enviam correio por si, publicar com um «~all» suave enquanto confirma que nada ficou de fora e só depois apertar para falha rígida. Feito por esta ordem, não estraga nada.

Qual é a diferença entre «~all» e «-all», e qual devemos usar?

«-all» (falha rígida) diz aos recetores para rejeitarem tudo o que não esteja na sua lista — a definição mais forte. «~all» (falha suave) diz «provavelmente não é legítimo, mas aceita na mesma». A recomendação atual de boas práticas é «~all» combinado com uma política DMARC de «reject» — esse par dá-lhe a mesma proteção que «-all» sem o risco de o correio reencaminhado ser devolvido. «~all» sozinho, sem DMARC a impô-lo, é a configuração fraca a evitar.

O SPF sozinho impede toda a falsificação de e-mail?

Não — é a primeira camada essencial, não a resposta completa. O SPF diz que servidores podem enviar por si, mas não diz aos recetores o que fazer quando uma mensagem falha, e não cobre o nome «de» visível que o utilizador vê. Para travar a imitação por completo, também precisa de DKIM e DMARC. O SPF é o primeiro passo mais rápido e de maior impacto, por isso comece aqui e depois acrescente os outros dois.

Quanto tempo leva a fazer efeito e pode ter algum custo?

As alterações de DNS costumam fazer efeito em minutos a poucas horas. A correção em si é sempre gratuita — é apenas editar uma definição no seu fornecedor de DNS. Quem lhe disser que precisa de um produto pago para adicionar um registo SPF está enganado.