Publicar um registo SPF não protege nada se esse mesmo registo ultrapassar um limite que quase ninguém verifica. A causa mais frequente de falha SPF raramente é a sua ausência pura e simples. Vem de um registo mal construído, que ultrapassa o limite de 10 pedidos DNS fixado pela RFC 7208 sem que nada avise o remetente antes do incidente. Um registo SPF válido contém a lista dos servidores autorizados a enviar emails por um domínio; acima de 10 pedidos DNS necessários para o avaliar, o servidor recetor devolve um erro PermError que invalida a autenticação de todas as mensagens do domínio, incluindo as de remetentes perfeitamente legítimos e não só a que fez transbordar o limite.
O que um registo SPF autoriza realmente
Um registo SPF (Sender Policy Framework) é um registo DNS do tipo TXT publicado num domínio, que lista os endereços IP autorizados a enviar emails em seu nome. Um servidor recetor, o Gmail ou o Outlook por exemplo, consulta este DNS e compara o IP de ligação com essa lista. O SPF verifica precisamente o MAIL FROM, também chamado Return-Path, o endereço técnico dos rebounds e das NDR, e não o endereço apresentado no campo “De:” do cliente de email. Esta distinção deixa uma brecha aberta ao spoofing visual.
Os mecanismos que compõem o registo SPF
A sintaxe SPF assenta numa série de mecanismos que, combinados, definem quem tem o direito de enviar. ip4: e ip6: declaram diretamente um intervalo de endereços, sem consultar o DNS uma segunda vez. a e mx verificam que o IP emissor corresponde ao registo A ou aos servidores MX do domínio citado. include: delega a verificação no registo SPF de outro domínio, tipicamente o de um prestador de envio (ESP, CRM, ferramenta de faturação). ptr efetua uma resolução inversa, atualmente desaconselhada pela própria RFC 7208 devido à sua lentidão. exists testa a existência de um registo A construído dinamicamente. O modificador redirect, por sua vez, não se adiciona à lista: substitui inteiramente a avaliação pela de outro registo, um pouco como um redirecionamento HTTP aplicado ao DNS. Cada um destes mecanismos, à exceção de ip4 e ip6, consome um pedido DNS distinto no momento da avaliação. Um include: pode conter, ele próprio, outros include: aninhados, sem que a linha visível o deixe adivinhar. A ordem de escrita também conta: o servidor recetor avalia os mecanismos da esquerda para a direita e para no primeiro que corresponda ao IP emissor. Colocar os servidores internos mais utilizados no início do registo não altera o resultado final: isso só acelera a avaliação em domínios com elevado volume de envio.
Os qualificadores -all, ~all, ?all: o que acontece a um email não conforme
Um registo SPF termina sempre com um qualificador que fixa o destino de um email enviado a partir de um IP ausente da lista. -all (fail strict) pede ao servidor recetor para rejeitar a mensagem. ~all (softfail) pede para a aceitar, mas marcá-la como suspeita, muitas vezes encaminhando-a para o spam. ?all (neutral) não dá nenhuma indicação clara, o que equivale a deixar cada fornecedor de email decidir sozinho. Um último qualificador, +all, autoriza explicitamente qualquer IP a enviar em nome do domínio; só tem utilidade para desativar voluntariamente o SPF em fase de teste, nunca em produção. O Gmail e o Microsoft 365 tratam o softfail com uma tolerância que diminui todos os anos. Um domínio ainda configurado em ~all por precaução acaba muitas vezes por migrar para -all assim que o DKIM e o DMARC estão implementados; sem essa transição, o SPF limita-se a sugerir desconfiança em vez de a decidir.
Um registo SPF comentado linha a linha
Consideremos um exemplo representativo de um domínio que envia simultaneamente a partir dos seus próprios servidores e através de um ESP terceiro:
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net mx -all
v=spf1 declara a versão do protocolo, sempre idêntica. ip4:203.0.113.10 autoriza diretamente o servidor de email interno da empresa, sem custo de lookup. include:_spf.google.com delega a autorização nos servidores do Google Workspace, aqui utilizados para os emails dos colaboradores. include:sendgrid.net faz o mesmo para as campanhas enviadas através do SendGrid. mx adiciona automaticamente os servidores MX do domínio à lista de remetentes válidos. -all fecha o registo em fail strict: qualquer IP ausente desta lista vê a sua mensagem rejeitada. Este registo já consome 3 lookups dos 10 autorizados (os dois include: e o mx), sem contar que cada include: pode, ele próprio, desencadear vários subpedidos uma vez resolvido.
O limite de 10 lookups DNS e o erro PermError
A RFC 7208, secção 4.6.4, fixa dois tetos distintos na avaliação de um registo SPF. O primeiro, o mais conhecido, limita a 10 o número de pedidos DNS desencadeados pelos mecanismos include, a, mx, ptr, exists e pelo modificador redirect; ip4 e ip6 não custam nenhum, uma vez que o endereço já está escrito no registo. O segundo teto, menos documentado, limita a 2 o número de “void lookups” tolerados: um pedido DNS que volta sem resposta (NXDOMAIN), geralmente causado por um include: a apontar para um domínio mal escrito ou um prestador cujo contrato terminou e cujo registo foi eliminado (AutoSPF, março de 2026). Ultrapassar um ou outro limite produz o mesmo veredicto: PermError. O servidor recetor interrompe então a avaliação e trata a autenticação como uma falha, para a totalidade das mensagens do domínio, incluindo as enviadas a partir de um IP perfeitamente legítimo e documentado três linhas acima no registo.
O achatamento SPF, também conhecido por SPF flattening, resolve este excesso substituindo cada include: pela lista bruta dos endereços IP que este designa. A avaliação passa então a custar apenas um lookup, seja qual for o número de prestadores de envio citados inicialmente. Fornecedores especializados em deliverability como a dmarcian ou a PowerDMARC documentam esta técnica e propõem serviços que recalculam o registo a cada alteração de IP do lado do prestador. O processo tem o seu próprio teto: uma cadeia TXT DNS está limitada a 255 caracteres por segmento. Um registo achatado que liste diretamente dezenas de endereços IP acaba por vezes por se aproximar perigosamente desse limite, o que obriga a dividi-lo em várias cadeias concatenadas.
É isto que explica um cenário clássico em equipas de growth: as campanhas acabam no spam, sem que surja qualquer explicação do lado do SaaS de emailing utilizado, que mostra, no entanto, “SPF configurado”. O dashboard verifica a existência e a sintaxe do registo. Nunca recalcula o número de lookups depois de todos os include: resolvidos em cascata. Um domínio que acumulou Google Workspace, um ESP transacional, uma ferramenta de marketing automation e um CRM pode ultrapassar o limite sem que nenhuma destas integrações, isoladamente, pareça ser a causa.
Verificar o registo SPF antes que este falhe
Verificar o registo SPF não requer nenhuma ferramenta paga. O método mais direto decorre em três etapas:
- Consultar o DNS na linha de comandos com
dig txt oseudominio.com(ounslookup -type=txt oseudominio.comno Windows) para ler o registo tal como está realmente publicado, e não tal como foi introduzido na interface do registrar. - Passar este registo por um verificador SPF online que resolve cada
include:aninhado e apresenta a contagem total de lookups, em vez de contar os mecanismos manualmente. - Repetir esta verificação sempre que se adicione um novo serviço de envio (ESP, ferramenta de faturação, plataforma de recrutamento que envia emails a candidatos) e não apenas no momento da configuração inicial.
O Google Postmaster Tools é a ferramenta postmaster do lado do Gmail. O SNDS faz o mesmo do lado da Microsoft, para o acompanhamento da reputação IP. Ambos apresentam um histórico de autenticação. Nenhum dos dois assinala um excesso de lookups antes de este produzir um PermError efetivo num envio real.
O registo duplicado e os erros mais recorrentes
Um domínio deve publicar apenas um único registo SPF. Ter dois, muitas vezes porque uma agência adicionou o seu sem eliminar o que já existia, produz um novo PermError: a RFC 7208 não previu nenhuma fusão automática entre dois registos TXT do tipo SPF. O outro erro recorrente é esquecer um prestador de envio terceiro na lista, uma ferramenta de inquéritos ou uma plataforma de recrutamento que envia emails transacionais em nome do domínio sem nunca ter sido adicionada ao registo. Estas mensagens falham silenciosamente até que um cliente assinale não ter recebido nada.
O reencaminhamento de email faz falhar o SPF: o que faz (e não faz) o SRS
Um email reencaminhado quebra quase sempre o SPF, pela própria construção do protocolo. O servidor que retransmite a mensagem nunca aparece no registo SPF do domínio de origem, pelo que a autenticação falha do lado do destinatário final. O Sender Rewriting Scheme (SRS) corrige este caso específico reescrevendo o endereço MAIL FROM da mensagem com o domínio do servidor de retransmissão, que esse sim está autorizado no seu próprio SPF (documentação Microsoft Learn, setembro de 2025). Este mecanismo tem um ponto cego documentado pela própria Microsoft: o SPF valida então o domínio do relay, enquanto o campo “From” visível para o destinatário continua a apresentar o domínio de origem.
A documentação da Microsoft esclarece isto de forma explícita: o SRS não resolve o caso das mensagens reencaminhadas que falham no DMARC, protocolo que exige um alinhamento entre o domínio validado por SPF (ou DKIM) e o domínio apresentado no campo From.
Uma mensagem pode, assim, passar no SPF graças ao SRS e mesmo assim falhar em DMARC reject, por falta de alinhamento entre os dois domínios verificados.
SPF, DKIM e o alinhamento DMARC: o mecanismo que protege verdadeiramente a reputação
SPF e DKIM não falam da mesma coisa ao servidor recetor. O SPF valida o MAIL FROM, o DKIM assina criptograficamente a totalidade da mensagem. O DMARC acrescenta uma camada que os dois protocolos ignoram sozinhos: o alinhamento, ou seja, a verificação de que o domínio autenticado por SPF ou DKIM corresponde efetivamente ao domínio apresentado no campo “From” lido pelo utilizador. Sem este alinhamento, uma mensagem pode validar o SPF através de um ESP terceiro ao mesmo tempo que apresenta um domínio de remetente totalmente diferente, o que corresponde exatamente ao esquema de um ataque de phishing por usurpação. Este triplo controlo condiciona a taxa de complaint rate e a luta contra o spam e o phishing tanto do lado do Gmail como do Outlook.
Um registo SPF limpo não compensa uma lista cheia de endereços mortos: uma campanha enviada para endereços inexistentes faz disparar a taxa de hard bounce, o que degrada a sender reputation que o SPF e o DKIM supostamente protegem, seja qual for o cuidado colocado na configuração DNS. Verificar a lista antes do envio, uma prática de list hygiene básica, custa menos em reputação do que filtrar a posteriori os Enhanced Status Codes 5.1.1 devolvidos pelos servidores de destino depois de a campanha já ter partido. O DMARC fecha o ciclo: sem ele, SPF e DKIM permanecem duas verificações isoladas, sem ligação garantida ao endereço que o destinatário realmente vê.
Um domínio corretamente autenticado nunca se destaca: não aparece em nenhum relatório de incidentes, precisamente porque ninguém precisa de falar sobre ele.
