Por que o seu registro SPF continua falhando (e como corrigir)

O que o SPF realmente verifica

SPF — Sender Policy Framework — é um registro TXT no seu domínio que lista quais servidores podem enviar e-mail em seu nome. O servidor que recebe consulta esse registro, compara com o endereço IP que acabou de se conectar e decide se a conexão está autorizada.

Dois detalhes sobre o que ele compara explicam quase toda a confusão com SPF:

• O SPF verifica o remetente do envelope, não o endereço From: que o seu destinatário vê. O remetente do envelope (o MAIL FROM da conversa SMTP, também chamado de caminho de retorno) é invisível no cliente de e-mail. Uma mensagem pode passar no SPF enquanto exibe um endereço From: completamente diferente e falsificado — e é por isso que o SPF sozinho não impede falsificação.
• O SPF verifica o IP que se conecta, e nada mais. Ele não inspeciona a mensagem, nem os cabeçalhos, nem o conteúdo. É uma única pergunta: este IP tinha permissão para se conectar em seu nome?

Então uma falha de SPF quase nunca significa que o seu registro está mal formado. Normalmente significa que o e-mail saiu de algum lugar que o registro não lista, ou que o registro não pôde ser avaliado por completo. São problemas diferentes com correções diferentes, e o resto deste guia os separa.

Como ler o seu próprio registro SPF

Um registro SPF é uma única linha de TXT, e dá para ler sem dificuldade quando você conhece as quatro partes.

Mecanismos: quem tem permissão

Cada termo adiciona remetentes permitidos. ip4: e ip6: listam endereços ou faixas diretamente. a autoriza aquilo para onde o registro A do seu domínio aponta. mx autoriza os seus próprios servidores de e-mail. include: é o que mais importa na prática: ele traz o registro SPF inteiro de outro domínio, e é assim que você autoriza Google, Microsoft ou um disparador em massa sem conhecer os endereços deles.

include: é uma delegação, não uma cópia. A outra parte pode mudar a lista dela a qualquer momento e o seu registro acompanha — o que é o objetivo, e também o motivo de o seu registro poder quebrar sem você ter tocado nele.

Qualificadores: o que acontece quando casa

Cada mecanismo pode levar um prefixo. + é pass e é o padrão, então um mx solto significa +mx. - é falha dura: rejeitar. ~ é falha suave: aceitar, mas marcar. ? é neutro: sem opinião, o que equivale a não ter política nenhuma.

O all do final

O último termo é quase sempre um mecanismo all, e ele decide o que acontece com todo remetente que o registro não listou. -all diz para rejeitar todo o resto. ~all diz para aceitar marcando. +all autoriza a internet inteira e é sempre um erro.

Comece em ~all enquanto ainda está descobrindo quem envia legitimamente por você, e aperte para -all quando os seus relatórios DMARC estiverem limpos. Ir direto para -all sem essa evidência é como um sistema de faturamento esquecido ou um suporte deixa de chegar a qualquer pessoa.

Exatamente um registro, sem exceções

Um domínio pode publicar um registro SPF. Dois registros TXT começando com v=spf1 são um permerror, e um permerror significa que a verificação não pode ser avaliada de jeito nenhum — em um receptor estrito isso é pior que uma falha simples. Isso acontece sem parar: o assistente de configuração de um provedor novo adiciona o registro dele em vez de editar o seu. Juntar os dois significa um registro com os dois conjuntos de mecanismos, não dois registros.

O limite de dez consultas, o assassino silencioso

É a causa mais comum de um registro SPF que parece perfeito e falha de qualquer forma.

A especificação limita a avaliação de SPF a dez consultas DNS. Cada include:, a, mx, ptr e exists: custa uma — e as consultas dentro de cada registro incluído também contam. Um include: que por sua vez contém três includes custa quatro das suas dez. Passar do limite dá permerror: não uma falha, mas um registro inavaliável, que muitos receptores tratam como não autenticado.

O que torna isso tão ruim é que é invisível e cresce sozinho. O seu registro passava quando você o escreveu. Meses depois, um dos seus provedores adicionou um include: ao registro dele, o seu total passou de dez, e o seu e-mail começou a ser marcado sem nada ter mudado do seu lado. ip4: e ip6: custam zero consultas, e é aí que está a sua principal alavanca.

Conte as suas antes de dar o registro por bom. Consulte o registro TXT do seu domínio, depois o registro de cada domínio incluído, e siga até não restar nada para expandir. Uma ferramenta de consulta DNS deixa isso rápido: consulte o registro TXT e então siga cada include: um por um.

Por que o e-mail falha quando o registro parece certo

Se o registro é sintaticamente válido e está dentro do limite de consultas, passe por esta lista em ordem.

• Algo envia a partir de um serviço não listado. Os suspeitos de sempre são um CRM, um sistema de faturamento ou de tickets, uma plataforma de marketing, uma ferramenta de monitoramento, ou um servidor de aplicação enviando pelo agente local dele. Cada um precisa de um include: ou da faixa de IP.
• O remetente do envelope é outro domínio. Uma plataforma que envia “em nome de” você costuma usar o próprio caminho de retorno, então o SPF é verificado contra o domínio dela e passa, enquanto o seu alinhamento DMARC continua falhando. A mensagem pode estar autenticada e desalinhada ao mesmo tempo.
• Um subdomínio sem registro próprio. O SPF não é herdado. E-mail de mail.example.com é verificado contra esse nome exato, e sem registro TXT o resultado é none, não a sua política do ápice. Publique um registro por subdomínio que envia, e um v=spf1 -all vazio nos subdomínios que nunca deveriam enviar.
• O registro mudou e os caches não acompanharam. O seu registro TXT carrega uma TTL como qualquer outro, então uma correção não está ativa em todo lugar no instante em que você salva — como a TTL e a propagação funcionam explica os prazos.
• Um include: obsoleto. Um provedor que você parou de usar e cujo domínio não resolve mais pode produzir um permerror, e não é do interesse de ninguém avisar você.

