Guia de Operações de Segurança para autenticação por e-mail no Microsoft 365

A autenticação de email no Microsoft 365 é um componente crítico para proteger a comunicação em sua organização. Quando um e-mail é recebido no Microsoft 365, o serviço adiciona um cabeçalho Authentication-Results . Este cabeçalho mostra os resultados de várias verificações de autenticação de e-mail, incluindo SPF, DKIM, DMARC e autenticação composta (compautação).

Este guia explica cenários comuns que poderá encontrar com estes resultados:

  • Por que uma mensagem foi aprovada ou reprovada na autenticação de email.
  • Se a origem do e-mail ou o destino do e-mail é responsável pelo resultado.
  • Que ações (se existirem) recomendamos para melhorar os resultados da autenticação de e-mail.

Mas, primeiro, aqui estão algumas definições principais:

Acrônimo Descrição
Configurar o SPF Estrutura de Política do Remetente. Identifica as origens de e-mail de um domínio para ajudar a impedir o spoofing.
Configurar o DKIM DomainKeys Identificado Correio. Assina digitalmente elementos importantes de uma mensagem (incluindo o cabeçalho de endereço "De") para verificar se a mensagem não foi alterada em trânsito, o que ajuda a impedir a falsificação.
Usar DMARC para validar emails Autenticação de Mensagens baseada em domínio, Relatórios e Conformidade. Utiliza os resultados de SPF e DKIM para verificar o alinhamento entre os domínios no endereço MAIL FROM e no endereço From, ajudando a evitar falsificação.
Configurar seladores ARC confiáveis Cadeia de Recebimento Autenticada. Preserve os resultados da autenticação de e-mail entre intermediários que modificam mensagens em trânsito.
Autenticação composta (compauth) Autenticação composta. Uma tecnologia proprietária do Microsoft 365 que combina vários sinais de autenticação de e-mail.
Endereço de MAIL FROM Também conhecido como o endereço 5321.MailFrom, o remetente P1 ou o remetente do envelope. Utilizado na transmissão de mensagens entre servidores de e-mail SMTP. Normalmente, é registrado no campo de cabeçalho Return-Path no cabeçalho da mensagem. Utilizado como endereço para relatórios de não entrega (também conhecidos como NDRs ou mensagens de devolução).
Endereço do remetente Também conhecido como endereço 5322.From ou remetente P2. O endereço de e-mail no campo de cabeçalho De. Mostrado como o endereço de e-mail do remetente nos clientes de e-mail.

Cenários de aprovação na autenticação de e-mail

Estes cenários descrevem mensagens que passaram por verificações de autenticação de e-mail ou foram aceites (por vezes devido a configurações específicas). Em geral, quando a autenticação de e-mail é aprovada, não é necessária nenhuma ação corretiva. No entanto, alguns cenários incluem notas de precaução onde recomendamos melhorias de configuração para melhorar a segurança.

O remetente refere-se aos administradores na organização de origem. O destinatário refere-se aos administradores na organização de destino.

Todas as verificações de autenticação foram aprovadas

Esse cenário se aplica quando todas as verificações de autenticação de email padrão são aprovadas com êxito.

  • Exemplo de cabeçalho: dmarc=pass (e, normalmente spf=pass , e dkim=pass).
  • O que significa: todas as verificações de autenticação de e-mail (SPF, DKIM e DMARC) foram bem-sucedidas. Este resultado indica que a mensagem está totalmente autenticada de acordo com os protocolos de autenticação de e-mail padrão.
  • Quem é o responsável: o remetente.
  • Ação recomendada: Nenhuma. A autenticação de e-mail está corretamente configurada e funcionando como esperado. O destinatário pode confiar no domínio do remetente autenticado corretamente nesta mensagem.

Autenticação composta aprovada

