Autenticação de e-mail em organizações na 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 receção autenticada (ARC): preserva as informações originais de autenticação do correio eletrónico quando mensagens são modificadas em trânsito por serviços conhecidos. 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 o DMARC para validar o domínio do endereço do remetente para remetentes na nuvem

Para evitar falhas de autenticação de e-mail devido a serviços que modificam o correio eletrónico recebido enviado para a sua organização no Microsoft 365, consulte Configurar seladores ARC fidedignos.

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 porque é que o email na internet precisa de autenticação, como o SPF, DKIM e DMARC trabalham em conjunto para autenticar os remetentes de mensagens de email, como a Microsoft utiliza autenticação implícita e composta por email para verificar o correio recebido enviado para o Microsoft 365, e como evitar falhas na autenticação ao enviar correio para o 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 é utilizado em relatórios de não entrega (também conhecidos como NDRs ou mensagens de rejeição).
• O endereço «De» (também conhecido como o endereço 5322.From ou remetente P2) é o endereço de e-mail no campo de cabeçalho De e corresponde ao endereço de e-mail do remetente apresentado nos 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 mostrado no cliente de e-mail do destinatário é security@woodgrovebank.com.

Embora esta mensagem seja válida segundo o protocolo SMTP, o domínio do endereço MAIL FROM (proseware.com) não corresponde ao domínio do endereço De (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 de internet precisam de SPF, DKIM e DMARC para trabalharem em conjunto e garantir uma autenticação eficaz de emails.

• 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 From nem o alinhamento entre os domínios MAIL FROM e From:

    • Um atacante pode enviar e-mails que passem pela autenticação SPF (um falso negativo) seguindo estes passos:
      • Registe um domínio (por exemplo, proseware.com) e configure o SPF para o domínio.
      • Envie um e-mail a partir de uma origem válida para o domínio registado, com os endereços de e-mail De num 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 passam por um reencaminhamento de e-mail no servidor que redireciona ou encaminha 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 sujeitas a reencaminhamento de e-mail com base no servidor.

  Como a assinatura DKIM no cabeçalho da mensagem não é afetada nem alterada durante o encaminhamento de emails ou quando um serviço de alojamento usa o mesmo endereço MAIL FROM para múltiplos domínios, estas mensagens conseguem passar DKIM.

  Problemas de DKIM: o domínio que o DKIM usa para assinar uma mensagem não tem de corresponder ao domínio no endereço do remetente mostrado nos clientes de e-mail.

  Tal como o SPF, um atacante pode enviar e-mails que transmitem a autenticação DKIM (um falso negativo) ao seguir estes passos:

  • Registe um domínio (por exemplo, proseware.com) e configure o DKIM para o domínio.
  • Envie um e-mail utilizando os endereços de e-mail do remetente num domínio diferente (por exemplo, woodgrovebank.com).

• DMARC: Conforme explicado em Configurar o DMARC para validar o domínio do endereço From para remetentes de caixas de correio na nuvem, o DMARC utiliza SPF e DKIM para verificar o alinhamento entre os domínios dos endereços MAIL FROM e From. O DMARC também especifica a ação que o sistema de e-mail de destino deve aplicar às mensagens que não passam na validação DMARC e identifica para onde devem ser enviados os resultados do DMARC (tanto de aprovação como de falha).

  Como o DMARC ajuda o SPF e o DKIM: Como descrito anteriormente, o SPF não tenta estabelecer correspondência entre o domínio em MAIL FROM e os endereços do remetente. O DKIM não se preocupa com o facto de o domínio que assinou a mensagem coincidir com o domínio no endereço do remetente.

  O DMARC resolve a falta de verificações de alinhamento de domínio no SPF e DKIM confirmando que os domínios nos endereços MAIL FROM e From correspondem.

  Problemas de DMARC: os serviços legítimos que modificam mensagens em trânsito antes da entrega invalidam as verificações de SPF, DKIM e, consequentemente, de 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 o DMARC após o reencaminhamento, utilize uma entrada de permissão limitada na Lista de Permissões/Bloqueios de Inquilino ou um relay autenticado, em vez de permitir todo o domínio do remetente.

• ARC: Conforme explicado em Configurar signatários ARC de confiança, os serviços legítimos que modificam mensagens em trânsito podem utilizar o ARC para preservar as informações originais de autenticação de e-mail 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 questões 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 verificar o 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 a autenticação implícita, consulte 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 regista o resultado das verificações de autenticação por email. O valor compauth é inserido no cabeçalho Authentication-Results dos 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 no cabeçalho da mensagem Authentication-results.

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 seguintes incidem apenas nos resultados da autenticação do e-mail (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 registo SPF ou na assinatura DKIM não corresponde ao domínio no endereço do remetente.

• 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 passar na autenticação composta, porque o domínio que foi aprovado pelo SPF corresponde ao domínio no endereço do remetente:

  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 com que o DKIM assinou a mensagem corresponde ao domínio no campo De.

• Resultado: a mensagem pode ser aprovada na autenticação composta, porque o domínio na assinatura DKIM corresponde ao domínio no endereço do remetente:

  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 registo SPF ou na assinatura DKIM não corresponde ao domínio no endereço do remetente.

• 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. Os e-mails de fontes não identificadas podem ainda ser assinalados como falsificados se não passarem na autenticação composta. No entanto, este comportamento continua a ser melhor do que todos os e-mails de remetentes do domínio serem marcados como falsificados pelo Microsoft 365. Normalmente, o sistema de correio eletrónico de destino aceita mensagens de remetentes do domínio provenientes de origens não identificadas quando o SPF está configurado com uma regra de aplicação de soft fail.

  2. Descubra e inclua mais origens de e-mail para as suas mensagens. Por exemplo:

     • Servidores de e-mail no local.
     • Email enviado por um prestador de software como serviço (SaaS).
     • Email enviados a partir de um serviço de alojamento na cloud (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 utilizar 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 nas verificações 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 com DKIM o correio de saída, mesmo que o cliente não configure explicitamente o DKIM no seu domínio (assine com um domínio predefinido). 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 marca automaticamente como lixo os e-mails dos domínios dos seus clientes simplesmente por não estarem autenticados.