Autenticação de email no Microsoft 365

Dica

Você sabia que pode experimentar os recursos no Microsoft Defender XDR para Office 365 Plano 2 gratuitamente? Use a avaliação de Defender para Office 365 de 90 dias no hub de avaliações do portal Microsoft Defender. Saiba mais sobre quem pode inscrever e testar termos aqui.

Como uma organização do Microsoft 365 com caixas de correio em Exchange Online ou uma organização EOP (Proteção do Exchange Online autônoma) sem caixas de correio Exchange Online, proteger a integridade das mensagens de email de remetentes em seus domínios é importante. Os destinatários devem se sentir confiantes de que as mensagens de remetentes em seu domínio realmente vieram de remetentes em seu domínio.

Email autenticação (também conhecida como validação de email) é um grupo de padrões para identificar e impedir a entrega de mensagens de email de remetentes forjados (também conhecido como falsificação). Remetentes falsificados são comumente usados em bec (compromisso de email comercial), phishing e outros ataques de email. Esses padrões incluem:

  • Estrutura de Política do Remetente (SPF): especifica os servidores de email de origem autorizados a enviar emails para o domínio.
  • DKIM (DomainKeys Identified Mail): usa um domínio para assinar digitalmente elementos importantes da mensagem para garantir que a mensagem não tenha sido alterada em trânsito.
  • DMARC (Autenticação de Mensagem, Relatório e Conformidade) baseado em domínio: especifica a ação para mensagens que falham nas verificações de SPF ou DKIM para remetentes no domínio e especifica para onde enviar os resultados do DMARC (relatório).
  • ARC (Cadeia recebida autenticada): preserva informações originais de autenticação de email por serviços conhecidos que modificam mensagens em trânsito. O servidor de email de destino pode usar essas informações para autenticar mensagens que, de outra forma, falhariam no DMARC.

É importante perceber que esses padrões são blocos de construção interdependentes que trabalham juntos para fornecer a melhor proteção de email possível contra ataques de falsificação e phishing. Qualquer coisa menor do que todos os métodos de autenticação de email resulta em proteção abaixo do padrão.

Para configurar a autenticação de email para emails enviados de organizações do Microsoft 365 com caixas de correio em organizações Exchange Online ou EOP (Proteção do Exchange Online autônomas) sem caixas de correio Exchange Online, confira os seguintes artigos:

Para evitar falhas de autenticação por email devido aos serviços que modificam os emails de entrada enviados à sua organização do Microsoft 365, consulte Configurar selos ARC confiáveis.

O restante deste artigo explica:

Por que o email da Internet precisa de autenticação

Por design, o email SMTP (Simple Mail Transfer Protocol) na Internet não faz nenhum esforço para validar que o remetente de mensagens é quem eles afirmam ser.

Uma mensagem de email SMTP padrão consiste em um envelope de mensagem e conteúdo de mensagem:

  • O envelope de mensagem contém informações para transmitir e receber a mensagem entre servidores SMTP. O envelope de mensagem é descrito no RFC 5321. Os destinatários nunca veem o envelope da mensagem porque ele é gerado durante o processo de transmissão de mensagens.
  • O conteúdo da mensagem contém campos de cabeçalho de mensagem (chamado coletivamente de cabeçalho de mensagem) e o corpo da mensagem. O cabeçalho da mensagem é descrito no RFC 5322.

Devido a esse design, uma mensagem tem vários valores de remetente:

  • O endereço MAIL FROM (também conhecido como 5321.MailFrom endereço, remetente P1 ou remetente de envelope) é o endereço de email usado na transmissão da mensagem entre servidores de email SMTP. Esse endereço normalmente é registrado no campo cabeçalho Caminho de Retorno no cabeçalho da mensagem (embora o servidor de email de origem possa designar um endereço de email de Caminho de Retorno diferente). Esse endereço de email é usado em relatórios de não entrega (também conhecidos como NDRs ou mensagens de salto).
  • O endereço From (também conhecido como 5322.From endereço ou remetente P2) é o endereço de email no campo De cabeçalho e é o endereço de email do remetente mostrado em clientes de email.

O exemplo a seguir mostra a transcrição simplificada de uma transmissão de mensagem válida entre dois servidores de email SMTP:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