Este cenário descreve como Microsoft 365 pode aceitar uma mensagem por meio da autenticação composta.

  • Exemplo de cabeçalho: compauth=pass (passe de autenticação composta).

  • O que significa: A mensagem foi aprovada na autenticação composta do Microsoft 365:

    • Os requisitos de DMARC foram cumpridos: SPF ou DKIM transmitidos e os endereços MAIL FROM e From estão alinhados.

      Ou

    • A lógica de confiança implícita da Microsoft identificou a mensagem como legítima. Por exemplo, uma mensagem pode ser aprovada na autenticação composta com base no histórico de remetentes seguros da Microsoft ou na inteligência contra falsificação, que indica que o remetente é confiável.

  • Quem é o responsável: o remetente.

  • Ação recomendada: Nenhuma. As verificações de autenticação foram efetuada com êxito e o sistema não detetou problemas. Não são necessárias alterações ao SPF ou ao DKIM neste cenário.

DMARC aprovado sem política DMARC (sem registro DMARC)

Esse cenário abrange mensagens que parecem passar DMARC mesmo que o remetente não tenha publicado um registro DMARC.

  • Exemplo de cabeçalho: dmarc=bestguesspass action=none
  • O que significa: a mensagem passou dMARC por predefinição porque o domínio do remetente não tem nenhum registo DMARC publicado. Quando um domínio não tem uma política DMARC, os servidores de e-mail de destino não podem falhar a mensagem no DMARC. Na prática, a verificação DMARC não se aplica. DMARC=bestguesspass action=nonesignifica que, se o domínio tivesse um registro DMARC válido, a verificação de DMARC da mensagem seria aprovada.
  • Quem é o responsável: o remetente.
  • Ação recomendada: o remetente deve publicar um registo DMARC para o respetivo domínio. Embora a mensagem tenha sido aceite, a ausência de uma política DMARC não é um bom sinal. Recomendamos que o proprietário do domínio configure um registo TXT DMARC para impor uma política DMARC (p=quarantine ou p=reject) para mensagens que falham na validação DMARC. Para obter mais informações, veja Sintaxe para registos TXT DMARC.

Validado pelo ARC (cenários de encaminhamento complexos)

Esse cenário se aplica a mensagens aceitas por meio da validação ARC no encaminhamento ou em outros caminhos de roteamento complexos.

  • Exemplo de cabeçalho: compauth=pass reason=130 (autenticação composta transmitida devido ao ARC).
  • O que significa: a mensagem foi autenticada devido a uma substituição da Cadeia de Recebimento Autenticado (ARC). Normalmente, este resultado ocorre em cenários complexos de encaminhamento de e-mail ou reencaminhamento de e-mail. Se um servidor de correio intermédio modificar a mensagem e fizer com que o SPF ou o DKIM falhem, uma assinatura ARC fidedigna informa o Microsoft 365 de que a autenticação original é válida. Neste caso, o sistema aceitou a mensagem com base na cadeia ARC válida, apesar de as verificações SPF ou DKIM diretas poderem falhar.
  • Quem é responsável: o Remetente (remetente original ou intermediário). Não há configuração incorreta. Um intermediário que utiliza o ARC processou a mensagem.
  • Ação recomendada: não é necessária nenhuma ação direta se este cenário for esperado (por exemplo, a mensagem foi processada por um serviço conhecido que implementa o ARC). Se operar um serviço intermediário que não seja da Microsoft, adicione cabeçalhos ARC e verifique se os servidores de receção (como o Microsoft 365) confiam nas suas assinaturas ARC. Esta configuração permite que as mensagens de entrada passem pela compauth através do ARC.

Observação

Em cenários de encaminhamento de email em que o serviço de encaminhamento é outra organização do Microsoft 365, não é necessário configurar seladores ARC confiáveis para microsoft.com. As assinaturas ARC são automaticamente aceitas como confiáveis pelas organizações do Microsoft 365 que recebem a mensagem quando ela passa na validação.

Mensagem entregue devido a entradas de permissão para remetentes falsificados na Lista de Permissões/Bloqueios do Locatário

