O que é a sintaxe do registro SPF e como ela afeta os e-mails de aplicação?

Um registro SPF é uma expressão de política ordenada

A RFC 7208 define um registro SPF como uma string DNS TXT cujo primeiro termo é v=spf1. Os demais termos, separados por espaços, são mecanismos, que podem corresponder, e modificadores, que alteram o processamento. A avaliação segue da esquerda para a direita e para no primeiro mecanismo que corresponde; por isso, a ordem expressa a política. Um registro típico pode autorizar duas faixas de endereços fixas, incluir a política de um provedor e terminar com -all. Não cole esse padrão sem alterações: o registro correto depende das identidades SMTP MAIL FROM ou HELO exatas e das fontes de envio reais. Faça primeiro o inventário dos provedores da aplicação, servidores de e-mail, ferramentas de suporte, plataformas de identidade, sistemas de marketing, caminhos de encaminhamento e remetentes de recuperação de desastres. Publique a política no domínio que está sendo avaliado, não automaticamente no domínio From visível. Um único registro sintaticamente válido ainda pode autorizar as fontes erradas, omitir um fluxo de produção ou ultrapassar os limites de avaliação DNS.

Os qualificadores mapeiam a correspondência de um mecanismo para um resultado SPF

Um mecanismo pode começar com um qualificador: + para pass, - para fail, ~ para softfail ou ? para neutral. Se nenhum qualificador aparecer, + fica implícito. O qualificador só se aplica quando aquele mecanismo corresponde. Ele não muda se os termos seguintes são avaliados quando o mecanismo não corresponde. As equipes costumam se concentrar no termo all final, mas cada mecanismo include, de endereço, a, mx ou exists anterior também tem um qualificador e pode encerrar a avaliação. Faça uma revisão explícita, em vez de presumir que ~all significa modo de teste ou que -all comprova que todas as fontes são conhecidas. Um resultado fail é uma evidência para o receptor sobre a identidade SMTP e o IP avaliados, não um comando universal para apagar o e-mail. Os receptores aplicam a política local. Neutral e softfail não são aprovações de autorização. Registre o resultado pretendido para fontes autorizadas, não autorizadas e temporariamente não resolvidas e verifique-o com fixtures controladas de IP e identidade.

Mecanismos de endereço são diretos, mas exigem responsabilidade

Os mecanismos ip4 e ip6 autorizam faixas de rede correspondentes, expressas com a sintaxe específica de cada protocolo e um comprimento de prefixo opcional. Eles evitam consultas adicionais de endereço durante a avaliação, mas podem ficar desatualizados quando as redes de saída mudam. Use endereços de envio públicos, nunca endereços privados do runtime, e mantenha as faixas tão restritas quanto o failover operacional permitir. Cada faixa deve ter um responsável, sistema de origem, ambiente, procedimento de mudança e data de revisão. O mecanismo a resolve um nome A ou AAAA e, por padrão, usa o domínio SPF atual, a menos que outro domain-spec seja informado. O mecanismo mx resolve os hosts MX e seus endereços. Esses mecanismos adicionam trabalho de DNS e podem autorizar infraestrutura que muda fora do ciclo de releases da aplicação. Não use a ou mx como atalho, a menos que todos os endereços resolvidos tenham permissão intencional para enviar com aquela identidade SMTP exata. Monitore as mudanças e teste os caminhos IPv4 e IPv6.

O include avalia outra política, não um trecho de texto

O mecanismo include avalia a política SPF do domínio referenciado e corresponde quando essa avaliação aninhada retorna pass. Ele não cola mecanicamente os termos na string atual, e os demais resultados aninhados têm efeitos definidos. Use include somente quando a organização referenciada documentar explicitamente aquele domínio para a sua relação de envio. O domínio do site, o domínio MX ou o domínio From visível de um provedor não é automaticamente o seu include de SPF. Includes criam dependências operacionais: uma mudança no registro do provedor pode alterar a autorização, adicionar consultas DNS aninhadas ou gerar erros temporários e permanentes. Registre o fornecedor, o serviço, o domínio exato do include, a fonte contratual, o responsável e o plano de remoção. Teste a política resultante a partir do IP de envio real do provedor e do seu domínio de envelope. Nunca achate os includes de provedores em listas de IPs copiadas, a menos que você também assuma a responsabilidade de acompanhar cada mudança de endereço do provedor e preservar a semântica original.

all, redirect e explicação têm papéis diferentes

O mecanismo all sempre corresponde e normalmente fica por último; os termos depois dele não afetam a avaliação. Seu qualificador determina o resultado para as fontes que não corresponderam antes. O modificador redirect diz ao SPF para usar a política de outro domínio quando nenhum mecanismo do registro atual correspondeu. Redirect não é o mesmo que include: include é um mecanismo ordenado, enquanto redirect substitui a decisão final da política sob as condições definidas. Um registro não deve conter vários modificadores redirect. O modificador exp pode referenciar uma explicação para um resultado fail, mas não autoriza e-mails e cria considerações operacionais e de privacidade adicionais. Mantenha as explicações genéricas e evite dados de remetentes ou destinatários. Escolha redirect quando domínios compartilham intencionalmente uma política inteira e têm responsabilidade coordenada. Escolha include ao adicionar as fontes autorizadas de um provedor dentro de uma política local mais ampla. Teste os caminhos sem correspondência, não apenas os pass esperados.

Evite o ptr e trate exists e macros como recursos avançados

