Como verificar um registro SPF para e-mail de aplicação?

Comece pela identidade que o SPF realmente verifica

Uma verificação SPF precisa de três entradas: o endereço IP do cliente SMTP, o domínio cuja política de autorização está sendo avaliada e a identidade do remetente. No e-mail comum de aplicação, esse domínio vem do endereço SMTP MAIL FROM, também chamado de remetente do envelope ou return path. Ele pode ser diferente do endereço que as pessoas veem no cabeçalho From da mensagem. Se o MAIL FROM estiver vazio, como normalmente acontece em uma notificação de status de entrega, o SPF usa a identidade HELO para a verificação do MAIL FROM. Registre o IP real da conexão e a identidade do envelope a partir de uma mensagem de teste recebida ou da configuração do provedor de envio antes de consultar o DNS. Verificar example.test só porque ele aparece no From é inconclusivo quando a aplicação na verdade envia com MAIL FROM em bounce.provider.test ou bounces.example.test.

Consulte o TXT no domínio exato do MAIL FROM

Consulte o TXT no DNS exatamente no domínio escolhido na primeira etapa. A RFC 7208 exige que políticas SPF versão 1 sejam publicadas como registros TXT no nome de proprietário que elas regem. Ignore valores TXT não relacionados e selecione os registros cuja seção de versão seja exatamente v=spf1. Se nenhum registro for selecionado, o resultado SPF é none. Mais de um registro SPF selecionado produz permerror; publicar registros separados para fornecedores diferentes não é uma forma válida de combiná-los. Um único registro de recurso TXT pode ser dividido em strings entre aspas pelas ferramentas de DNS, mas essas strings são concatenadas sem espaços inseridos antes do parsing do SPF. Guarde a resposta completa, o resolvedor, o horário da consulta e o TTL para que a verificação possa ser repetida após uma mudança.

Valide a sintaxe e avalie os termos da esquerda para a direita

Um registro SPF é uma política ordenada, não uma lista desordenada de provedores. Depois de v=spf1, os mecanismos são avaliados da esquerda para a direita até que um corresponda. Um qualificador no início controla o resultado: + significa pass e é o padrão, - significa fail, ~ significa softfail e ? significa neutral. Os mecanismos ip4 e ip6 comparam o endereço do cliente com um endereço ou uma rede. Os mecanismos a e mx resolvem DNS, enquanto include avalia a política SPF de outro domínio e só corresponde de acordo com as regras de include. exists realiza um teste baseado em DNS. all sempre corresponde e costuma encerrar o registro. Erros de sintaxe em qualquer ponto causam permerror antes da avaliação normal. Um bom verificador deve informar qual mecanismo correspondeu, seu qualificador e cada domínio expandido, em vez de retornar apenas um selo colorido.

Rastreie include e redirect sem tratá-los como aliases

Siga cada include e redirect no mesmo contexto de avaliação. Include é um mecanismo: ele pergunta se a política incluída retorna pass para o cliente e o remetente atuais e, se não corresponder, continua no registro original. Redirect é um modificador considerado depois que nenhum mecanismo do registro atual corresponde; ele transfere a avaliação para outra política, mantendo o IP do cliente e o remetente. Um redirect é ignorado se all aparecer em qualquer parte do registro. Essas diferenças importam durante migrações. Trocar include:vendor.test por redirect=vendor.test pode substituir toda a política de fallback do dono do domínio, em vez de apenas adicionar um fornecedor. Detecte ciclos, alvos ausentes, alvos inválidos e erros aninhados permanentes ou transitórios, e preserve a cadeia de dependências no resultado para que uma mudança de política do lado do provedor fique visível.

Conte o orçamento completo de consultas DNS

Conte os termos que geram consultas DNS em toda a avaliação recursiva, não só no registro de nível superior. A RFC 7208 limita os termos include, a, mx, ptr, exists e redirect a dez em uma única avaliação SPF; ultrapassar o limite exige permerror. Os mecanismos all, ip4 e ip6 não consomem esse orçamento de termos. O processamento de MX e PTR tem limites adicionais de consultas de endereço. A RFC também recomenda limitar as consultas vazias (void lookups), ou seja, respostas bem-sucedidas vazias ou erros de nome, a duas, e produzir permerror quando esse limite for excedido. O mecanismo ptr é desaconselhado porque é lento e pouco confiável. Um registro pode parecer curto enquanto os includes de provedores se expandem em termos aninhados suficientes para falhar; por isso, informe o total, cada termo que contribui para ele, as consultas vazias e o ramo exato seguido para o IP testado.

Interprete o resultado SPF sem exagerar seu significado

Use o vocabulário padrão de resultados. Pass significa que o cliente testado está autorizado a usar a identidade SMTP verificada. Fail significa que foi encontrada uma autorização negativa correspondente. Softfail é uma declaração negativa fraca, enquanto neutral indica que o domínio não faz nenhuma afirmação sobre aquele cliente. None significa que nenhum registro SPF foi selecionado. Temperror reflete um problema transitório na avaliação, geralmente de DNS; permerror reflete uma política que não pode ser avaliada corretamente. Se nenhum mecanismo corresponder e nenhum redirect se aplicar, o resultado é neutral, equivalente a um ?all implícito. Informe o resultado junto com a identidade, o IP do cliente, o termo correspondente, o rastreamento DNS e o horário. Não traduza pass como mensagem segura, e-mail desejado, aceitação pelo provedor, entrega na caixa postal ou chegada à caixa de entrada, porque o SPF não decide esses resultados.