Esse cenário explica por que uma mensagem falsificada ainda pode ser entregue quando a organização do destinatário a permite explicitamente.

  • O que significa: a mensagem ignorou as ações de falha de autenticação normais porque as entradas de permissões para remetentes falsificados existem na Lista de Permissões/Bloqueios do Inquilino. No Microsoft 365, uma entrada de permissão para remetentes falsos pode sobrepor-se às falhas. Mesmo quando as verificações de autenticação de e-mail normalmente falham, a mensagem é permitida devido a esta configuração de confiança explícita.

  • Exemplo de cabeçalho: compauth=fail reason=000 (mas uma política da organização permitiu a entrega da mensagem: Lista de Permissões/Bloqueios de Locatários: falsificação de identidade permitida).

  • Quem é o responsável: o destinatário. Os administradores da organização do destinatário configuraram uma entrada de permissão para falsificação na lista Permitir/Bloquear de Locatário para essa sintaxe de par de domínio específica para entradas de remetente falsificadas. O remetente deve resolve problemas de autenticação para evitar problemas de capacidade de entrega com outros destinatários.

  • Ação recomendada: os administradores dos destinatários podem verificar a seção Todas as substituições na página da entidade de email para confirmar se há envolvimento de uma substituição da Lista de Permissões/Bloqueios de Locatários. Estas mensagens contêm Permitido pela política da organização: falsificação permitida pela Lista de Permissões/Bloqueios do locatário.

    Geralmente, não há nenhuma ação imediata para estas mensagens, uma vez que são intencionalmente permitidas. No entanto, é uma boa prática para os administradores revisarem periodicamente as entradas de permissão de remetentes falsificados para garantir que apenas os remetentes necessários sejam permitidos. A utilização excessiva da Lista de Permissões/Bloqueios do Inquilino permite a entrega de mensagens (possivelmente maliciosas) que normalmente falhariam nas verificações de autenticação.

Alinhamento autenticado através de PTR (DNS inverso)

Esse cenário descreve a autenticação de fallback com base em informações de DNS reverso (PTR) quando as verificações padrão são inconclusivas.

  • Exemplo de cabeçalho: compauth=pass com códigos como reason=116 ou reason=111 para indicar a utilização do registo PTR.
  • O que significa: a mensagem foi autenticada com base na validação de PTR (DNS reverso) como alternativa. Em alguns casos, quando as verificações SPF e DKIM não produzem um passe conclusivo, o Microsoft 365 pode analisar o registo PTR do remetente. Se o endereço IP do servidor de envio tiver um registo PTR (DNS inverso) que corresponda ao domínio no endereço De da mensagem, o sistema poderá tratar a mensagem como autenticada.
  • Quem é o responsável: o remetente. O servidor de e-mail do remetente foi verificado através do registo PTR no DNS. Normalmente, este resultado significa que o SPF e o DKIM não foram configurados corretamente e o sistema recorreu à pesquisa PTR.
  • Ação recomendada: o remetente deve garantir que o SPF e o DKIM estão configurados corretamente para o respetivo domínio. Um registo DNS inverso (PTR) correto que mapeia o domínio de envio para o endereço IP de envio é bom, mas não substitui o alinhamento DMARC. Os remetentes têm de tratar o passe PTR como um indicador para melhorar a configuração do SPF e do DKIM. Não há nenhuma ação a ser tomada pelo destinatário, exceto notificar os remetentes quando perceberem esse resultado.

Cenários de falha na autenticação de e-mail

Estes cenários abrangem verificações de autenticação falhadas ou outras condições em que a mensagem é marcada como não autenticada. Falhar em uma verificação de autenticação nem sempre significa que a mensagem foi rejeitada. Algumas falhas fazem com que a mensagem seja colocada em quarentena ou entregue com avisos. Os cenários seguintes descrevem o motivo pelo qual a falha ocorreu, quem precisa de a resolver e como corrigir o problema subjacente.

O remetente refere-se aos administradores na organização de origem. O destinatário refere-se aos administradores na organização de destino.

DMARC Falhou (Mensagem Rejeitada ou Em Quarentena)

