Configurar sealers ARC fidedignos

Email autenticação ajuda a validar o e-mail enviado de e para a sua organização do Microsoft 365 para impedir remetentes falsificados que são utilizados em e-mails empresariais comprometidos (BEC), ransomware e outros ataques de phishing.

No entanto, alguns serviços de e-mail legítimos podem modificar mensagens antes de serem entregues à sua organização do Microsoft 365. Modificar mensagens de entrada em trânsito pode e provavelmente causará as seguintes falhas de autenticação de e-mail no Microsoft 365:

  • O SPF falha devido à nova origem da mensagem (endereço IP).
  • O DKIM falha devido à modificação do conteúdo.
  • O DMARC falha devido às falhas do SPF e do DKIM.

A Cadeia De Receção Autenticada (ARC) ajuda a reduzir as falhas de autenticação de e-mail de entrada da modificação de mensagens por serviços de e-mail legítimos. O ARC preserva as informações de autenticação de e-mail originais no serviço de e-mail. Pode configurar a sua organização do Microsoft 365 para confiar no serviço que modificou a mensagem e para utilizar essas informações originais nas verificações de autenticação de e-mail.

Quando usar selantes ARC de confiança

Uma organização do Microsoft 365 só precisa de identificar sealers ARC fidedignos quando as mensagens entregues aos destinatários do Microsoft 365 são regularmente afetadas das seguintes formas:

  • O serviço intermediário modifica o cabeçalho da mensagem ou o conteúdo do e-mail.
  • As modificações da mensagem fazem com que a autenticação falhe por outros motivos (por exemplo, ao remover anexos).

Depois de um administrador adicionar um selador ARC fidedigno no portal do Defender, o Microsoft 365 utiliza as informações de autenticação de e-mail originais que o selador ARC fornece para validar as mensagens enviadas através do serviço para o Microsoft 365.

Sugestão

Adicione apenas serviços legítimos e necessários como sealers ARC fidedignos na sua organização do Microsoft 365. Adicionar apenas serviços legítimos ajuda as mensagens afetadas a passar nas verificações de autenticação por email e impede que mensagens legítimas sejam entregues na pasta de Spam, colocadas em quarentena ou rejeitadas devido a falhas na autenticação do email.

O que precisa de saber antes de começar?

  • Abra o portal Microsoft Defender em https://security.microsoft.com. Para aceder diretamente à página de definições de autenticação do Email, utilize https://security.microsoft.com/authentication.

  • Para ligar ao Exchange Online PowerShell, veja Ligar ao Exchange Online PowerShell.

  • Precisa de lhe ser atribuídas permissões antes de poder adicionar ou gerir seladores ARC de confiança. Tem as seguintes opções:

    • Microsoft Defender XDR controlo de acesso baseado em funções unificadas (RBAC) (Se Email & permissões de colaboração>do Defender para Office 365 estiver Ativo. Afeta apenas o portal do Defender, não o PowerShell): Autorização e definições/Definições de segurança/Definições de Segurança Principal (gerir) ou Autorização e definições/Definições de segurança/Definições de Segurança Principal (leitura).

    • Exchange Online permissões: associação aos grupos de funções Gestão da Organização ou Administrador de Segurança.

    • Microsoft Entra permissões: Associação no Administrador* Global. Os membros da função Administrador de Segurança não podem aceder às definições de autenticação de e-mail no portal do Defender.

      Importante

      * A Microsoft defende fortemente o princípio do menor privilégio. Atribuir apenas as permissões mínimas necessárias para realizar as respetivas tarefas ajuda a reduzir os riscos de segurança e reforça a proteção geral da sua organização. O Administrador Global é uma função altamente privilegiada que deve limitar a cenários de emergência ou quando não pode utilizar uma função diferente.

