Autenticação de e-mail em organizações de nuvem

Enquanto organização com caixas de correio na nuvem, é importante proteger a integridade das mensagens de e-mail dos remetentes nos seus domínios. Os destinatários devem sentir-se confiantes de que as mensagens de remetentes no seu domínio são realmente provenientes de remetentes no seu domínio.

Email autenticação (também conhecida como validação de e-mail) é um grupo de normas para identificar e impedir a entrega de mensagens de e-mail de remetentes falsificados (também conhecidos como spoofing). Os remetentes falsificados são frequentemente utilizados em e-mails empresariais comprometidos (BEC), phishing e outros ataques de e-mail. Estas normas incluem:

• Sender Policy Framework (SPF): especifica os servidores de e-mail de origem que estão autorizados a enviar correio para o domínio.
• DomainKeys Identified Mail (DKIM): utiliza um domínio para assinar digitalmente elementos importantes da mensagem para garantir que a mensagem permanece inalterado em trânsito.
• Autenticação de Mensagens baseada em domínio, Relatórios e Conformidade (DMARC): 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 DMARC (relatórios).
• Cadeia de Recebimento Autenticada (ARC): preserva as informações originais de autenticação de email por meio de serviços conhecidos que modificam as mensagens em trânsito. O servidor de e-mail de destino pode utilizar estas informações para autenticar mensagens que, de outra forma, falhariam com o DMARC.

É importante perceber que estas normas são blocos modulares interdependentes que funcionam em conjunto para fornecer a melhor proteção de e-mail possível contra ataques de spoofing e phishing. Qualquer coisa menos do que todos os métodos de autenticação de e-mail resulta numa proteção inferior ao padrão.

Para configurar a autenticação de e-mail para e-mails enviados por organizações do Microsoft 365 com caixas de correio na nuvem, consulte os seguintes artigos:

• Configurar o SPF para identificar origens de e-mail válidas para os seus domínios de cloud personalizados
• Configurar o DKIM para assinar correio a partir do seu domínio na nuvem
• Configurar DMARC para validar o domínio do endereço de origem para remetentes na nuvem

Para evitar falhas na autenticação de email devido a serviços que modificam os emails recebidos enviados para sua organização do Microsoft 365, consulte Configurar seladores ARC confiáveis.

Para diagnosticar e corrigir falhas de autenticação de e-mail, consulte Resolver problemas de autenticação de e-mail no Microsoft 365.

Este artigo também aborda por que o email da Internet precisa de autenticação, como SPF, DKIM e DMARC funcionam juntos para autenticar remetentes de mensagens de email, como Microsoft usa a autenticação de email implícita e composta para verificar emails de entrada enviados para Microsoft 365 e como evitar falhas de autenticação de email ao enviar emails para Microsoft 365.

Por que motivo o e-mail da Internet precisa de autenticação

Por predefinição, o e-mail do Protocolo SMTP (Simple Mail Transfer Protocol) na Internet não faz qualquer esforço para validar que o remetente da mensagem é quem afirma ser.

Uma mensagem de e-mail SMTP padrão consiste num envelope de mensagens e conteúdos de mensagens:

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

Devido a esta estrutura, uma mensagem tem vários valores de remetente:

• O endereço MAIL FROM (também conhecido como endereço 5321.MailFrom , remetente P1 ou remetente de envelope) é o endereço de e-mail utilizado na transmissão da mensagem entre servidores de e-mail SMTP. Normalmente, este endereço é registado no campo de cabeçalho Return-Path no cabeçalho da mensagem (embora o servidor de e-mail de origem possa designar um endereço de e-mail Return-Path diferente). Este endereço de e-mail é usado em relatórios de não entrega (também conhecidos como NDRs ou mensagens de retorno).
• O endereço no campo De (também conhecido como endereço 5322.From ou remetente P2) é o endereço de e-mail no campo de cabeçalho De e é o endereço de e-mail do remetente exibido em clientes de e-mail.

O exemplo seguinte mostra a transcrição simplificada de uma transmissão de mensagens válida entre dois servidores de e-mail 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 e-mail de origem identifica-se como woodgrovebank.com ao servidor de e-mail de destino tailspintoys.com no comando HELO.
• O destinatário da mensagem é astobes@tailspintoys.com.
• O endereço MAIL FROM no envelope de mensagem (utilizado para transmitir a mensagem entre servidores de e-mail SMTP) é dubious@proseware.com.
• O endereço do remetente exibido no cliente de e-mail do destinatário é security@woodgrovebank.com.