Este cenário explica como interpretar uma falha de DMARC que leva à quarentena ou rejeição da mensagem.

  • Exemplo de cabeçalho: dmarc=fail action=quarantine (ou action=reject); frequentemente acompanhado por compauth=fail um código (por exemplo, reason=000, reason=001ou reason=601).

  • O que significa: A validação DMARC falhou para a mensagem. Este resultado significa:

    • O SPF ou o DKIM não foi aprovado no alinhamento com o domínio do endereço "De".

      And

    • O registro DMARC do domínio do endereço no campo De contém uma política p=quarantine ou p=reject.

    Como resultado, o Microsoft 365 marcou a mensagem para a ação de política especificada: entregar na pasta Email de Lixo, colocar em quarentena ou rejeitar.

  • Quem é o responsável: o remetente ou o destinatário. A falha ocorre devido ao domínio do remetente não passar dMARC ou a configuração do destinatário para integrar serviços de segurança não Microsoft com Microsoft 365 que causaram falha do DMARC.

    Embora os remetentes sejam responsáveis por configurar corretamente o SPF, o DKIM e o DMARC para o respetivo domínio, as falhas de autenticação podem, por vezes, resultar de problemas na organização do destinatário. Por exemplo:

    • A organização do destinatário utiliza um serviço de filtragem não Microsoft entre a Internet Microsoft 365 sem configurar a Filtragem Avançada para Conectores. A validação do SPF poderá falhar quando o Microsoft 365 receber a mensagem.
    • Se o serviço de filtragem não Microsoft modificar a mensagem antes da entrega, o DKIM poderá falhar, mesmo que o registo DKIM do remetente esteja configurado corretamente.

    Portanto, é importante distinguir entre o veredicto no momento da receção inicial (registo MX) vs. o veredicto quando a mensagem chega à caixa de correio do destinatário.

  • Ação recomendada:

    • O remetente precisa corrigir a configuração de autenticação de e-mail. Especificamente, o remetente tem de efetuar os seguintes passos:

      • Certifique-se de que o registro SPF inclua todos os endereços IP de origem legítimos para e-mails enviados do domínio.
      • Configure o DKIM para o domínio e verifique se as assinaturas estão corretamente aplicadas ao correio enviado.
      • Verifique se SPF ou DKIM (ou ambos) são aprovados e também estão alinhados com o domínio do endereço no campo De, conforme exigido pelo DMARC.
      • Verifique a sintaxe do registo DMARC e a política DMARC. Por exemplo: p=quarantine ou p=reject.

    • O destinatário precisa corrigir sua configuração complexa de roteamento de e-mail. Especificamente, o destinatário tem de efetuar os seguintes passos:

      • Configurar a Filtragem Avançada para Conectores
      • Se disponível, configure os seladores ARC confiáveis para ignorar falhas causadas por modificações na mensagem em trânsito.
      • Considere utilizar o Microsoft 365 para aplicar modificações de mensagens (rodapés, exclusões de responsabilidade, assunto, etc.) em vez de serviços não Microsoft.

Falha na verificação de SPF