Utilizar o portal do Microsoft Defender para adicionar sealers ARC fidedignos

  1. No portal de Microsoft Defender em https://security.microsoft.com, aceda a Email & políticas de colaboração>& regras>Políticas> de ameaças Email Definições de Autenticação na secção >ARC . Em alternativa, para aceder diretamente à página de definições de autenticação Email, utilize https://security.microsoft.com/authentication.

  2. Na página Email definições de autenticação, verifique se o separador ARC está selecionado e, em seguida, selecione Adicionar.

    Sugestão

    Se os sealers Fidedignos já estiverem listados no separador ARC , selecione Editar.

  3. Na lista de opções Adicionar sealers ARC fidedignos que é aberta, introduza o domínio de assinatura fidedigno na caixa (por exemplo, fabrikam.com).

    O nome de domínio tem de corresponder ao domínio apresentado no valor d nos cabeçalhos ARC-Seal e ARC-Message-Signature nas mensagens afetadas. Utilize os seguintes métodos para ver o cabeçalho da mensagem:

    Repita este passo quantas vezes for necessário. Para remover uma entrada existente, selecione junto à entrada.

    Quando tiver terminado, na lista de opções Adicionar sealers ARC fidedignos , selecione Guardar.

Utilizar Exchange Online PowerShell para adicionar sealers ARC fidedignos

Se preferir utilizar o PowerShell para ver, adicionar ou remover sealers ARC fidedignos, ligue-se ao Exchange Online PowerShell para executar os seguintes comandos.

  • Veja os selantes ARC confiáveis existentes: Execute o seguinte comando para verificar quais os selantes ARC confiáveis que estão atualmente configurados na sua organização:

    Get-ArcConfig
    

    Se não estiverem configurados sealers ARC fidedignos, o comando não devolve resultados.

  • Adicionar ou remover sealers ARC fidedignos

    Para substituir quaisquer sealers ARC existentes pelos valores que especificar, utilize a seguinte sintaxe:

    Set-ArcConfig -Identity [TenantId\]Default -ArcTrustedSealers "Domain1","Domain2",..."DomainN"
    

    O valor TenantId\ não é necessário na sua própria organização, apenas em organizações delegadas. É um GUID que está visível em muitos URLs do portal de administração no Microsoft 365 (o tid= valor). Por exemplo, aaaabbbb-0000-cccc-1111-dddd2222eeeeee.

    Este exemplo configura "cohovineyard.com" e "tailspintoys.com" como os únicos sealers ARC fidedignos na organização.

    Set-ArcConfig -Identity Default -ArcTrustedSealers "cohovineyard.com","tailspintoys.com"
    

    Para preservar os valores existentes, certifique-se de que inclui os sealers ARC que pretende manter juntamente com os novos sealers ARC que pretende adicionar.

    Para adicionar ou remover selantes ARC sem afetar as outras entradas, consulte os exemplos em Set-ArcConfig.

Importante

O domínio do sealer arc não é o domínio da sua organização. É o domínio de assinatura do fornecedor que aparece no d= campo do cabeçalho ARC-Seal. Verifique sempre o valor real d= de um cabeçalho de mensagem antes de configurar o selador fidedigno.

Configure selantes ARC de confiança para vários fornecedores

Se a sua organização usar múltiplos serviços de email que adicionam selos ARC, ligue-se ao PowerShell do Exchange Online e adicione todos os domínios do fornecedor num único comando.

Importante

O parâmetro -ArcTrustedSealers substitui todas as entradas existentes . Para preservar os sealers fidedignos existentes, inclua-os no comando juntamente com os novos domínios que pretende adicionar.

Atenção

Adicione apenas fornecedores que utilize e confie ativamente. Adicionar sealers ARC desnecessários aumenta a superfície de ataque porque um fornecedor comprometido pode passar mensagens falsificadas através das verificações de autenticação.

Set-ArcConfig -Identity Default -ArcTrustedSealers "Domain1.com","Domain2.com","Domain3.com","Domain4.com"

Localizar o domínio do selador ARC do seu fornecedor