Neste exemplo:

  • O servidor de email de origem se identifica como woodgrovebank.com para o servidor de email de destino tailspintoys.com no comando HELO.
  • O destinatário da mensagem é astobes@tailspintoys.com.
  • O endereço MAIL FROM no envelope de mensagem (usado para transmitir a mensagem entre servidores de email SMTP) é dubious@proseware.com.
  • O endereço From mostrado no cliente de email do destinatário é security@woodgrovebank.com.

Embora essa mensagem seja válida de acordo com o SMTP, o domínio do endereço MAIL FROM (proseware.com) não corresponde ao domínio no endereço From (woodgrovebank.com). Esta mensagem é um exemplo clássico de falsificação, em que a intenção provavelmente enganará o destinatário mascarando a verdadeira fonte da mensagem a ser usada em um ataque de phishing.

Claramente, o email SMTP precisa de ajuda para verificar se os remetentes de mensagens são quem eles afirmam ser!

Como SPF, DKIM e DMARC trabalham juntos para autenticar remetentes de mensagens de email

Esta seção descreve por que você precisa de SPF, DKIM e DMARC para domínios na Internet.

  • SPF: Conforme explicado em Configurar o SPF para identificar fontes de email válidas para seu domínio do Microsoft 365, o SPF usa um registro TXT no DNS para identificar fontes de email válidas do domínio MAIL FROM e o que fazer se o servidor de email de destino receber emails de uma fonte indefinida ('falha difícil' para rejeitar a mensagem; 'soft fail' para aceitar e marcar a mensagem).

    Problemas de SPF:

    • O SPF valida apenas as fontes para remetentes no domínio MAIL FROM. O SPF não considera o domínio no endereço De ou alinhamento entre os domínios MAIL FROM e From:

      • Um invasor pode enviar um email que passa pela autenticação SPF (um falso negativo) seguindo estas etapas:
        • Registre um domínio (por exemplo, proseware.com) e configure o SPF para o domínio.
        • Envie email de uma fonte válida para o domínio registrado, com os endereços de email De um domínio diferente (por exemplo, woodgrovebank.com).
      • Um serviço de email legítimo que envia emails em nome de outros domínios pode controlar o endereço MAIL FROM. Os outros domínios e o domínio MAIL FROM não correspondem, portanto, as mensagens não podem passar autenticação SPF (um falso positivo).

    • O SPF é interrompido após as mensagens encontrarem o encaminhamento de email baseado em servidor que redireciona ou retransmite mensagens.

      • O encaminhamento de email baseado em servidor altera a origem da mensagem do servidor original para o servidor de encaminhamento.
      • O servidor de encaminhamento não está autorizado a enviar emails do domínio MAIL FROM original, portanto, a mensagem não pode passar autenticação SPF (um falso positivo).

    • Cada domínio e quaisquer subdomínios exigem seus próprios registros SPF individuais. Subdomínios não herdam o registro SPF do domínio pai. Esse comportamento se torna problemático se você quiser permitir o email de subdomínios definidos e usados, mas impedir que o email seja indefinido e não utilizado subdomínios.

  • DKIM: Conforme explicado em Configurar o DKIM para assinar emails do domínio do Microsoft 365, o DKIM usa um domínio para assinar digitalmente elementos importantes da mensagem (incluindo o endereço De) e armazena a assinatura no cabeçalho da mensagem. O servidor de destino verifica se os elementos assinados da mensagem não foram alterados.

    Como o DKIM ajuda o SPF: o DKIM pode validar mensagens que falham no SPF. Por exemplo:

    • Mensagens de um serviço de hospedagem por email em que o mesmo endereço MAIL FROM é usado para emails de outros domínios.
    • Mensagens que encontram o encaminhamento de email baseado em servidor.

    Como a assinatura DKIM no cabeçalho da mensagem não é afetada ou alterada nesses cenários, essas mensagens são capazes de passar DKIM.

    Problemas de DKIM: o domínio que o DKIM usa para assinar uma mensagem não precisa corresponder ao domínio no endereço From mostrado em clientes de email.

    Assim como o SPF, um invasor pode enviar um email que passa a autenticação DKIM (um falso negativo) seguindo estas etapas:

    • Registre um domínio (por exemplo, proseware.com) e configure o DKIM para o domínio.
    • Envie email com os endereços De email em um domínio diferente (por exemplo, woodgrovebank.com).

  • DMARC: Conforme explicado em Configurar o DMARC para validar o domínio De endereço para remetentes no Microsoft 365, o DMARC usa SPF e DKIM para marcar para alinhamento entre os domínios nos endereços MAIL FROM e From. O DMARC também especifica a ação que o sistema de email de destino deve receber em mensagens que falham no DMARC e identifica onde enviar resultados DMARC (passar e falhar).

    Como o DMARC ajuda o SPF e o DKIM: Conforme descrito anteriormente, o SPF não faz nenhuma tentativa de corresponder ao domínio no domínio MAIL FROM e em endereços. O DKIM não se importa se o domínio que assinou a mensagem corresponder ao domínio no endereço De.

    O DMARC resolve essas deficiências usando SPF e DKIM para confirmar se os domínios nos endereços MAIL FROM e From correspondem.

    Problemas de DMARC: serviços legítimos que modificam mensagens em trânsito antes da interrupção de entrega SPF, DKIM e, portanto, verificações DMARC.

  • ARC: Conforme explicado em Configurar selos ARC confiáveis, serviços legítimos que modificam mensagens em trânsito podem usar ARC para preservar as informações originais de autenticação de email de mensagens modificadas.

    Como o ARC ajuda o DMARC: o sistema de email de destino pode identificar o serviço como um selador ARC confiável. Em seguida, o ARC pode usar as informações de autenticação de email preservadas para validar a mensagem.

