O endereço mostrado em Return-Path geralmente difere do endereço que o leitor vê em De. Isso pode ser normal para um serviço de entrega que lida com devoluções em nome de um cliente. Diagnosticar a identidade relevante e pular antes de decidir se a diferença é uma falsificação sinal ou um arranjo de roteamento de rotina.
Distinguir o envelope do conteúdo da mensagem
CORREIO DE fornece o caminho reverso SMTP durante uma transação. O campo De da mensagem identifica seu autor no formato de mensagem da Internet. Na entrega final, o sistema SMTP de entrega insere um campo Return-Path para preservar o caminho inverso. Não é simplesmente outra grafia do endereço visível do autor. Seções 3.3 e 4.4 RFC 5321; Seção 3.6.2 RFC 5322.
Um caminho reverso nulo é legítimo para notificações de entrega e ajuda a evitar loops de notificação. Um Return-Path visível de <> deve, portanto, ser interpretado no contexto real da mensagem, em vez de ser chamado de malformado apenas porque não possui um endereço.
Saiba qual salto a evidência descreve
Um acordo de encaminhamento ou retransmissão pode alterar o envelope usado para uma transação posterior. O Return-Path final armazenado, portanto, não precisa descrever o envelope em cada salto anterior. Obtenha logs de recebimento ou propriedades de autenticação confiáveis quando a questão for o que um determinado receptor avaliou. Não substitua o cabeçalho final da entrega por um envelope histórico sem verificar o roteiro.
SPF verifica uma identidade SMTP de acordo com suas regras. Com um caminho reverso vazio, RFC 7208 constrói a identidade MAIL FROM do postmaster e o HELO domínio; não é necessário um endereço do campo De visível. DMARCo uso de evidências SPF também requer a alinhamento com o domínio De visível. Uma passagem para um domínio de retorno não relacionado não estabelece por si só o sucesso DMARC . Seções 2.3 e 2.4 RFC 7208; RFC 9989.
Compare um cabeçalho editável com evidências de transação
Suponha que uma mensagem colada diga Return-Path : < bounce@service.example >, enquanto uma segunda cópia diga Return-Path : < edited@unrelated.example >. Uma edição de texto por si só não altera um comando MAIL FROM anterior nem prova qual cópia reflete a entrega final. Esses são valores hipotéticos, não um experimento de edição de arquivo executado.
Obtenha a exportação original autorizada e os registros relevantes do sistema de entrega final. Campos Return-Path duplicados inesperados precisam de investigação, não de uma primeira ou última regra arbitrária. A seção 4.4 RFC 5321 descreve a inserção da entrega final e possível remoção/reconstrução no encaminhamento posterior; aplique a rota conhecida em vez de tratar cada campo colado como oficial.
Repare apenas a identidade que está errada
Para um serviço legítimo, confirme o domínio de devolução configurado, sua propriedade, o caminho de envio real e os resultados de autenticação relevantes. Uma diferença no domínio de retorno por si só não justifica a exclusão de uma configuração de fornecedor. Se a rota não for autorizada ou o envelope não corresponder à configuração aprovada, corrija essa configuração específica sob controle de alterações e teste uma mensagem autorizada.
Fechar com o autor visível, identidade do envelope no salto avaliado, proveniência final Return-Path e resultado da autenticação. Mantenha o envio SMTP bem-sucedido, a entrega final e a legitimidade da mensagem como conclusões distintas.
Analise um acordo de serviço legítimo
Suponha que uma marca autorizou um serviço de notificação para lidar com suas rejeições. Nesta transação hipotética, MAIL FROM é bounce@service.example enquanto From é notices@brand.example . Na entrega final, o sistema receptor insere Return-Path do caminho reverso daquela transação. Os diferentes domínios de retorno e autor são consistentes com o acordo de serviço assumido, mas os campos por si só não comprovam a autorização.
Para validar uma configuração real, confirme a propriedade e a configuração do serviço e, em seguida, examine os resultados confiáveis para o salto de recebimento relevante. A passagem SPF para service.example por si só não se alinha com brand.example neste exemplo. Um válido Assinatura DKIM usar d=brand.example pode fornecer um caminho alinhado, assumindo uma política DMARC aplicável e nenhum erro de avaliação não resolvido. Nenhum teste DNS , assinatura ou entrega foi realizado aqui.
Mantenha a avaliação em nível de mensagem separada das obrigações de implantação: RFC 9989 as seções 7.4 e 8 exigem publicação de domínios p=reject não confiar apenas no SPF e aplicar medidas válidas DKIM assinaturas. Editar o texto Return-Path não é uma maneira de atender a esses requisitos.
Diagnosticar uma diferença de domínio de retorno
- Identifique From separadamente de MAIL FROM no salto de recebimento avaliado.
- Estabeleça quem inseriu o Return-Path final e se o encaminhamento posterior alterou o envelope.
- Confirme o serviço aprovado e a configuração do domínio devolvido.
- Inspecione SPF confiável e evidências DKIM / DMARC alinhadas sem derivá-las do cabeçalho texto sozinho.
- Repare apenas um defeito de configuração comprovado e preserve a evidência original.