Embora esta mensagem seja válida de acordo com o protocolo SMTP, o domínio do endereço MAIL FROM (proseware.com) não corresponde ao domínio do endereço From (woodgrovebank.com). Esta mensagem é um exemplo clássico de spoofing, em que é provável que a intenção engane o destinatário ao mascarar a verdadeira origem da mensagem a utilizar num ataque de phishing.

Claramente, o e-mail SMTP precisa de verificar se os remetentes de mensagens são quem dizem ser!

Como o SPF, o DKIM e o DMARC funcionam em conjunto para autenticar remetentes de mensagens de e-mail

Os domínios da Internet precisam de SPF, DKIM e DMARC para trabalhar em conjunto para autenticação de email eficaz.

• SPF: Conforme explicado em Configurar o SPF para identificar origens de e-mail válidas para os seus domínios de cloud personalizados, o SPF utiliza um registo TXT no DNS para:

  • Identifique origens de correio válidas do domínio MAIL FROM.
  • O que fazer se o servidor de e-mail de destino receber correio de uma origem indefinida ("falha difícil" ao rejeitar a mensagem; "falha suave" para aceitar e marcar a mensagem).

  Problemas do SPF:

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

    • Um atacante pode enviar emails que passem pela autenticação SPF (um falso negativo) seguindo estas etapas:
      • Registe um domínio (por exemplo, proseware.com) e configure o SPF para o domínio.
      • Enviar email de uma origem válida para o domínio registrado, com os endereços de email "De" em um domínio diferente (por exemplo, woodgrovebank.com).
    • Um serviço de e-mail legítimo que envia correio 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, pelo que as mensagens não podem passar na autenticação SPF (um falso positivo).

  • O SPF falha quando as mensagens encontram encaminhamento de email baseado em servidor que redireciona ou retransmite as mensagens.

    • O reencaminhamento de e-mail baseado no servidor altera a origem da mensagem do servidor original para o servidor de reencaminhamento.
    • O servidor de reencaminhamento não está autorizado a enviar correio a partir do domínio MAIL FROM original, pelo que a mensagem não pode passar na autenticação SPF (um falso positivo).

  • Cada domínio e quaisquer subdomínios requerem os seus próprios registos SPF individuais. Os subdomínios não herdam o registo SPF do domínio principal. Este comportamento torna-se problemático se quiser permitir e-mails de subdomínios definidos e utilizados, mas impedir o e-mail de subdomínios não definidos e não utilizados.

• DKIM: conforme explicado em Configurar o DKIM para assinar correio a partir do seu domínio na nuvem, o DKIM utiliza 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 alojamento de e-mail onde o mesmo endereço MAIL FROM é utilizado para correio de outros domínios.
  • Mensagens que encontram encaminhamento de email baseado em servidor.

  Como a assinatura DKIM no cabeçalho da mensagem não é afetada ou alterada durante o encaminhamento de email ou quando um serviço de hospedagem usa o mesmo endereço MAIL FROM para vários domínios, 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 campo De mostrado nos clientes de e-mail.

  Assim como o SPF, um invasor pode enviar emails que passam pela autenticação DKIM (um falso negativo) seguindo estas etapas:

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

• DMARC: conforme explicado em Configurar o DMARC para validar o domínio do endereço De para remetentes de caixas de correio na nuvem, o DMARC usa SPF e DKIM para verificar o alinhamento entre os domínios nos endereços MAIL FROM e De. O DMARC também especifica a ação que o sistema de e-mail de destino deve executar em mensagens que não passam na validação DMARC e identifica para onde enviar os resultados do DMARC (tanto aprovações quanto falhas).

  Como o DMARC auxilia o SPF e o DKIM: conforme descrito anteriormente, o SPF não tenta corresponder o domínio no domínio MAIL FROM e nos endereços De. O DKIM não se importa se o domínio que assinou a mensagem corresponde ao domínio no endereço De.

  O DMARC aborda a falta de verificações de alinhamento de domínio em SPF e DKIM confirmando que 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 entrega invalidam as verificações de SPF, DKIM e, consequentemente, DMARC.

  Quando as mensagens são reencaminhadas automaticamente entre domínios ou organizações, o alinhamento DMARC pode falhar mesmo para remetentes de serviço legítimos. Por exemplo, se um domínio de serviço da Microsoft (como voicemail.microsoft.com) falhar na DMARC após o encaminhamento, use uma entrada de permissão com escopo definido na Lista de Permissões/Bloqueios de Locatários ou um relay autenticado, em vez de permitir todo o domínio remetente.

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

  Como o ARC ajuda o DMARC: o sistema de e-mail de destino pode identificar o serviço como um selador ARC fidedigno. Em seguida, o ARC pode utilizar as informações de autenticação de e-mail preservadas para validar a mensagem.