Autenticação de email de entrada para email enviado ao Microsoft 365

Devido a preocupações de phishing e adoção menos do que completa de políticas de autenticação de email fortes por remetentes de email na Internet, o Microsoft 365 usa a autenticação de email implícita para marcar email de entrada. A autenticação de email implícito estende as verificações regulares de SPF, DKIM e DMARC usando sinais de outras fontes para avaliar o email de entrada. Essas fontes incluem:

  • Reputação do remetente.
  • Histórico do remetente.
  • Histórico do destinatário.
  • Análise comportamental.
  • Outras técnicas avançadas.

Para ver o anúncio original da Microsoft sobre autenticação implícita, confira Um Mar de Phish Part 2 – Anti-falsificação aprimorada no Microsoft 365.

Usando esses outros sinais, as mensagens que de outra forma falhariam nas verificações tradicionais de autenticação de email podem passar autenticação implícita e ser permitidas no Microsoft 365.

Autenticação composta

Os resultados das verificações implícitas de autenticação do Microsoft 365 são combinados e armazenados em um único valor chamado autenticação composta ou compauth abreviado. O valor compauth é marcado no cabeçalho Resultados de Autenticação nos cabeçalhos da mensagem. O cabeçalho Autenticação-Resultados usa a seguinte sintaxe:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Estes valores são explicados em Resultados de autenticação do cabeçalho da mensagem.

Administradores e usuários podem examinar os cabeçalhos de mensagem para descobrir como o Microsoft 365 identificou o remetente como um remetente falsificado suspeito ou legítimo.

Dica

É importante entender que uma falha de autenticação composta não resulta diretamente em uma mensagem sendo bloqueada. Nosso sistema usando uma estratégia de avaliação holística que considera a natureza geral suspeita de uma mensagem juntamente com os resultados de autenticação composta. Esse método foi projetado para mitigar o risco de bloquear incorretamente o email legítimo de domínios que podem não seguir estritamente os protocolos de autenticação por email. Essa abordagem balanceada ajuda a distinguir emails genuinamente mal-intencionados de remetentes de mensagens que simplesmente não estão em conformidade com as práticas padrão de autenticação de email.

