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

Email autenticação é um componente fundamental para proteger a comunicação na 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 motivo uma mensagem passou ou falhou a autenticação de e-mail.
• 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.

No entanto, em primeiro lugar, algumas definições, conforme descrito na tabela seguinte:

Email cenários de acesso de autenticação

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 aprovadas

• 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. Email a autenticação está corretamente configurada e a funcionar conforme pretendido. O destinatário pode confiar no domínio do remetente autenticado corretamente nesta mensagem.

Autenticação composta aprovada

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

• O que significa: A mensagem passou 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 passar a autenticação composta com base no histórico de remetentes seguros da Microsoft ou informações de spoof que indicam que o remetente é fidedigno.

• 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.

Passagem DMARC sem política DMARC (sem registo 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. Efetivamente, a verificação DMARC não se aplica. DMARC=bestguesspass action=none significa que, se o domínio tivesse um registo DMARC válido, a verificação DMARC da mensagem passaria.
• 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)

• Exemplo de cabeçalho: compauth=pass reason=130 (autenticação composta transmitida devido ao ARC).
• O que significa: a mensagem passou a autenticação devido a uma substituição da Cadeia De Receção Autenticada (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 é o 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.

Mensagem entregue devido a entradas de permissões para remetentes falsificados na Lista de Permissões/Bloqueios de Inquilinos

• 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 falsificados pode substituir 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 de organização permitiu a mensagem: Lista de Permissões/Bloqueios de Inquilinos spoof permitido).

• Quem é o responsável: o destinatário. Os administradores na organização do destinatário configuraram uma entrada de permissão para spoofing na lista Permitir/Bloquear Inquilino para este par de domínio específico. O remetente deve resolver problemas de autenticação para evitar problemas de capacidade de entrega com outros destinatários.

• Ação recomendada: os administradores de destinatários podem verificar a secção Todas as Substituições na página da entidade Email para confirmar se está envolvida uma substituição da Lista de Permissões/Bloqueios do Inquilino. Estas mensagens contêm Permitido pela política de organização: Permissões/Lista de Bloqueios de Inquilinos spoof permitido.

  Geralmente, não há nenhuma ação imediata para estas mensagens, uma vez que são intencionalmente permitidas. No entanto, é uma boa prática que os administradores revejam periodicamente as entradas de permissões de remetentes falsificados para garantir que apenas os remetentes necessários são 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)

• 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 passou a autenticação com base na validação PTR (DNS inverso) como uma contingência. 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 existe nenhuma ação para o destinatário, a não ser notificar os remetentes quando repararem neste resultado.

Email cenários de falha de autenticação

Estes cenários abrangem verificações de autenticação falhadas ou outras condições em que a mensagem é marcada como não autenticada. A falha de uma verificação de autenticação nem sempre significa que a mensagem foi rejeitada. Algumas falhas resultam na colocação ou entrega da mensagem em quarentena 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)

• 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 passaram com o alinhamento para o domínio de endereço De.

    E

  • O registo DMARC do domínio de endereço De contém uma p=quarantine política 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 deve-se ao facto de o domínio do remetente não estar a transmitir DMARC ou a configuração complexa de encaminhamento de correio do destinatário que causou a 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 tem de corrigir a configuração da autenticação de e-mail. Especificamente, o remetente tem de efetuar os seguintes passos:

    • Certifique-se de que o respetivo registo SPF inclui todos os endereços IP de origem legítimos para o e-mail do domínio.
    • Configure o DKIM para o domínio e verifique se as assinaturas estão corretamente aplicadas ao correio enviado.
    • Verifique se o SPF ou o DKIM (ou ambos) passam e também estão alinhados com o domínio de endereço 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 tem de corrigir a configuração de encaminhamento de correio complexa. Especificamente, o destinatário tem de efetuar os seguintes passos:

    • Configurar a Filtragem Avançada para Conectores
    • Se disponível, configure os sealers ARC fidedignos para substituir as falhas causadas pela modificação da 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 do SPF

• Exemplo de cabeçalho: spf=fail ou spf=softfail. Tenha em atenção a spf=temperror indicação de problemas de DNS transitórios ou spf=permerror a indicação de problemas de configuração do 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 SPF não foi 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 do domínio (o domínio de endereço MAIL FROM difere do domínio de endereço De), pode corrigi-lo ao efetuar um ou ambos os seguintes passos:
    • Alinhe os domínios utilizados nos endereços MAIL FROM e From.
    • Configure a assinatura DKIM de mensagens a enviar através de um domínio que corresponda ao domínio de endereço De. 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 time-to-Live (TTL) for demasiado baixo e causar tempos limite frequentes, considere aumentar o TTL para , pelo menos, uma hora.
  • spf=permerror normalmente indica um problema com o próprio registo SPF, incluindo a necessidade de mais de 10 pesquisas DNS. Simplifique o registo SPF ao remover instruções desnecessárias include: e corrigir 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)

• 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 for publicada, é provável que tenha ocorrido um tempo limite quando o Microsoft 365 tentou consultar o registo. Verifique se o valor time-to-Live (TTL) está definido como , pelo menos, uma hora.

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

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

• Exemplo de cabeçalho: dkim=fail (A assinatura não foi verificação).
• 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 uma aplicação de segurança) altera um cabeçalho assinado (por exemplo, Assunto:, De:ou Para:) após a assinatura DKIM ter sido originalmente aplicada. O h= valor na 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 está assinada com DKIM até sair do seu ambiente.
  • Intermediários: permita que os clientes configurem o seu serviço como um selador ARC fidedigno para substituir as falhas de DKIM causadas pela modificação da mensagem em trânsito.

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

• 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 uma aplicação 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 receção não corresponde ao hash na assinatura DKIM, pelo que a verificação do 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: efetue os seguintes passos:
    • 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: permita que os clientes configurem o seu serviço como um selador ARC fidedigno para substituir as falhas de DKIM causadas pela modificação da mensagem em trânsito.

Tabela de Referência Rápida

Esta secção contém uma tabela simplificada que resume os cenários, as soluções recomendadas e ligações 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.

Melhores práticas e sugestões

• 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. Rode e faça a gestão das chaves DKIM conforme necessário e monitorize os seus relatórios DMARC para identificar falhas de autenticação.

• Monitorizar os resultados da autenticação: verifique regularmente os cabeçalhos Authentication-Results ou utilize ferramentas/relatórios (por exemplo, as informações de spoof intelligence do Microsoft 365) para ver o desempenho das mensagens recebidas. 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:

  • Blogue do Microsoft Defender para Office 365
  • Blogue da Equipa do Exchange
  • Novidades no Microsoft Defender para Office 365
  • O Centro de Mensagens do Microsoft 365.