Esse cenário ajuda você a diagnosticar mensagens que falham na avaliação do SPF.

  • Exemplo de cabeçalho: spf=fail ou spf=softfail. Fique atento a spf=temperror, que indica problemas transitórios de DNS, ou a spf=permerror, que indica problemas de configuração de SPF.

  • O que significa: uma das seguintes possibilidades:

    • O endereço IP do servidor de envio não está autorizado pelo registo SPF do domínio, pelo que o SPF devolveu uma falha.
    • A verificação de SPF não pôde ser concluída corretamente. Por exemplo, um problema de pesquisa de DNS (spf=temperror) ou demasiados redirecionamentos (spf=permerror).

    Uma falha de SPF sem um passe DMARC também resulta numa falha DMARC.

  • Quem é o responsável: o remetente. O problema reside na configuração do registo SPF do domínio do remetente ou na configuração do servidor de envio.

  • Ação recomendada: o remetente deve atualizar e corrigir o registo SPF do domínio:

    • Verifique se todos os endereços IP de origem legítimos do domínio estão incluídos no registo SPF.
    • Se o DMARC falhar devido a um desalinhamento entre domínios (o domínio do endereço MAIL FROM é diferente do domínio do endereço no campo From), você pode corrigir isso realizando uma ou ambas as etapas a seguir:
      • Alinhe os domínios usados nos endereços MAIL FROM e From.
      • Configure a assinatura DKIM de mensagens de saída usando um domínio que corresponda ao domínio do endereço From. O DMARC requer validação SPF ou DKIM, não ambas.
    • spf=temperror geralmente indica que o destinatário teve um problema ao resolver o registo SPF (por exemplo, problemas de DNS transitórios). O remetente deve verificar se os servidores DNS do respetivo domínio estão em bom estado de funcionamento e acessíveis. Se o valor de tempo de vida (TTL) for muito baixo e causar expirações frequentes, considere aumentar o TTL para pelo menos uma hora.
    • spf=permerror geralmente indica um problema no próprio registro SPF, incluindo a solução de problemas em registros TXT de SPF que exigem mais de 10 consultas DNS. Simplifique o registro SPF removendo declarações desnecessárias include: e corrigindo quaisquer erros de sintaxe.

Resolver problemas de SPF significa que é mais provável que as mensagens passem pela autenticação DMARC. Os destinatários devem notificar os remetentes sobre falhas de SPF e as ações recomendadas para corrigir os problemas.

Falha na Verificação de DKIM (Sem chave para assinatura)

Esse cenário aborda falhas de DKIM causadas por chaves públicas ausentes ou incompatíveis no DNS.

  • Exemplo de cabeçalho: dkim=fail (sem chave para assinatura) se a chave pública estiver em falta.

  • O que significa: uma das seguintes possibilidades:

    • Havia uma assinatura DKIM, mas o destinatário não conseguiu encontrar uma chave pública correspondente no DNS (sem chave).

      Ou

    • A chave não correspondia à assinatura (não foi possível verificar a assinatura).

  • Quem é o responsável: o remetente. O domínio do remetente tem uma configuração de DKIM quebrada:

    • Uma chave pública não está presente no registo DKIM CNAME ou TXT no DNS.

      Ou

    • Existe um problema de DNS do lado do remetente ou do lado do recetor.

  • Ação recomendada: o remetente deve corrigir a configuração do DKIM para o respetivo domínio através dos seguintes passos:

    • Publique a chave pública DKIM no DNS. Verifique se o registo DKIM CNAME ou TXT contém um seletor válido (por exemplo, selector._domainkey.contoso.com) que corresponde à chave privada utilizada para assinar as mensagens.
    • Se a chave estiver publicada, provavelmente ocorreu um tempo limite quando o Microsoft 365 tentou consultar o registro. Verifique se o valor de Time-to-Live (TTL) está definido para pelo menos uma hora.

Dica

Alinhe o domínio no registro DKIM para DMARC usando o mesmo domínio ou subdomínio no campo d= da assinatura DKIM que no endereço De. Geralmente, este requisito significa trabalhar com serviços que não sejam da Microsoft para publicar a chave pública adequada, conforme descrito em Assinatura DKIM de correio do seu domínio personalizado noutros serviços de e-mail.

Assim que o DKIM estiver corretamente configurado e alinhado, os destinatários verão dkim=pass em suas mensagens, o que também ajuda as mensagens a passar pela verificação DMARC.

O DKIM falhou após a modificação (a assinatura não foi validada)

