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

A autenticação por email no Microsoft 365 é um componente crítico para garantir 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:

• Porque é que uma mensagem foi aprovada ou reprovada na 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.

Mas primeiro, aqui ficam algumas definições chave:

Cenários de autenticação com êxito do correio eletrónico

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

Este cenário aplica-se quando todas as verificações padrão de autenticação por email passam com sucesso.

• 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 a funcionar como previsto. O destinatário pode confiar no domínio do remetente autenticado corretamente nesta mensagem.

Autenticação composta aprovada

Este cenário descreve como o Microsoft 365 pode aceitar uma mensagem através de 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: o SPF ou o DKIM foi aprovado 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 considerada aprovada na autenticação composta com base no histórico de remetentes seguros da Microsoft ou em inteligência contra falsificação que indique que o remetente é fiá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 registo DMARC)

Este cenário abrange mensagens que parecem passar por DMARC mesmo que o remetente não tenha publicado um 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)

Este cenário aplica-se a mensagens aceites na sequência da validação ARC em cenários de reencaminhamento ou noutros percursos 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: 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

Este cenário explica porque é que uma mensagem falsificada ainda pode ser entregue quando a organização destinatária o 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 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 da organização permitia a mensagem: Falsificação permitida na Lista de Permissões/Bloqueios do inquilino).

• Quem é o responsável: o destinatário. Os administradores na organização do destinatário configuraram uma entrada de permissão para falsificação na lista de Permisso/Bloqueio de Tenant para esta sintaxe específica de pares de domínios para entradas de remetente falsificadas. O remetente deve resolver 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 secção Todas as substituições na página da entidade de e-mail para confirmar se está em causa uma substituição da Lista de Permissões/Bloqueios do inquilino. Estas mensagens contêm Permitido pela política da organização: falsificação de identidade permitida pela Lista de Permissões/Bloqueios do Inquilino.

  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 autorização para remetentes falsificados para garantir que apenas são autorizados os remetentes necessários. 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)

Este cenário descreve a autenticação de recurso com base em informações de DNS inverso (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 PTR (DNS inverso) 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. O destinatário não tem de tomar qualquer medida, exceto notificar os remetentes quando se aperceber deste resultado.

Cenários de falha na autenticação de email

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

    E

  • O registo 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 deve-se ao domínio do remetente não passar no DMARC ou à configuração do destinatário para integrar serviços de segurança não-Microsoft com o Microsoft 365, 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 de autenticação de e-mail. Especificamente, o remetente tem de efetuar os seguintes passos:

    • Certifique-se de que o registo SPF inclui todos os endereços IP de origem legítimos para o envio de e-mail a partir 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 na validação e também estão alinhados com o domínio do 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 complexa de encaminhamento 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 fidedignos para ignorar 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

Este cenário ajuda-o a diagnosticar mensagens que não passam na avaliação do SPF.

• Exemplo de cabeçalho: spf=fail ou spf=softfail. Esteja atento a spf=temperror, que indica problemas transitórios de DNS, ou a spf=permerror, que indica 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 entre domínios (o domínio do endereço MAIL FROM difere do domínio do endereço From), pode corrigir esta situação efetuando uma ou ambas as seguintes etapas:
    • Alinhe os domínios utilizados nos endereços MAIL FROM e From.
    • Configure a assinatura DKIM das mensagens enviadas com um domínio que corresponda ao domínio do endereço do remetente. 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 time-to-live (TTL) for demasiado baixo e causar expirações frequentes, considere aumentar o TTL para pelo menos uma hora.
  • spf=permerror normalmente indica um problema com o próprio registo SPF, incluindo a resolução de problemas de registos SPF TXT que requerem mais de 10 consultas DNS. Simplifique o registo SPF removendo as 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)

Este cenário cobre falhas DKIM causadas por chaves públicas em falta 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 for publicada, é provável que tenha ocorrido um tempo limite quando o Microsoft 365 tentou consultar o registo. Verifique se o valor de tempo de vida (TTL) está definido para pelo menos uma hora.

Assim que o DKIM estiver corretamente configurado e alinhado, os destinatários verão dkim=pass nas suas mensagens, o que também ajuda essas mensagens a passarem na validação DMARC.

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

Este cenário explica falhas no 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 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 valor h= na assinatura DKIM-Signature identifica os campos de cabeçalho 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é a mensagem sair do seu ambiente.
  • Intermediários: Permite que os clientes configurem o seu serviço como um selador ARC de confiança para contornar falhas de DKIM causadas por modificações nas mensagens em trânsito.

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

Este cenário cobre falhas no 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 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: siga estes 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: Permite que os clientes configurem o seu serviço como um selador ARC de confiança para contornar falhas de DKIM causadas por modificações nas mensagens em trânsito.

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

A tabela seguinte resume os cenários de autenticação por email, as soluções recomendadas e os 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.

Melhores práticas e sugestões

Use as seguintes boas práticas para reforçar e manter a autenticação por 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 gira as 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 Microsoft Defender para Office 365
  • Blogue da Equipa do Exchange
  • Novidades no Microsoft Defender para Office 365
  • O Centro de Mensagens do Microsoft 365.