Use os seguintes passos para identificar o domínio correto do selante ARC:

  1. Envie um e-mail de teste através do serviço intermediário para uma caixa de correio do Microsoft 365.
  2. Abra os cabeçalhos da mensagem (no Outlook:Propriedadesdo >> da Internet ou utilize o Analisador de Cabeçalhos de Mensagens).
  3. ARC-Seal: Procure nos cabeçalhos.
  4. Anote o d= valor. Este valor é o domínio a adicionar como um selador ARC fidedigno.

Validar um selador ARC fidedigno

Se existir um selo ARC de um serviço antes de a mensagem chegar ao Microsoft 365, verifique o cabeçalho da mensagem para obter os cabeçalhos arc mais recentes após a entrega da mensagem.

No último cabeçalho ARC-Authentication-Results , procure arc=pass e oda=1. Estes valores indicam:

  • O ARC anterior foi verificado.
  • O selador ARC anterior é fidedigno.
  • O resultado anterior do passe pode ser utilizado para substituir a falha DMARC atual.

O exemplo seguinte mostra um cabeçalho ARC-Authentication-Results onde arc=pass e oda=1 confirmam um selante ARC confiável:

ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
172.17.17.17) smtp.rcpttodomain=microsoft.com
smtp.mailfrom=sampledoamin.onmicrosoft.com; dmarc=bestguesspass action=none
header.from=sampledoamin.onmicrosoft.com; dkim=none (message not signed);
arc=pass (0 oda=1 ltdi=1
spf=[1,1,smtp.mailfrom=sampledoamin.onmicrosoft.com]
dkim=[1,1,header.d=sampledoamin.onmicrosoft.com]
dmarc=[1,1,header.from=sampledoamin.onmicrosoft.com])

Para verificar se o resultado do ARC foi utilizado para substituir uma falha DMARC, procure compauth=pass e reason=130 no último cabeçalho Authentication-Results . O exemplo seguinte mostra um cabeçalho Authentication-Results onde a autenticação composta passou devido a um selante ARC confiável (reason=130):

Authentication-Results: spf=fail (sender IP is 10.10.10.10)
smtp.mailfrom=contoso.com; dkim=fail (body hash did not verify)
header.d=contoso.com;dmarc=fail action=none
header.from=contoso.com;compauth=pass reason=130

Nota

O resultado do ARC transmitido de um selador ARC fidedigno pode potencialmente substituir falhas no SPF, DKIM ou DMARC causados pela modificação da mensagem durante o trânsito. No entanto, a determinação final do spoofing baseia-se no resultado da autenticação composta (CompAuth). As mensagens que falham no ARC ainda poderão ser entregues se transmitirem avaliações de autenticação composta, DKIM, DMARC e SPF.

Diagramas de fluxo de correio do selador ARC fidedigno

Os diagramas nesta secção contrastam o fluxo de correio e o efeito nos resultados da autenticação de e-mail com e sem um selador ARC fidedigno. Em ambos os diagramas, a organização do Microsoft 365 utiliza um serviço de e-mail legítimo que modifica o correio de entrada antes de ser entregue no Microsoft 365. Esta modificação interrompe o fluxo de correio, o que pode causar falhas de autenticação de e-mail ao alterar o IP de origem e atualizar o cabeçalho da mensagem de e-mail.

O seguinte diagrama de fluxo de correio mostra o resultado sem um selante ARC de confiança:

A Contoso publica SPF, DKIM e DMARC. Um remetente que utiliza o SPF envia e-mails de dentro contoso.com para fabrikam.com e esta mensagem passa por um serviço legítimo que não é da Microsoft que modifica o endereço IP de envio no cabeçalho do e-mail. Durante a verificação de DNS no Microsoft 365, a mensagem falha no SPF devido ao IP alterado e falha no DKIM porque o conteúdo foi modificado. O DMARC falha devido às falhas do SPF e do DKIM. A mensagem é entregue na pasta Email de Lixo, colocada em quarentena ou rejeitada.

O seguinte diagrama de fluxo de correio mostra o resultado com um selante ARC de confiança:

A Contoso publica SPF, DKIM e DMARC, mas também configura os sealers ARC fidedignos necessários. Um remetente que utiliza o SPF envia e-mails de dentro contoso.com para fabrikam.com e esta mensagem passa por um serviço legítimo que não é da Microsoft que modifica o endereço IP de envio no cabeçalho do e-mail. O serviço utiliza a selagem ARC e, uma vez que o serviço é definido como um selador ARC fidedigno no Microsoft 365, a modificação é aceite. O SPF falha no novo endereço IP. O DKIM falha devido à modificação do conteúdo. O DMARC falha devido às falhas anteriores. No entanto, o ARC reconhece as modificações, emite um Pass e aceita as alterações. Spoof também recebe um passe. A mensagem é entregue na Caixa de Entrada.

Cenários comuns de falha do ARC

Quando o ARC não funcionar conforme esperado, utilize a seguinte referência de resolução de problemas.

Referência rápida: sintomas de falha do ARC

A tabela seguinte lista os sintomas comuns de falha do ARC, as suas prováveis causas e as resoluções recomendadas.

Sintoma Causa provável Resolução
arc=fail em ARC-Authentication-Results Domínio do sealer arc não adicionado como fidedigno ou domínio errado configurado. Verifique o d= valor no cabeçalho do ARC-Seal e adicione-o aos sealers fidedignos.
arc=none em ARC-Authentication-Results O serviço intermediário não está a adicionar cabeçalhos ARC. Contacte o fornecedor para ativar a assinatura arc.
oda=0 apesar de arc=pass O domínio do sealer arc não está na lista de seladores fidedignos. Adicione o domínio correto com Set-ArcConfig.
compauth=fail reason=000 apesar do selador fidedigno Falha na validação da cadeia ARC (cadeia quebrada). Verifique se existem problemas de integridade da cadeia (veja Cadeia ARC quebrada).
dmarc=fail e não existem cabeçalhos ARC A mensagem não passou por um intermediário compatível com ARC. O ARC não pode ajudar. Corrija o SPF/DKIM na origem.
Mensagens colocadas em quarentena apesar da passagem do ARC A ação de política antiss spam substitui o resultado do ARC. Reveja a política de quarentena. O ARC substitui apenas o DMARC e não a filtragem de spam.

Domínio do sealer ARC incorreto configurado

Problema: adicionou o seu próprio domínio (por exemplo, contoso.com) em vez do domínio de selagem ARC do fornecedor.

Os cabeçalhos das mensagens mostram o domínio real de selagem ARC do fornecedor. Verifique o valor d= no cabeçalho ARC-Seal para identificar o domínio correto a configurar como selador fidedigno:

ARC-Seal: i=1; a=rsa-sha256; d=pphosted.com; s=arcselector;
  cv=none; b=<signature>

Mas quando executas o Get-ArcConfig no Exchange Online PowerShell, o resultado mostra que o teu próprio domínio está configurado em vez do domínio de selagem ARC do fornecedor:

ArcTrustedSealers : {contoso.com}

Resolução: utilize o domínio de selagem ARC do fornecedor. Por exemplo:

Set-ArcConfig -Identity Default -ArcTrustedSealers "pphosted.com"

O serviço intermediário não está a adicionar cabeçalhos ARC

Problema: as mensagens passam pelo gateway, mas não contêm cabeçalhos ARC. O serviço intermediário não suporta o ARC ou o ARC não está ativado.

Diagnóstico: procurar cabeçalhos de mensagens para ARC-Seal:. Se não existir nenhum cabeçalho ARC-Seal, o intermediário não está a selar.

Resolução: ative o início de sessão do ARC na consola de gestão do fornecedor:

Fornecedor Como ativar o ARC
Ponto de verificação linguística Ative o ARC no Email Protection> Email definições deSaída de >.
Mimecast Ativeatravés de Definições de Políticas> de> de >>.
Barracuda O ARC está ativado por predefinição na Defesa do Gateway de Email. Verifique em Definições>de Entrada Anti-Phishing.
Sophos Ative noArc> de > do > Email.

Importante

Se o seu fornecedor não suportar o ARC, considere soluções alternativas:

Cadeia ARC quebrada (cv=fail)