Esse cenário explica falhas de DKIM causadas por alterações de cabeçalho após a assinatura.

  • Exemplo de cabeçalho: dkim=fail (A assinatura não pôde ser verificada).
  • O que significa: a mensagem continha uma assinatura DKIM válida, mas a mensagem falhou na verificação de DKIM porque um cabeçalho incluído na assinatura DKIM foi modificado em trânsito após a assinatura. Normalmente, esta modificação ocorre quando um intermediário (por exemplo, uma lista de correio, um serviço de reencaminhamento ou dispositivo de segurança) altera um cabeçalho assinado (por exemplo, Assunto:, De:ou Para:) após a assinatura DKIM ter sido originalmente aplicada. O valor h= em DKIM-Signature identifica os cabeçalhos incluídos no hash original. Modificar qualquer um destes cabeçalhos resulta numa falha de DKIM.
  • Quem é o responsável: o remetente ou o intermediário que alterou os cabeçalhos da mensagem. O remetente original assinou corretamente a mensagem, mas um intermediário pode ser responsável pela assinatura DKIM quebrada.
  • Ação recomendada: não faça alterações aos cabeçalhos após a assinatura de uma mensagem no DKIM:
    • Remetentes: Verifique se os cabeçalhos assinados permanecem inalterados desde o momento em que a mensagem é assinada com DKIM até que ela saia do seu ambiente.
    • Intermediários: permite que os clientes configurem seu serviço como um selador ARC confiável para ignorar falhas de DKIM causadas por modificações na mensagem durante o trânsito.

O DKIM falhou após a modificação (o hash do corpo falhou)

Esse cenário aborda falhas de DKIM causadas por alterações no corpo da mensagem após a assinatura.

  • Exemplo de cabeçalho: dkim=fail (o hash do corpo falha).
  • O que significa: a mensagem continha uma assinatura DKIM válida, mas a mensagem falhou na verificação de DKIM porque o corpo da mensagem foi modificado em trânsito após a assinatura. Normalmente, esta modificação ocorre quando um intermediário (por exemplo, uma lista de correio, um serviço de reencaminhamento ou dispositivo de segurança) altera o conteúdo do corpo da mensagem após a assinatura DKIM ter sido originalmente aplicada. O resultado é que o hash calculado pelo sistema de e-mail de recebimento não corresponde ao hash na assinatura DKIM, de modo que a verificação DKIM falha.
  • Quem é o responsável: o remetente ou o intermediário que alterou a mensagem. O remetente original assinou corretamente a mensagem, mas um intermediário pode ser responsável pela assinatura DKIM quebrada.
  • Ação recomendada: certifique-se de que não são efetuadas alterações não intencionais ao conteúdo do e-mail após a assinatura:
    • Remetentes: siga estas etapas:
      • Verifique se os cabeçalhos assinados permanecem inalterados desde o momento em que a mensagem está assinada com DKIM até sair do ambiente.
      • Considere utilizar o Microsoft 365 para aplicar modificações de mensagens (rodapés, exclusões de responsabilidade, assunto, etc.) em vez de serviços não Microsoft.
    • Intermediários: permite que os clientes configurem seu serviço como um selador ARC confiável para ignorar falhas de DKIM causadas por modificações na mensagem durante o trânsito.

Tabela de referência rápida para cenários de autenticação de email

A tabela a seguir resume os cenários de autenticação de email, as soluções recomendadas e links para artigos relevantes para leitura adicional.

O remetente refere-se aos administradores do domínio de envio. O destinatário refere-se aos administradores da organização receção.