A RFC 7208 diz que o mecanismo ptr não deve ser usado, porque é lento, pouco confiável e sobrecarrega os servidores. Não adicione ptr para fazer um IP desconhecido passar. O mecanismo exists pode executar um teste de existência no DNS usando um domain-spec, e as macros do SPF podem expandir componentes de identidade e de conexão dentro dos campos suportados. Essas ferramentas conseguem expressar autorização delegada ou por cliente, mas aumentam a complexidade, o trabalho de DNS, a exposição de privacidade e os modos de falha. A sintaxe de macros não é um template de strings arbitrário; apenas letras, transformadores, delimitadores e contextos definidos são válidos. Nunca coloque endereços completos de destinatários, segredos ou entradas de tenants sem limite em consultas DNS. Se um conjunto simples de faixas de IP próprias e includes de provedores documentados consegue expressar a política, prefira-o. Para políticas avançadas, construa fixtures determinísticas para vários domínios, remetentes, famílias de IP, caminhos reversos nulos, escape de macros, NXDOMAIN, timeouts e respostas DNS inesperadas antes da produção.

Respeite o limite de dez consultas DNS

A RFC 7208 limita as implementações de SPF a dez termos que geram consultas DNS durante uma verificação, incluindo o processamento relevante de include, a, mx, ptr, exists e redirect. Includes aninhados contam. A especificação também recomenda limitar a duas as consultas vazias (void lookups), em que o DNS retorna uma resposta vazia ou erro de nome. Ultrapassar os limites de processamento pode gerar um erro permanente em vez de um pass. Conte o grafo de avaliação expandido, não apenas os termos visíveis na string TXT de primeiro nível. Um único include de provedor pode trazer várias dependências aninhadas, e um mecanismo mx pode disparar consultas de endereço para vários hosts. Use um avaliador alinhado aos padrões com fixtures de DNS capturadas, mas inspecione também a árvore de dependências por conta própria. Remova provedores não usados e mecanismos redundantes. Evite achatamentos inseguros que percam silenciosamente as atualizações dos provedores. Monitore mudanças de política e deixe folga no orçamento de consultas para a evolução dos provedores, em vez de implantar exatamente no máximo.

Publique exatamente uma política SPF por domínio

A RFC 7208 usa registros DNS TXT para o SPF e exige a seleção do registro que começa com v=spf1. Vários registros SPF no mesmo nome exato causam um erro permanente, em vez de combinar as autorizações. Modifique a política existente com responsabilidade coordenada; não adicione um segundo registro TXT porque outra aplicação precisa de acesso. Outros registros TXT não relacionados podem coexistir no mesmo nome, mas só deve existir uma política SPF selecionada. Confirme o comportamento de aspas e divisão de strings do painel de DNS, consulte os servidores autoritativos e depois resolvedores recursivos independentes. Preserve o valor anterior e o TTL para rollback. A propagação do DNS não é instantânea, e caches negativos podem persistir. Uma verificação verde em um painel comprova apenas a consulta observada e o comportamento do parser dele. Verifique o domínio de envelope de produção exato a partir dos cabeçalhos brutos recebidos e dos logs do provedor, incluindo subdomínios e endereços de bounce que podem publicar políticas separadas.

Relacione a sintaxe do SPF ao DMARC sem confundi-los

O SPF normalmente avalia o domínio MAIL FROM ou a identidade HELO segundo as regras do protocolo. O DMARC usa o domínio From visível da RFC 5322 e aceita o SPF como um dos caminhos somente quando o domínio autenticado pelo SPF está alinhado a esse domínio visível. Por isso, o return path de um provedor pode passar no SPF e continuar sem alinhamento para o DMARC. Por outro lado, um pass de DKIM alinhado pode satisfazer o DMARC quando o SPF falha ou não está alinhado. Registre separadamente o resultado do SPF, o domínio avaliado, o IP de conexão, o From visível, os resultados do DKIM, o alinhamento e o resultado do DMARC. O encaminhamento costuma mudar o IP de conexão e pode quebrar o SPF mesmo quando o remetente original estava autorizado. Não amplie o SPF para incluir encaminhadores arbitrários. Use o DKIM e, quando apropriado, mecanismos de cadeia autenticada e evidências do receptor. Um pass de SPF não comprova a integridade da mensagem, a segurança do conteúdo, o consentimento do destinatário, a aceitação pelo servidor nem a chegada à caixa de entrada.

Valide as mudanças com um fluxo determinístico

Antes de editar o DNS, exporte o registro atual e enumere cada mecanismo ou modificador com seu responsável e propósito. Faça o parsing do candidato segundo a gramática da RFC 7208, expanda as dependências DNS a partir de snapshots controlados, conte os termos que geram consultas e teste fixtures IPv4 e IPv6 autorizadas e não autorizadas. Verifique o comportamento de includes aninhados com pass, fail, neutral, softfail, erro temporário e erro permanente. Teste o tratamento de caminho reverso nulo via HELO, subdomínios, return paths de provedores e uma fonte que deveria cair no all. Publique pelos controles de mudança normais, consulte o DNS autoritativo e o recursivo e depois envie mensagens controladas por todos os fluxos reais. Guarde o Authentication-Results bruto de receptores confiáveis e compare-o com as identidades esperadas. Faça rollback em caso de fontes de produção ausentes, seleção de vários registros, erros de limite de consultas, temperror generalizado ou autorização não intencional. Nunca teste enviando e-mails não solicitados.

Configure SPF com o SendHQ

O SendHQ provisiona uma política SPF TXT como parte da configuração da identidade do remetente. Ele interrompe a configuração diante de políticas SPF conflitantes e informa um valor SPF mesclado recomendado em vez de sobrescrever silenciosamente uma política não relacionada. Mantenha exatamente uma política SPF selecionável; consulte a documentação de Domínios e DNS para detalhes de configuração e correção.

Perguntas frequentes

Fontes

• RFC 7208: Sender Policy Framework — RFC Editor (em inglês)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor (em inglês)
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor (em inglês)