Problema: a validação da cadeia ARC mostra cv=fail, o que significa que não foi possível verificar um selo ARC anterior na cadeia.

O exemplo seguinte mostra um cabeçalho ARC-Seal onde cv=fail indica uma cadeia ARC quebrada:

ARC-Seal: i=2; a=rsa-sha256; d=mimecast.com; s=arc-2018;
  cv=fail; b=<signature>

Normalmente, esta falha tem as seguintes causas:

  • Um intermediário anterior modificou a mensagem depois de adicionar o selo ARC (quebrando a cadeia).
  • Os problemas de DNS impediram a pesquisa da chave pública do selador ARC.
  • A chave pública do ARC foi rodada, mas os registos DNS em cache não expiraram.

Resolução: utilize os seguintes passos para diagnosticar e corrigir a cadeia quebrada:

  1. Verifique o cv= valor em cada instância do ARC (i=1, i=2, etc.) para identificar onde a cadeia se partiu.
  2. Verifique se a chave pública do selador ARC está publicada no DNS. Por exemplo, utilize nslookup -type=TXT arcselector._domainkey.pphosted.com para consultar o registo de chave.
  3. Se o DNS não devolver nenhum resultado, contacte o fornecedor sobre a publicação da chave ARC.
  4. Se a cadeia se quebrar entre dois serviços que controla, certifique-se de que as modificações de mensagens ocorrem antes da selagem do ARC, não depois.

O ARC passa, mas as mensagens ainda vão para o Email de Lixo

Problema: a validação do ARC é aprovada (arc=pass, compauth=pass reason=130), mas as mensagens continuam a ser entregues na pasta Email de Lixo.

Explicação: o ARC substitui apenas as falhas de autenticação DMARC. Não ignora:

  • Filtragem de spam baseada em conteúdo (valores SCL da análise de conteúdo).
  • Filtragem de e-mail em massa (limiar BCL).
  • Ações de política antiss spam.
  • Ações de regras de fluxo de correio.
  • Listas de remetentes seguros/bloqueados.

Diagnóstico: Reveja o cabeçalho X-Forefront-Antispam-Report para determinar se a filtragem de spam baseada no conteúdo tenha feito com que a mensagem fosse para Lixo Eletrónico, independentemente de ARC:

X-Forefront-Antispam-Report: CIP:10.10.10.10; CTRY:US; LANG:en; SCL:5;
  SFV:SPM; H:mail.fabrikam.com; PTR:mail.fabrikam.com; CAT:SPM;

Se CAT:SPM ou SCL:5 mais, a mensagem foi filtrada como spam pela filtragem de conteúdos, que é independente do ARC.

Resolução: experimente as seguintes opções para resolver a filtragem de spam:

CompAuth reason codes reference (Referência de códigos de motivos compAuth)

A tabela seguinte resume os códigos de motivo da autenticação composta (CompAuth) que aparecem no cabeçalho Authentication-Results.

Código do motivo Descrição
000 Falha na autenticação composta da mensagem (falha explícita).
001 Falha na autenticação composta da mensagem (falha implícita).
002 A mensagem tem um desvio SPF/DKIM explícito que impede a avaliação de autenticação composta.
010 A mensagem foi excluída da filtragem DMARC (por exemplo, enviada para si próprio).
1xx Falha na mensagem DMARC com a ação determinada pela política DMARC.
130 Substituição do ARC: autenticação composta transmitida devido a um selador ARC fidedigno.
2xx Autenticação composta de passagem recuperável de mensagens (a origem era suspeita).
3xx Autenticação composta não verificada.
4xx A mensagem ignorou a autenticação composta.

Sugestão

Depois de adicionar ou modificar os sealers ARC fidedignos, aguarde até 30 minutos para que a configuração entre em vigor. Teste com novas mensagens enviadas após este período.

Passos seguintes

Verifique os cabeçalhos do ARC com o Analisador de Cabeçalhos de Mensagens em https://mha.azurewebsites.net.

Configura SPF, DKIM e DMARC para o teu domínio.

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