Um polido phishing mensagem pode ser persuasiva, mas seu estilo de escrita não altera o DMARC condição de passe. Investigue as identidades de domínio e as evidências de autenticação antes de decidir qual controle falhou. Você não precisa provar que a IA escreveu o texto para impedir uma solicitação comercial não autorizada.
Avalie identificadores, não prosa
DMARC compara o domínio do autor com domínios autenticados através SPF ou DKIM. É necessário pelo menos um caminho alinhado e de passagem para uma passagem. A escolha das palavras, a gramática, a urgência e se um modelo ajudou a redigir a mensagem não são entradas para esse teste de identificador. RFC 9989.
Isso não significa que o corpo nunca possa afetar a autenticação. DKIM assina um corpo canônico e cabeçalhos selecionados. Editar uma mensagem assinada pode invalidar sua assinatura. A distinção está entre alterar bytes após a assinatura e produzir texto refinado antes de uma assinatura válida ser criada. RFC 6376. Um julgamento semântico sobre se a prosa parece escrita por máquina não é nenhuma das duas operações.
Separe três caminhos de abuso
Propriedade de um invasor domínio semelhante pode se autenticar enquanto se faz passar por uma empresa no texto de exibição. Uma conta legítima comprometida pode usar uma rota de envio alinhada. Uma mensagem reivindicando seu domínio exato sem um caminho de autenticação alinhado pode falhar DMARC . Estes casos exigem investigações técnicas diferentes, mesmo quando o pedido de pagamento é idêntico.
Use resultados de receptor confiável em vez de declarações fornecidas pelo remetente. Mantenha o autor, o envelope e os domínios de assinatura reais visíveis no registro do caso. A equipe antifraude também deve preservar a solicitação comercial, a alteração solicitada e o status de verificação independente. A autenticação não estabelece que uma pessoa pretendia ou aprovou uma transferência.
Compare suposições de identificador fixo
Para cada caso escrito, assuma um único campo De visível válido e uma avaliação DMARC elegível. Compare etiquetas simples e polidas sem alterar nenhuma entrada de autenticação.
- Caso A: De alerts@brand.test ; Passe SPF para CORREIO DE bounce@brand.test ; não Assinatura DKIM. DMARC passa sob ambos os rótulos de estilo por meio SPF alinhado.
- Caso B: De alerts@brand.test ; Passe SPF para bounce@other.test ; DKIM passa com d=other.test; suponha que other.test não esteja alinhado com brand.test. Nenhum dos identificadores autenticados se alinha, então DMARC falha em qualquer um dos rótulos.
- Caso C: De billing@lookalike.test ; Passe SPF para bounce@lookalike.test ; sem assinatura DKIM . DMARC é aprovado para lookalike.test em ambos os rótulos, não para a empresa ser representada no texto de exibição.
Estas são deduções narrativas de resultados estipulados, não seis chamadas de função executadas, testes de servidor de correio ou um benchmark de IA. Nenhum modelo gerou a prosa ou detector a classificou. Uma passagem SPF em nível de mensagem não é um endosso à implantação somente de SPF: a seção 7.4 RFC9989 requer DKIM válido para p=reject domínios.
Verifique a ação comercial de forma independente
Para uma solicitação de alteração de pagamento, entre em contato com o fornecedor por meio de um canal estabelecido e de origem independente e aplique o processo normal de aprovação. Não utilize um número de telefone fornecido apenas pela mensagem suspeita. O FBI recomenda verificar de forma independente as alterações de pagamento e conta. Orientação sobre comprometimento de e-mail comercial do FBI.
O cenário de negócios hipotético estipula domain_pass=true, masknown_contact_confirmed=false e second_approval=false, portanto a regra de pagamento proposta manteria a solicitação. Esses campos de verificação são inventados, não um retorno de chamada completo. Registre a verificação real autorizada antes de liberar fundos. Concentre a resposta na ação arriscada e na autoridade comprometida, em vez de esperar por uma atribuição incerta a um sistema de IA.