Os exemplos a seguir se concentram apenas nos resultados da autenticação por email (o valor e o compauth motivo). Outras tecnologias de proteção do Microsoft 365 podem identificar mensagens que passam autenticação por email como falsificadas ou identificar mensagens que falham na autenticação de email como legítimas.

  • Cenário: o domínio no registro SPF ou na assinatura DKIM não corresponde ao domínio no endereço De.

  • Resultado: a mensagem pode falhar na autenticação composta. Apesar da falha de autenticação composta, a mensagem ainda poderá ser permitida se outras avaliações não indicarem uma natureza suspeita:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • Cenário: o domínio fabrikam.com não tem registros SPF, DKIM ou DMARC.

  • Resultado: mensagens de remetentes no domínio fabrikam.com podem falhar na autenticação composta:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • Cenário: o domínio fabrikam.com tem um registro SPF e nenhum registro DKIM. Os domínios nos endereços MAIL FROM e From correspondem.

  • Resultado: a mensagem pode passar autenticação composta, pois o domínio passado pelo SPF corresponde ao domínio no endereço De:

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Cenário: o domínio fabrikam.com tem um registro DKIM sem um registro SPF. O domínio que o DKIM assinou a mensagem corresponde ao domínio no endereço De.

  • Resultado: a mensagem pode passar autenticação composta, pois o domínio na assinatura DKIM corresponde ao domínio no endereço De:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Cenário: o domínio no registro SPF ou na assinatura DKIM não corresponde ao domínio no endereço De.

  • Resultado: a mensagem pode falhar na autenticação composta:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Como evitar falhas de autenticação por email ao enviar emails para o Microsoft 365

Dica

Os clientes do Microsoft 365 podem usar os seguintes métodos para permitir mensagens de remetentes identificados como falhas de falsificação ou autenticação:

  • Configurar registros SPF, DKIM e DMARC para seus domínios: use as informações de configuração fornecidas pelo registrador de domínio ou pelo serviço de hospedagem DNS. Há também empresas de terceiros dedicadas a ajudar a configurar registros de autenticação de email.

    Muitas empresas não publicam registros SPF porque não conhecem todas as fontes de email para mensagens em seu domínio.

    1. Comece publicando um registro SPF que contém todas as fontes de email que você conhece (especialmente onde o tráfego corporativo está localizado) e use o valor da regra de imposição "soft fail" (~all). Por exemplo:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Se você criar esse registro SPF, o Microsoft 365 tratará o email de entrada de sua infraestrutura corporativa como autenticado, mas o email de fontes não identificadas ainda poderá ser marcado como falsificação se falhar na autenticação composta. No entanto, esse comportamento ainda é uma melhoria de todos os emails de remetentes no domínio que estão sendo marcados como falsificação pelo Microsoft 365. Normalmente, o sistema de email de destino aceita mensagens de remetentes no domínio de fontes não identificadas quando o SPF é configurado com uma regra de imposição de falha suave.

    2. Descubra e inclua mais fontes de email para suas mensagens. Por exemplo:

      • Servidores de email no local.
      • Email enviado de um provedor de software como serviço (SaaS).
      • Email enviado de um serviço de hospedagem em nuvem (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services, etc.).

      Depois de identificar todas as fontes de email para seu domínio, você pode atualizar seu registro SPF para usar o valor da regra de imposição "hard fail" (-all).

    3. Configure o DKIM para assinar mensagens digitalmente.

    4. Configure o DMARC para validar que os domínios nos endereços MAIL FROM e From correspondem, para especificar o que fazer com mensagens que falham em verificações DMARC (rejeitar ou quarentena) e identificar serviços de relatório para monitorar os resultados do DMARC.

    5. Se você usar remetentes em massa para enviar email em seu nome, verifique se o domínio no endereço De corresponde ao domínio que passa SPF ou DMARC.

  • Você hospeda um email de domínio ou fornece infraestrutura de hospedagem que pode enviar email:

    • Verifique se seus clientes têm documentação que explica como configurar o SPF para seus domínios.
    • Considere o email de saída DKIM de assinatura DKIM, mesmo que o cliente não configure explicitamente o DKIM em seu domínio (assine com um domínio padrão). Você pode até assinar duas vezes o email com assinaturas DKIM (com o domínio da empresa e o domínio do cliente se/quando ele estiver disponível).

    A entrega para a Microsoft não é garantida, mesmo se você autenticar emails provenientes de sua plataforma. Mas, a autenticação por email garante que a Microsoft não efetue lixo eletrônico automaticamente de seus domínios de cliente simplesmente porque ele não é autenticado.