Um sistema de correio pode relatar SPF passar e DKIM passe enquanto DMARC ainda falha. Esse resultado não é contraditório. Cada mecanismo começa com uma identidade diferente e DMARC adiciona um teste de relacionamento entre uma identidade passante e o domínio no endereço De da mensagem.
A maneira confiável de investigar uma mensagem é registrar a cadeia de identidade antes de alterar DNS . Comece com o domínio que o destinatário vê em De. Em seguida, registre o domínio usado para SPF e todos os domínios encontrados em um Assinatura DKIM. Só depois disso você deve avaliar alinhamento e o resultado DMARC no nível da mensagem.
Nomeie as três identidades antes de ler os resultados
Considere esta mensagem fictícia:
De: Equipe de faturamento < statements@billing.example.com > Return-Path : < bounce+739@mailer.example.net > DKIM-Signature : ... d=billing.example.com; s=outbound1; ...O domínio De é billing.example.com. DMARC o chama de Domínio do Autor. O remetente do envelope é aqui representado pelo Return-Path domínio mailer.example.net; para a verificação MAIL FROM desta mensagem comum, que é a identidade que SPF avalia em RFC 7208 §2.4. Um separado HELO verificação também pode ocorrer sob RFC 7208 §2.3; O tratamento Return-Path é especificado em RFC 5321 §4.4. O domínio de assinatura DKIM é o valor de d=, que é billing.example.com neste exemplo.
Um nome de exibição como Billing Team não é uma identidade de autenticação. Reply-To também não é o domínio do autor. Esses campos podem ser importantes para uma investigação de fraude, mas não substituem os domínios que DMARC compara.
Registre os resultados e o alinhamento separadamente
Uma passagem SPF bruta significa que a fonte de conexão foi autorizada para a identidade SPF que foi avaliada. Um passe DKIM bruto significa uma assinatura verificada quanto à sua d= domínio e o material da mensagem abrangida. Nenhum dos resultados, por si só, diz que seu domínio possui o relacionamento necessário com From.
Portanto, DMARC precisa de duas colunas para cada caminho:
- Caminho: SPF ; Pergunta de autenticação: SPF passou na identidade do envelope avaliado?; Pergunta de alinhamento: Essa identidade está alinhada com o Domínio do Autor?
- Caminho: DKIM ; Pergunta de autenticação: Esta assinatura passou pelo seu domínio d=?; Pergunta de alinhamento: Esse domínio d= está alinhado com o domínio do autor?
Sob RFC 9989 §3.2.10.2, o alinhamento estrito requer igualdade exata de domínio. Sob RFC 9989 §4.10.2, o alinhamento relaxado usa o relacionamento de descoberta de domínio organizacional aplicável. Não se aproxime desse limite usando os dois últimos rótulos, porque as regras de sufixos públicos podem tornar esse atalho errado.
Trabalhe com um passe e um passe bruto enganoso
O que se segue é um exemplo de ensino sintético, não uma mensagem do cliente. Assuma uma política válida aplicável, verificações concluídas, resultados confiáveis de recebimento e modos de alinhamento conhecidos; RFC 9989 §5.3.5 define a regra de aprovação/reprovação resultante.
- Observação: De; Mensagem A: alerts@example.com ; Mensagem B: alerts@example.com
- Observação: resultado SPF ; Mensagem A: Passe para bounce.vendor.example.net ; Mensagem B: Passe para bounce.vendor.example.net
- Observação: SPF alinhado?; Mensagem A: Não; Mensagem B: Não
- Observação: resultado DKIM ; Mensagem A: Passe com d=example.com; Mensagem B: Passe com d=vendor.example.net
- Observação: alinhamento DKIM ?; Mensagem A: Sim; Mensagem B: Não
- Observação: DMARC em nível de mensagem; Mensagem A: Passe pelo DKIM ; Mensagem B: Falha
A mensagem A passa DMARC porque uma assinatura DKIM verifica e alinha. Seu resultado SPF desalinhado não cancela esse caminho válido. A mensagem B tem duas passagens de autenticação brutas, mas nenhum domínio autenticado se alinha com o domínio do autor, portanto, não há caminho DMARC de passagem.
Esta tabela também é um registro de alterações útil. Mostra se o reparo pertence à identidade do envelope, à configuração de assinatura ou ao domínio De visível. Um ícone verde sem esses domínios não é evidência suficiente para autorizar uma alteração DNS .
Inspecione cada assinatura DKIM
Uma mensagem pode conter mais de uma assinatura DKIM . Um serviço de saída, um gateway e um intermediário podem adicionar um, cada um. Avalie cada assinatura de forma independente. Uma assinatura de passagem alinhada pode fornecer o caminho DKIM mesmo quando outra assinatura está desalinhada ou falha.
Não infira o seletor de um nome de provedor. Leia o s= valor do cabeçalho DKIM-Signature real, combine-o com o valor dessa assinatura d= domínio e consulte o nome DNS resultante em RFC 6376 §3.6.2.1. A publicação de uma chave apenas disponibiliza material de verificação. O sistema remetente ainda deve criar uma assinatura válida com a chave privada correspondente.
A correspondência indireta pode alterar o conteúdo assinado ou o caminho do envelope. O encaminhamento pode, portanto, afetar SPF , enquanto as modificações na lista podem afetar DKIM . Trate o caminho observado como evidência a ser investigada, e não como prova de que o remetente original ou intermediário era malicioso.
Use evidências de recebimento confiáveis
Authentication-Results pode resumir as identidades e os resultados, mas a confiança depende de onde o cabeçalho foi adicionado. Um remetente pode inserir um cabeçalho que afirma ter sucesso. Sob RFC 8601 §7.1, use o resultado produzido pelo sistema receptor que você administra ou outro limite cujo tratamento você entende.
Quando a mensagem foi rejeitada antes da entrega, pode não existir uma cópia entregue. Use a resposta de rejeição, os registros do provedor e qualquer telemetria de recebimento disponível. Não invente identidades ausentes apenas com base em um código de erro.
Transforme a cadeia de identidade em um registro operacional
Para cada remetente de material, retenha:
- o proprietário da empresa e o aplicativo;
- os domínios From que está autorizado a usar;
- a identidade do envelope observada;
- cada DKIM d= domínio e seletor observado;
- o resultado da autenticação para cada caminho;
- o modo de alinhamento e conclusão;
- uma data de teste representativa e um identificador de mensagem.
Esse registro separa a autorização comercial da evidência de protocolo. Também evita um erro comum: mudar a raiz da organização Registro SPF para resolver um problema de alinhamento DKIM ou alterar a política DMARC quando a configuração do remetente é o defeito real.
Assim que a cadeia de identidade estiver clara, use o guia de solução de problemas de alinhamento para reparar um caminho com falha e o inventário do remetente para atribuir propriedade.
Mantenha a conclusão dentro das evidências
Para a mensagem A, escreva SPF aprovado/não alinhado e DKIM aprovado/alinhado como fatos separados. Para B, não converta duas passagens brutas não relacionadas em uma passagem DMARC . Retenha cada assinatura de forma independente e não deduza a identidade SMTP apenas do nome de exibição. Estes casos e a assinatura abreviada são exemplos de ensino, não material de assinatura válido ou verificação executada.