Verifique uma mensagem real, não apenas o registro publicado

Uma verificação estática do registro responde se uma política pode ser descoberta e interpretada. Ela não comprova que a aplicação usou o domínio MAIL FROM ou o IP de saída esperado. Envie uma mensagem controlada por cada caminho real de produção para uma conta de destinatário que você administra e inspecione os cabeçalhos recebidos. Compare o IP de conexão, o remetente do envelope e a entrada Authentication-Results do receptor com a avaliação de DNS. Repita para cada provedor, região, pool dedicado ou compartilhado, caminho de fallback e classe de mensagem que possa alterar o return path. Preserve os cabeçalhos em armazenamento restrito, porque endereços e detalhes de roteamento podem ser sensíveis. Se o painel de um provedor e a mensagem recebida divergirem, a mensagem é a evidência mais forte do caminho que de fato foi executado, mas o resultado de um único receptor ainda não deve ser generalizado como comportamento universal de entrega.

Avalie o alinhamento DMARC como uma etapa separada

O SPF pode passar para um domínio de return path do provedor enquanto o DMARC continua sem poder usar esse resultado. As regras atuais do DMARC comparam o domínio RFC5321.MailFrom autenticado com sucesso pelo SPF com o domínio do autor no campo RFC5322.From visível. O alinhamento strict exige o mesmo domínio DNS. O alinhamento relaxed permite domínios que resolvem para o mesmo domínio organizacional segundo as regras de descoberta do DMARC. Por exemplo, bounces.example.test e example.test podem se alinhar no modo relaxed, mas bounce.provider.test e example.test não. Um resultado DMARC pode, em vez disso, se basear em uma assinatura DKIM verificada e alinhada; portanto, um resultado SPF não alinhado não significa, por si só, que o DMARC falha. Informe a autenticação e o alinhamento de forma independente e use o procedimento atual de descoberta de domínio, em vez de uma comparação fixa dos dois últimos rótulos.

Teste a configuração de MAIL FROM específica do provedor

A configuração do provedor determina qual identidade SPF aparece na transmissão. O Amazon SES, por exemplo, documenta um domínio MAIL FROM personalizado que precisa de seu próprio registro MX e registro SPF TXT. O SES pode recorrer a um domínio MAIL FROM amazonses.com que depende da região quando o MX do domínio personalizado está mal configurado, ou pode rejeitar o envio, conforme o comportamento configurado. Esse fallback pode alterar o alinhamento DMARC mesmo quando o endereço From visível não muda. Para qualquer provedor, registre o domínio de return path configurado, os valores DNS exigidos, o comportamento de fallback, as regiões de envio e os responsáveis. Após uma mudança de DNS ou de provedor, espere as respostas em cache relevantes expirarem e então repita a avaliação de DNS e os envios controlados. Não copie o include de um fornecedor para o domínio do From visível, a menos que essa seja a identidade real e o inventário completo de remetentes do domínio justifique isso.

Use uma auditoria SPF reproduzível durante mudanças

Mantenha uma linha por caminho de envio com responsável, aplicação, classe de mensagem, domínio do From visível, domínio MAIL FROM, domínio HELO, faixas de origem esperadas, dependência de provedor e horário do último teste controlado. Armazene cada verificação SPF com o registro selecionado, o rastreamento recursivo, a contagem de consultas DNS, o mecanismo correspondente, o resultado, a decisão de alinhamento e um identificador de teste não sensível. Durante uma migração, mantenha as origens legítimas antigas e novas autorizadas apenas pela janela de transição necessária, verifique o novo caminho e depois remova deliberadamente a autorização obsoleta. Monitore erros de autenticação permanentes e transitórios, em vez de reagir apenas a rejeições. Execute a auditoria novamente após mudanças de provedor, trocas de pool de IP, mudanças de domínio, edições de DNS ou novas aplicações. Esse fluxo detecta tanto políticas restritas demais, que bloqueiam caminhos legítimos, quanto políticas amplas demais, que mantêm autorizações sem uso.

Verifique o SendHQ usando o mesmo padrão de evidência

O SendHQ documenta que um envio direto deve usar um endereço em um domínio de workspace verificado. Isso verifica a identidade do remetente, mas não substitui uma avaliação de SPF. Uma mensagem controlada do SendHQ ainda precisa do mesmo rastreamento de DNS, inspeção do cabeçalho recebido, resultado de SPF e verificação de alinhamento DMARC descritos acima.

Perguntas frequentes

Fontes

• RFC 7208: Sender Policy Framework — IETF (em inglês)
• RFC 5321: Simple Mail Transfer Protocol — IETF (em inglês)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — RFC Editor (em inglês)
• Using a custom MAIL FROM domain in Amazon SES — Amazon Web Services (em inglês)
• Contrato OpenAPI do SendHQ — SendHQ