Teste SPF requer dois tipos de evidências: o que DNS publica e o que um receptor avaliou para uma mensagem específica. Dig e nslookup ajudam a inspecionar o primeiro. Um confiável Authentication-Results campo ou rastreamento do lado do receptor ajuda a inspecionar o segundo. Mantenha essas observações conectadas pelo mesmo domínio de envelope, enviando rota e janela de tempo.
Comece com o domínio certo
Envie uma mensagem representativa por meio do aplicativo que você está investigando e preserve seus cabeçalhos originais. Identifique a identidade do envelope a partir de evidências de destinatário confiável, usando Return-Path como uma pista, em vez de confundi-lo com o endereço De visível. Para um caminho reverso vazio, o tratamento de identidade do SPF envolve HELO; não assuma que as entradas de mensagens comuns cobrem esse caso. RFC 7208 §2.3 e RFC 7208 §2.4 descreva as identidades.
Anote o IP de envio observado pelo destinatário, a identidade do envelope, o sistema do destinatário e o horário da mensagem. Não carregue cabeçalhos privados completos para um verificador público desconhecido apenas para obter um resultado colorido. Um equipamento mínimo controlado muitas vezes pode responder à questão técnica sem revelar dados de mensagens não relacionados.
Inspecione a resposta TXT publicada
Estes são comandos somente leitura ilustrativos. Substitua o nome do exemplo pelo domínio que está sendo avaliado; eles não são evidências de testes já executados:
cavar TXT bounce.example.com . nslookup - type=TXT bounce.example.com .O Manual de escavação BIND documenta o utilitário de consulta e Referência nslookup da Microsoft descreve opções de consulta. Use um ponto final para um nome de consulta absoluto, evitando expansão não intencional do sufixo de pesquisa. Mantenha a resposta completa ao solucionar problemas, incluindo resolvedor, status, resposta e TTL, quando mostrado. Uma resposta abreviada pode ser conveniente para leitura, mas omite o contexto do diagnóstico.
Inspecione o nome real do proprietário e selecione o valor SPF de não relacionado Registros TXT. Várias sequências de caracteres entre aspas podem pertencer a um registro TXT ; SPF trata essas strings como concatenadas sem inserir espaços. Dois aplicáveis separados Registros SPF são um problema diferente. RFC 7208 §3.2 e RFC 7208 §3.3 definir essa distinção.
Leia um resultado sintético emparelhado
O seguinte é um acessório totalmente sintético, sem correspondência observada ou registro de produção. Suponha que o receptor tenha visto uma conexão direta do endereço de documentação 192.0.2.10 , CORREIO DE invoices@bounce.example.com e visível em invoices@example.com . Sua resposta DNS contém um registro de recurso TXT :
bounce.example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 " " -all "As duas strings dentro desse registro unem-se a v=spf1 ip4:192.0.2.10 -all. O espaço à direita na primeira string separa os mecanismos. Para a conexão indicada, o mecanismo de endereço corresponde e o resultado SPF esperado é aprovado. Um resultado ilustrativo correspondente do receptor é:
Authentication-Results : mx.receiver.example ; spf=pass smtp.mailfrom= bounce.example.comTrate isso como confiável apenas sob a suposição explícita de que mx.receiver.example é o serviço de autenticação confiável do destino. Caso contrário, um remetente poderia inserir um texto semelhante. O exemplo mostra apenas evidências SPF ; não afirma uma DKIM, DMARC ou resultado de entrega.
Compare isso com esta resposta DNS sintética diferente, que contém dois registros aplicáveis separados com o mesmo nome:
bounce.example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 -all " bounce.example.com . 300 IN TXT " v=spf1 ip4:192.0.2.20 -all "A seleção de registros agora retorna permerror em vez de combinar as autorizações. Não diagnostique essa situação contando apenas aspas; preservar os limites do registro de recursos DNS .
Compare resolvedores quando a publicação é contestada
Se o editor DNS e uma consulta recursiva discordarem, identifique o autoritativo servidores de nomes e consulte diretamente um servidor autorizado verificado. Dig suporta o formulário dig @nome do servidor TXT; substitua um servidor verificado real e um nome de destino. Compare a resposta e o carimbo de data/hora com o resultado recursivo. Não presuma que a conta DNS que está sendo editada hospeda a zona delegada.
Uma resposta oficial atual e uma resposta recursiva mais antiga podem indicar armazenamento em cache. Um tempo limite, SERVFAIL e uma resposta bem-sucedida sem nenhum registro aplicável são observações diferentes. Preserve a resposta exata antes de decidir a causa. Evite editar repetidamente um registro correto apenas porque uma observação está obsoleta.
Avalie a mensagem, não apenas a sintaxe
Uma pesquisa TXT não executa SPF . Um avaliador consciente dos padrões precisa do IP da conexão e das identidades SMTP relevantes, além do estado DNS que ele resolve. Inspecione seu rastreamento em busca do mecanismo, dependências e erros correspondentes. Um validador de registro estático pode relatar uma política estruturalmente aceitável sem responder se o remetente real é aprovado.
No destino, leia os Authentication-Results inseridos por um receptor confiável, não uma cópia anterior arbitrária. RFC 8601 torna o limite de confiança importante. Registre o resultado e a identidade SPF juntamente com os resultados DKIM e DMARC sem tratá-los como intercambiáveis.
Mantenha um registro de teste reproduzível
Salve os comandos, os tempos de consulta, as respostas DNS , as entradas do avaliador e as evidências de mensagens recebidas redigidas. Teste cada rota de aplicativo e família de endereços materialmente diferentes em uso. Rotule os acessórios sintéticos separadamente dos resultados observados. Se a visualização DNS parecer correta, mas o receptor discordar, continue com passagem da ferramenta versus falha do destinatário em vez de declarar que o receptor deve estar errado.
Histórico DNS : Seção 3.2.1 RFC 1035 define o TTL do registro de recursos; RFC 2308 §5 cobre cache negativo; RFC 8767 §4 atualiza a semântica do TTL e permite o uso obsoleto quando a atualização autoritativa falha. Eles descrevem o comportamento DNS , não um tempo universal de conclusão para uma alteração.
Registre a próxima decisão
Para o fixture de registro único, mantenha o limite mostrando duas strings dentro de um registro e o espaço de junção; SPF esperado é aprovado para 192.0.2.10 . Para o fixture de dois registros, a seleção falha com permerror antes que os mecanismos sejam avaliados. Salve a suposição de resultado confiável separadamente: o texto impresso Authentication-Results não é confiável de forma independente. Nenhum comando ou verificação de email foi executado aqui.