Encaminhamento quebra o SPF, por projeto

Esta não é culpa sua e não pode ser corrigida no seu registro, então vale entender antes de gastar um dia nisso.

Quando um destinatário encaminha a sua mensagem — um alias de universidade, uma regra .forward, uma lista de e-mails — o servidor que encaminha se conecta ao destino final usando o próprio endereço IP e mantém o seu domínio como remetente do envelope. O receptor verifica o seu registro SPF contra um IP de que você nunca ouviu falar, e falha. Com razão: aquele IP realmente não é autorizado por você.

Existem duas mitigações, e nenhuma é uma mudança no SPF. O DKIM assina a mensagem criptograficamente e sobrevive ao encaminhamento, então uma mensagem encaminhada que falha no SPF ainda pode passar no DKIM e, portanto, no DMARC — que é a principal razão para usar os dois. O SRS (Sender Rewriting Scheme) é tarefa de quem encaminha: ele reescreve o remetente do envelope para o próprio domínio, de modo que o SPF seja verificado contra ele. Você não consegue obrigar um encaminhador remoto a fazer isso.

A conclusão prática: nunca diagnostique SPF a partir de uma cópia encaminhada, e não vá para -all supondo que toda falha que você vê é um atacante.

SPF passar não é DMARC passar

Um resultado pass nos cabeçalhos enquanto o DMARC continua falhando confunde quase todo mundo, e o motivo é o alinhamento.

O SPF autentica o remetente do envelope. O DMARC exige, além disso, que o domínio autenticado coincida com o domínio From: visível. Uma plataforma que envia com o próprio caminho de retorno pode te dar um pass de SPF impecável no domínio dela, o que não faz nada pelo seu domínio From:: a verificação de SPF passou, a de alinhamento não, e o DMARC falha com base nisso.

Então o SPF nunca foi uma defesa contra falsificação: um atacante pode publicar um SPF perfeitamente válido para o próprio domínio e ainda assim colocar o seu nome no campo From:. O DMARC é o que amarra a autenticação ao endereço que o destinatário realmente vê, e é também o que envia os relatórios que dizem quem está enviando como você. O guia de SPF, DKIM e DMARC explica como os três se encaixam e como implantar uma política.

Como corrigir um registro que falha

Nesta ordem, porque cada passo remove causas que os seguintes esconderiam.

• Confirme que existe exatamente um registro. Consulte os seus registros TXT e conte quantos começam com v=spf1. Mais de um é permerror — junte os mecanismos em um registro único antes de investigar qualquer outra coisa.
• Conte as consultas, incluindo as aninhadas. Se você está em dez ou perto, troque o include: mais pesado pelas faixas ip4: para as quais ele resolve, e remova includes de provedores que você não usa mais. Tirar um único include abandonado costuma trazer tudo de volta para baixo do limite.
• Levante quem realmente envia por você. Os relatórios agregados do DMARC são a única fonte confiável aqui: eles listam cada IP que envia como o seu domínio, inclusive os sistemas de que ninguém se lembra. Adivinhar produz um registro incompleto.
• Elimine ptr por completo. É obsoleto, lento, pouco confiável, e alguns receptores ignoram registros que o usam.
• Fique em ~all até os relatórios estarem limpos, e então vá para -all. Uma falha dura sobre um registro incompleto faz o seu próprio e-mail voltar.
• Reduza a TTL antes de editar, e verifique de fora. Confira o registro TXT no ar com uma ferramenta de consulta DNS em vez de confiar no seu painel, e confira de novo depois de a TTL antiga expirar.

Erros comuns

• Dois registros SPF porque o assistente de um provedor adicionou o dele. Permerror, e pior que uma falha.
• Passar de dez consultas e nunca descobrir, porque a falha é um permerror nos logs de outra pessoa.
• Pular para -all antes de conhecer todo remetente legítimo. O sistema que você esqueceu normalmente é o que fatura os seus clientes.
• Esperar que subdomínios herdem. Não herdam. Publique um registro por subdomínio que envia.
• Usar ptr, ou +all, que autoriza todo mundo.
• Diagnosticar por uma mensagem encaminhada. O encaminhamento falha no SPF legitimamente e não diz nada sobre o seu registro.
• Supor que um pass de SPF significa DMARC passando. Sem alinhamento com o domínio From: visível, não significa.
• Editar o registro e testar na hora. O registro TXT antigo continua em cache por toda a duração da TTL dele.

Versão curta

O SPF compara o IP que se conecta com um registro TXT e verifica o remetente invisível do envelope, não o endereço From: que o seu destinatário lê. Publique exatamente um registro, mantenha o total de consultas DNS — incluindo as aninhadas dentro de cada include: — em dez ou menos, liste todo serviço que envia legitimamente por você, dê a cada subdomínio que envia o seu próprio registro, e fique em ~all até os seus relatórios DMARC provarem que a lista está completa. E-mail encaminhado vai falhar no SPF não importa o que você faça, e é por isso que DKIM e DMARC existem ao lado dele. Leia o registro TXT no ar de qualquer domínio, expanda cada include: e veja a TTL restante com a ferramenta gratuita de consulta DNS.

Ferramentas e guias relacionados:

• Consulta de DNS — Consulte registros A, AAAA, MX, TXT, NS e mais, com valores e TTL, além de DNS reverso.
• Como ler um relatório DMARC sem se afogar em XML — O que há em um relatório agregado de DMARC

Perguntas frequentes