Autenticação de e-mail de entrada para correio enviado para o Microsoft 365

Devido a problemas de phishing e à adoção menos completa de políticas de autenticação de e-mail fortes por remetentes de e-mail na Internet, o Microsoft 365 utiliza a autenticação implícita de e-mail para marcar e-mail de entrada. A autenticação implícita de e-mail expande as verificações normais de SPF, DKIM e DMARC através de sinais de outras origens para avaliar o e-mail de entrada. Estas origens incluem:

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

Para ver o anúncio original da Microsoft sobre autenticação implícita, veja A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365.

Com estes outros sinais, as mensagens que, de outra forma, falhariam nas verificações de autenticação de e-mail tradicionais podem passar a autenticação implícita e ser permitidas no Microsoft 365.

Autenticação composta

Os resultados das verificações de autenticação implícita do Microsoft 365 são combinados e armazenados num único valor denominado autenticação composta ou compauth abreviada. O cabeçalho Authentication-Results é um campo de cabeçalho de mensagem que registra o resultado das verificações de autenticação de email. O valor compauth é marcado no cabeçalho Resultados de Autenticação nos cabeçalhos da mensagem. O cabeçalho Authentication-Results utiliza 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.

Os administradores e utilizadores podem examinar os cabeçalhos das mensagens para descobrir como o Microsoft 365 identificou o remetente como um remetente falsificado suspeito ou legítimo.

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

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

• Resultado: a mensagem pode falhar a 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 registos SPF, DKIM ou DMARC.

• Resultado: as mensagens de remetentes no domínio fabrikam.com podem falhar a 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 registo SPF e nenhum registo DKIM. Os domínios nos endereços MAIL FROM e From correspondem.

• Resultado: a mensagem pode ser aprovada na autenticação composta, porque o domínio aprovado no SPF corresponde ao domínio no endereço From:

  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 registo DKIM sem um registo SPF. O domínio que assinou a mensagem com DKIM corresponde ao domínio no endereço From.

• Resultado: a mensagem pode passar pela autenticação composta, porque o domínio na assinatura DKIM corresponde ao domínio no endereço From.

  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 a assinatura DKIM não corresponde ao domínio no endereço De.

• Resultado: A mensagem pode falhar a 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 de e-mail ao enviar correio para o Microsoft 365

• Configurar registos SPF, DKIM e DMARC para os seus domínios: utilize as informações de configuração fornecidas pela sua entidade de registo de domínios ou pelo serviço de alojamento DNS. Também existem serviços não Microsoft dedicados a ajudar a configurar registos de autenticação de e-mail.

  Muitas empresas não publicam registos SPF porque não conhecem todas as origens de e-mail das mensagens no respetivo domínio.

  1. Comece por publicar um registo SPF que contenha todas as origens de e-mail que conhece (especialmente onde está localizado o tráfego empresarial) e utilize o valor da regra de imposição "soft fail" (~all). Por exemplo:

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

     Se criar este registo SPF, o Microsoft 365 trata o e-mail de entrada da sua infraestrutura empresarial como autenticado. Email de fontes não identificadas ainda pode ser marcado como falsificado se não passar na autenticação composta. No entanto, esse comportamento ainda é melhor do que todos os e-mails de remetentes do domínio serem marcados como falsificados no Microsoft 365. Normalmente, o sistema de email de destino aceita mensagens de remetentes no domínio de fontes não identificadas quando o SPF está configurado com uma regra de aplicação de falha flexível.

  2. Descubra e inclua mais origens de e-mail para as 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 origens de e-mail do seu domínio, pode atualizar o registo SPF para utilizar o valor da regra de imposição "falha grave" (-all).

  3. Configure o DKIM para assinar digitalmente mensagens.

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

  5. Se você usa serviços de envio em massa para enviar e-mails em seu nome, verifique se o domínio no campo De corresponde ao domínio que passa na verificação SPF ou DMARC.

• Aloja o e-mail de um domínio ou fornece uma infraestrutura de alojamento que pode enviar e-mails:

  • Certifique-se de que os seus clientes têm documentação que explica como configurar o SPF para os respetivos domínios.
  • Considere assinar os e-mails de saída com DKIM, mesmo que o cliente não configure explicitamente o DKIM em seu domínio (assine com um domínio padrão). Pode até assinar novamente o e-mail com assinaturas DKIM (com o domínio da empresa e o domínio do cliente se/quando estiver disponível).

  A entrega à Microsoft não é garantida, mesmo que autentique o e-mail com origem na sua plataforma. No entanto, a autenticação de e-mail garante que a Microsoft não trate automaticamente como lixo eletrônico os e-mails dos domínios dos seus clientes simplesmente por eles não estarem autenticados.