Cenário Solução Referência do Learn
Todas as verificações de autenticação passam (SPF, DKIM e DMARC todos passam) Não é necessária nenhuma ação. A autenticação é completamente bem-sucedida. Cabeçalhos de mensagens anti-spam no Office 365
Passe de autenticação composto (compauth=pass) Não é necessária nenhuma ação. A mensagem foi identificada como legítima por compauth. Recomendamos publicar registros SPF, DKIM ou DMARC ausentes no DNS para verificação explícita. Autenticação de email no Microsoft 365
DMARC bestguesspass, sem política (sem registo DMARC) O remetente deve publicar um registo DMARC para o domínio. Usar DMARC para validar emails
ARC validado (serviço que não é da Microsoft considerado confiável via ARC) Não é necessária qualquer ação (se for esperada a modificação de mensagens por um serviço que não seja da Microsoft). Certifique-se de que os serviços que não são da Microsoft utilizam o ARC. Configurar seladores ARC confiáveis
Permitido pela Lista de Permissões/Bloqueios do locatário (permitido pela política da organização: falsificação de identidade permitida na Lista de Permissões/Bloqueios do locatário) Não é necessária qualquer ação imediata. Os administradores devem revisar periodicamente as entradas de permissão para remetentes falsos. Exibir entradas de remetentes falsificados na Lista de Permissões/Bloqueios do Locatário
Autenticado através do registo PTR (pesquisa de DNS inversa) O remetente deve configurar o SPF ou o DKIM (não dependa da pesquisa PTR). Configurar o SPF para identificar origens de e-mail válidas para o seu domínio do Microsoft 365
Falha de DMARC (política de quarentena ou rejeição) O remetente deve garantir:
  • Passe SPF ou DKIM.
  • O domínio MAIL FROM ou o domínio de assinatura DKIM está alinhado com o domínio De.

Destinatário para configurar a Filtragem Avançada para Conectores e ARC em cenários de encaminhamento de correio complexos (serviços intermediários).

O destinatário deve considerar mover as modificações nas mensagens (rodapés, avisos legais, linha de assunto etc.) para o Microsoft 365 para evitar falhas de DKIM.		 Usar DMARC para validar emails

Filtragem avançada para conectores

Configurar seladores ARC confiáveis

Considerações para integrar serviços de segurança não Microsoft no Microsoft 365
Falha na verificação de SPF Remetente para atualizar o registo SPF (inclua todos os endereços IP de origem e corrija erros). Configurar o SPF para identificar origens de e-mail válidas para o seu domínio do Microsoft 365
DKIM nenhum O remetente deve configurar a assinatura com DKIM usando o domínio do endereço no campo From. Use o DKIM para e-mails em seu domínio personalizado
A verificação de DKIM falhou (nenhuma chave para a assinatura) O remetente deve corrigir a configuração de DKIM para o domínio (publicar a chave pública DKIM). Configurar o DKIM
DKIM invalidado por modificação (a assinatura não pôde ser verificada ou a hash do corpo falhou) Configurar serviços intermediários como seladores ARC confiáveis

O destinatário deve considerar mover as modificações nas mensagens (rodapés, avisos legais, linha de assunto etc.) para o Microsoft 365 para evitar falhas de DKIM.		 Configurar seladores ARC confiáveis

Melhores práticas e sugestões

Use as práticas recomendadas a seguir para fortalecer e manter a autenticação de email.

  • Implementar SPF, DKIM e DMARC: estas tecnologias complementam-se mutuamente e fornecem defesa em profundidade. Qualquer coisa menos deixa lacunas na proteção.

  • Manter registos DNS: mantenha os registos SPF atualizados com todas as suas origens de e-mail. Faça a rotação e gerencie as chaves DKIM conforme necessário, e monitore seus relatórios DMARC para identificar falhas de autenticação.

  • Monitore os resultados da autenticação: verifique regularmente os cabeçalhos Authentication-Results ou use ferramentas/relatórios (por exemplo, o insight de inteligência contra falsificação do Microsoft 365) para ver como as mensagens recebidas estão sendo tratadas. Esta atividade pode revelar parceiros que não tenham configurado o SPF/DKIM ou se a sua própria mensagem estiver a falhar na autenticação.

  • Utilizar o ARC para cenários de reencaminhamento: se a sua organização fizer o reencaminhamento de e-mail ou utilizar serviços que não sejam da Microsoft que modificam mensagens, considere configurar sealers ARC fidedignos no Microsoft 365. O ARC pode ajudar a preservar a autenticação e evitar falhas falsas quando as mensagens passam por intermediários.

  • Tenha cuidado com as listas de permissões: confie nos resultados de autenticação padrão sempre que possível, em vez de a organização permitir entradas. As entradas de permissão devem ser exceções e devem ser verificadas periodicamente para remover entradas desnecessárias.

  • Mantenha-se informado: siga estes recursos:

  • Last updated on