Configurar DMARC para validar o domínio do endereço de origem para remetentes na nuvem

Dica

Sabia que pode experimentar as funcionalidades no Microsoft Defender para Office 365 Plano 2 gratuitamente? Utilize a versão de avaliação do Defender para Office 365 de 90 dias no hub de avaliações do portal do Microsoft Defender. Saiba mais sobre quem pode inscrever-se e os termos de avaliação em Experimentar Microsoft Defender para Office 365.

A Autenticação de Mensagens baseada em domínio, Relatórios e Conformidade (DMARC) é um método de autenticação de e-mail para validar o correio enviado da sua organização do Microsoft 365. Esta validação ajuda a impedir remetentes falsificados que são utilizados em e-mails empresariais comprometidos (BEC), ransomware e outros ataques de phishing.

Pode ativar o DMARC para um domínio ao criar um registo TXT no DNS. A validação DMARC de uma mensagem de e-mail envolve os seguintes elementos:

• Verifique se os domínios nos endereços MAIL FROM e FROM estão alinhados: O SPF e o DKIM não requerem que os domínios nos seguintes endereços de e-mail "alinhem" (corresponder):

  • O endereço MAIL FROM: o endereço de email utilizado na transmissão da mensagem entre servidores de email SMTP. Este endereço também é conhecido como endereço 5321.MailFrom , remetente P1 ou remetente de envelope.
  • O endereço De: o endereço de email no campo de cabeçalho De, exibido como o remetente da mensagem nos clientes de email. Este endereço também é conhecido como o 5322.From endereço ou remetente P2.

  Para obter mais informações sobre como estes endereços de e-mail podem estar em domínios diferentes e utilizados para spoofing, consulte Por que motivo o e-mail da Internet precisa de autenticação.

  • O DMARC utiliza o resultado do SPF para verificar ambas as seguintes condições:

    • A mensagem veio de uma origem autorizada para o domínio utilizado no endereço MAIL FROM (o requisito básico do SPF).
    • Os domínios nos endereços MAIL FROM e From na mensagem estão alinhados. Esse resultado exige que os remetentes válidos da mensagem estejam no domínio do endereço De.

  • O DMARC utiliza o resultado do DKIM para verificar se o domínio que assinou a mensagem (o valor d= em um campo de cabeçalho DKIM-Signature, conforme validado pelo valor do seletor s=) está alinhado com o domínio no endereço From.

  Uma mensagem passa DMARC se uma ou ambas as verificações de SPF ou DKIM descritas passarem. Uma mensagem falha DMARC se ambas as verificações de SPF e DKIM descritas falharem.

• Política DMARC: especifica o que fazer com mensagens que falham DMARC (rejeitar, colocar em quarentena ou sem instruções).

• Relatórios DMARC: especifica para onde enviar relatórios:

  • Relatórios agregados (um resumo periódico dos resultados DMARC positivos e negativos).
  • Relatórios forenses (também conhecidos como Relatórios de falha; resultados de falha DMARC quase imediatos semelhantes a um relatório de entrega não entregue ou mensagem de devolução).

Antes de começar, eis o que precisa de saber sobre o DMARC no Microsoft 365 com base no seu domínio de e-mail:

• Se utilizar apenas o domínio do Endereço de Encaminhamento do Microsoft Online Email (MOERA) para e-mail (por exemplo, contoso.onmicrosoft.com): Embora o SPF e o DKIM já estejam configurados para o seu domínio *.onmicrosoft.com, tem de criar o registo TXT DMARC para o domínio *.onmicrosoft.com no Centro de administração do Microsoft 365. Para obter instruções, consulte Usar o Centro de administração do Microsoft 365 para adicionar registros TXT DMARC para domínios *.onmicrosoft.com em Microsoft 365. Para obter mais informações sobre os domínios *.onmicrosoft.com, consulte Por que motivo tenho um domínio "onmicrosoft.com"?

• Se utilizar um ou mais domínios personalizados para e-mail (por exemplo, contoso.com): se ainda não o fez, terá de configurar o SPF para todos os domínios e subdomínios personalizados que utiliza para o e-mail. Você também precisa configurar a assinatura DKIM usando o domínio ou subdomínio personalizado para que o domínio usado para assinar a mensagem fique alinhado com o domínio no endereço De. Para obter instruções, 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

  Depois disso, também tem de configurar os registos TXT DMARC para os seus domínios personalizados, conforme descrito neste artigo. Também tem as seguintes considerações:

  • Subdomínios:

    • Para serviços de e-mail que não estejam sob o seu controlo direto (por exemplo, serviços de e-mail em massa), utilize um subdomínio (por exemplo, marketing.contoso.com) em vez do seu domínio de e-mail principal (por exemplo, contoso.com). Não quer que os problemas com o correio enviado a partir desses serviços de e-mail afetem a reputação dos e-mails enviados pelos utilizadores no seu domínio de e-mail principal. Para obter mais informações sobre como adicionar subdomínios, consulte Posso adicionar subdomínios personalizados ou múltiplos domínios ao Microsoft 365?.
    • Ao contrário do SPF e do DKIM, o registo TXT DMARC de um domínio abrange automaticamente todos os subdomínios (incluindo subdomínios inexistentes) que não têm o seu próprio registo TXT DMARC. Por outras palavras, pode interromper a herança de DMARC num subdomínio ao criar um registo TXT DMARC nesse subdomínio. No entanto, cada subdomínio requer um registo SPF e DKIM para DMARC.

  • Se tiver domínios registados, mas não utilizados: se tiver domínios registados que não são utilizados para e-mail ou qualquer coisa (também conhecidos como domínios estacionados), configure os registos TXT DMARC nesses domínios para especificar que nenhum e-mail deve vir desses domínios. Esta diretiva inclui o domínio *.onmicrosoft.com se não estiver a utilizá-lo para e-mail.

• As verificações de DMARC para emails recebidos podem precisar de ajuda: se você usa um serviço de e-mail que modifica mensagens em trânsito antes de entregá-las ao Microsoft 365, talvez consiga identificar o serviço como um selador ARC confiável. Os sealers ARC fidedignos impedem que as mensagens modificadas falhem automaticamente nas verificações DMARC. Para obter mais informações, consulte As Próximas Etapas.

O resto deste artigo abrange a criação de registos DMARC TXT, a implementação gradual para domínios personalizados e o processamento de DMARC de entrada no Microsoft 365.

Dica

Para criar o registro TXT DMARC para seu domínio *.onmicrosoft.com no Centro de administração do Microsoft 365, consulte Usar o Centro de administração do Microsoft 365 para adicionar registros TXT DMARC para domínios *.onmicrosoft.com em Microsoft 365.

Não existem portais de administração nem cmdlets do PowerShell no Microsoft 365 para gerir registos TXT DMARC nos seus domínios personalizados . Em vez disso, cria o registo TXT DMARC na sua entidade de registo de domínios ou no serviço de alojamento DNS (muitas vezes a mesma empresa).

São fornecidas instruções para criar o registo TXT de prova de propriedade do domínio para o Microsoft 365 em muitas entidades de registo de domínios. Pode utilizar estas instruções como ponto de partida para criar registos TXT DMARC. Para obter mais informações, veja Adicionar registos DNS para ligar o seu domínio.

Se não estiver familiarizado com a configuração de DNS, contacte a entidade de registo de domínios e peça ajuda.

Sintaxe para registros TXT do DMARC

Os registos TXT DMARC são descritos exaustivamente no RFC 7489.

A sintaxe básica do registo TXT DMARC para um domínio no Microsoft 365 é:

Nome do anfitrião: _dmarc
Valor TXT: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

ou

Nome do anfitrião: _dmarc
Valor TXT: v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

Por exemplo:

Nome do anfitrião: _dmarc
Valor TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

• O valor _dmarc do nome do anfitrião é obrigatório.

• v=DMARC1; identifica o registo TXT como um registo TXT DMARC.

• Política DMARC: informa ao sistema de email de destino o que fazer com mensagens que falham em DMARC (rejeitar, colocar em quarentena ou nenhuma ação):

  • p=reject: as mensagens devem ser rejeitadas. O que realmente acontece à mensagem depende do sistema de e-mail de destino, mas as mensagens são normalmente eliminadas.
  • p=quarantine: As mensagens devem ser aceitas, mas marcadas. O que realmente acontece à mensagem depende do sistema de e-mail de destino. Por exemplo, a mensagem pode ser colocada em quarentena como spam, entregue na pasta Email de Lixo ou entregue na Caixa de Entrada com um identificador adicionado ao assunto ou corpo da mensagem.
  • p=none: nenhuma ação sugerida para mensagens que falhem DMARC. O que acontece à mensagem depende das funcionalidades de proteção de e-mail no sistema de e-mail de destino. Use esse valor para testar e ajustar a política DMARC.

  Dica

  O email de saída de domínios no Microsoft 365 que não passar nas verificações de DMARC no serviço de email de destino será encaminhado pelo pool de entrega de alto risco para mensagens de saída se a política de DMARC do domínio for p=reject ou p=quarantine. Não há substituição para este comportamento.

• Percentagem de correio DMARC falhado sujeito à política DMARC: indica ao sistema de e-mail de destino quantas mensagens que falham DMARC (percentagem) obtêm a política DMARC aplicada às mesmas. Por exemplo, pct=100 significa que todas as mensagens que falham DMARC obtêm a política DMARC aplicada às mesmas. Você usa valores inferiores a 100 para testar e ajustar a política DMARC. Se não utilizar pct=, o valor predefinido é pct=100.

• Relatórios DMARC:

  • URI do relatório de agregação DMARC: o rua=mailto: valor identifica para onde enviar o relatório de Agregação DMARC. O relatório Aggregate tem as seguintes propriedades:

    • Normalmente, as mensagens de e-mail que contêm o Relatório agregado são enviadas uma vez por dia (o relatório contém os resultados DMARC do dia anterior). A linha Assunto contém o domínio de destino que enviou o relatório (Submitter) e o domínio de origem para os resultados DMARC (Domínio de Relatório).
    • Os dados DMARC estão num anexo de e-mail XML que provavelmente é comprimido por GZIP. O esquema XML é definido no Apêndice C de RFC 7489. O relatório contém as seguintes informações:
      • Os endereços IP de servidores ou serviços que enviam correio com o seu domínio.
      • Se os servidores ou serviços passam ou falham na autenticação DMARC.
      • As ações que a DMARC executa no correio que falha na autenticação DMARC (com base na política DMARC).

    Dica

    As informações no relatório Agregado podem ser vastas e difíceis de analisar. Para ajudar a compreender os dados, pode utilizar as seguintes opções para relatórios DMARC:

    • Crie automatização com o PowerShell ou Microsoft Power BI.
    • Utilizar um serviço externo. Para obter uma lista de serviços, procure DMARC no Catálogo da Associação de Segurança Inteligente da Microsoft (MISA) em https://www.microsoft.com/misapartnercatalog. Os serviços de relatório do DMARC descrevem quaisquer valores personalizados exigidos no registro TXT do DMARC.

  • URI do relatório forense DMARC: o ruf=mailto: valor identifica para onde enviar o relatório forense DMARC (também conhecido como o relatório de falha DMARC). O relatório é gerado e enviado imediatamente após uma falha DMARC, como um relatório de entrega sem êxito (também conhecido como NDR ou mensagem de devolução).

  Dica

  Você deve analisar regularmente os relatórios agregados do DMARC para monitorar de onde vêm os e-mails dos seus domínios e verificar falhas não intencionais de DMARC (falsos positivos).

  Os sistemas de e-mail de destino individuais são responsáveis pelo envio de relatórios DMARC de volta para si. A quantidade e variedade de relatórios DMARC variam da mesma forma que o volume e a variedade de e-mails enviados pela sua organização variam. Por exemplo, espere um menor volume de correio durante os feriados e um maior volume de correio durante eventos organizacionais. É melhor designar pessoas específicas para monitorizar relatórios DMARC e utilizar uma caixa de correio específica ou um Grupo do Microsoft 365 para receber os relatórios DMARC (não entregar os relatórios na caixa de correio de um utilizador).

Para obter mais informações sobre o DMARC, utilize os seguintes recursos:

• A Série de treinamento DMARC do M³AAWG (Mensagens, Malware, Grupo de Trabalho Antiabuso Móvel).
• Informações em DMARC.org.

Utilize o Centro de administração do Microsoft 365 para adicionar registos TXT DMARC para domínios *.onmicrosoft.com no Microsoft 365

Execute as etapas a seguir para adicionar um registro TXT DMARC para seu domínio *.onmicrosoft.com no Centro de administração do Microsoft 365.

1. No centro de administração do Microsoft 365 em https://admin.microsoft.com, selecione Mostrar tudo>Configurações>Domínios. Em alternativa, para aceder diretamente à página Domínios , utilize https://admin.microsoft.com/Adminportal/Home#/Domains.

2. Na página Domínios, selecione o domínio *.onmicrosoft.com da lista ao clicar em qualquer parte da linha que não seja a caixa de marcar junto ao nome de domínio.

3. Na página de detalhes do domínio que é aberta, selecione o separador Registos DNS .

4. No separador Registos DNS , selecione Adicionar registo.

5. Na lista de opções Adicionar um registo DNS personalizado que é aberta, configure as seguintes definições:

   • Tipo: verifique se TXT (Texto) está selecionado.

   • Nome TXT: introduza _dmarc.

   • Valor TXT: introduza v=DMARC1; p=reject.

     Dica

     Para especificar destinos para os relatórios DMARC Aggregate e DMARC Forensic, use a sintaxe v=DMARC1; p=reject; rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. Por exemplo, v=DMARC1; p=reject; rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

     Os fornecedores de relatórios DMARC no Catálogo https://www.microsoft.com/misapartnercatalog MISA facilitam a visualização e interpretação dos resultados DMARC.

   • TTL: verifique se está selecionada uma hora .

   Quando terminar, na lista de opções Adicionar um registo DNS personalizado , selecione Guardar.

Configurar o DMARC para domínios personalizados ativos no Microsoft 365

Dica

Antes de configurar o DMARC para domínios personalizados ou subdomínios, você precisa criar registros TXT SPF e configurar a assinatura de DKIM para todos os domínios e subdomínios personalizados usados para enviar emails em Microsoft 365.

Recomenda-se uma abordagem gradual para configurar o DMARC para os seus domínios do Microsoft 365. O objetivo é aceder a uma p=reject política DMARC para todos os seus domínios e subdomínios personalizados, mas tem de testar e verificar ao longo do caminho para impedir que os sistemas de e-mail de destino rejeitem um bom correio devido a falhas não intencionais do DMARC.

O seu plano de implementação DMARC deve utilizar os seguintes passos. Comece com um domínio ou subdomínio com volume de correio baixo e/ou menos potenciais origens de e-mail (menos probabilidade de o correio legítimo de origens desconhecidas ser bloqueado):

1. Comece com uma política DMARC de p=none e monitorize os resultados do domínio. Por exemplo:

   Registro TXT do DMARC para marketing.contoso.com:

   Nome do anfitrião: _dmarc
   Valor TXT: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Os relatórios DMARC Aggregate e DMARC Forensic fornecem os números e fontes de mensagens que passam e falham nas verificações DMARC. Pode ver quanto do seu tráfego de correio legítimo é ou não abrangido pelo DMARC e resolver problemas. Também pode ver quantas mensagens fraudulentas estão a ser enviadas e de onde são enviadas.

2. Aumente a política DMARC para p=quarantine e monitorize os resultados do domínio.

   Após monitorar por tempo suficiente os efeitos de p=none, você pode aumentar a política DMARC para p=quarantine no domínio. Por exemplo:

   Registro TXT do DMARC para marketing.contoso.com:

   Nome do anfitrião: _dmarc
   Valor TXT: v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Também pode utilizar o pct= valor para afetar gradualmente mais mensagens e verificar os resultados. Por exemplo, você pode mover em incrementos como os seguintes:

   • pct=10
   • pct=25
   • pct=50
   • pct=75
   • pct=100

3. Aumente a política DMARC para p=reject e monitorize os resultados do domínio.

   Após monitorar por tempo suficiente os efeitos de p=quarantine, você pode aumentar a política DMARC para p=reject no domínio. Por exemplo:

   Registro TXT do DMARC para marketing.contoso.com:

   Nome do anfitrião: _dmarc
   Valor TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Também pode utilizar o pct= valor para afetar gradualmente mais mensagens e verificar os resultados.

4. Repita os três passos anteriores para os restantes subdomínios de aumento de volume e/ou complexidade, guardando o domínio principal para o último.

   Dica

   Bloquear emails legítimos em qualquer volume significativo é inaceitável para os usuários, mas é quase inevitável obter alguns falsos positivos. Lide lentamente e metodicamente com problemas que são revelados nos relatórios DMARC. Os fornecedores de relatórios DMARC no Catálogo https://www.microsoft.com/misapartnercatalog MISA facilitam a visualização e interpretação dos resultados DMARC.

5. Os subdomínios herdam as configurações de registro TXT DMARC do domínio pai, que você pode substituir com um registro TXT DMARC separado no subdomínio. Quando terminar de configurar o DMARC num domínio e em todos os subdomínios e as definições DMARC forem efetivamente idênticas para o domínio principal e todos os subdomínios, pode eliminar os registos TXT DMARC nos subdomínios e confiar no único registo TXT DMARC no domínio principal.

Registos TXT DMARC para domínios estacionados no Microsoft 365

Dica

O registo TXT SPF recomendado para domínios estacionados que não enviam correio está descrito nos registos TXT do SPF para domínios de nuvem personalizados. Conforme descrito em Configurar o DKIM para assinar correio a partir do seu domínio na nuvem, os registos CNAME de DKIM não são recomendados para domínios estacionados.

1. Se registou domínios dos quais ninguém na Internet deve esperar receber correio, crie o seguinte registo TXT DMARC na entidade de registo de domínios do domínio:

   Nome do anfitrião: _dmarc
   Valor TXT: v=DMARC1; p=reject;

   • O pct= valor não está incluído, porque o valor predefinido é pct=100.
   • Os valores rua=mailto: e ruf=mailto: podem não ser necessários neste cenário, porque nenhum e-mail válido deveria vir de remetentes desse domínio.

2. Se não utilizar o domínio *.onmicrosoft.com para enviar correio, também terá de adicionar o registo TXT DMARC para o seu domínio *.onmicrosoft.com.

DMARC para correio de entrada no Microsoft 365

Os recursos e comportamentos a seguir influenciam como Microsoft 365 avalia o DMARC para mensagens de entrada e se os relatórios DMARC são enviados.

• As seguintes funcionalidades de segurança incorporadas para todas as caixas de correio na nuvem afetam as verificações DMARC no correio recebido:

  • Se a inteligência contra falsificação está ativada ou desativada na política antiphishing que verificou a mensagem. A desativação da inteligência contra falsificação desativa a proteção implícita contra falsificação somente nas verificações de autenticação composta.
  • Se a configuração Respeitar a política do registro DMARC quando a mensagem for detectada como falsificada está ativada ou desativada na política anti-phishing que verificou a mensagem, e as ações especificadas com base na política DMARC do domínio de origem (p=quarantine ou p=reject no registro TXT de DMARC).

  Para obter informações completas, consulte Proteção contra falsificação e políticas DMARC do remetente.

  Para ver os valores padrão dessas configurações nas políticas anti-phishing, consulte os valores das configurações na tabela em Configurações da política anti-phishing para todas as caixas de correio na nuvem.

• O Microsoft 365 não envia relatórios forenses DMARC (também conhecidos como relatórios de Falha DMARC), mesmo que exista um endereço válido ruf=mailto: no registo TXT DMARC do domínio de origem.

• O Microsoft 365 envia relatórios de Agregação DMARC para todos os domínios com um endereço válido rua=mailto: nos registos TXT DMARC, desde que o registo MX do domínio do Microsoft 365 aponte diretamente para o Microsoft 365.

  Se você encaminhar emails da Internet por meio de um serviço ou dispositivo que não seja da Microsoft antes da entrega ao Microsoft 365 (o registro MX aponta para outro lugar que não o Microsoft 365), os relatórios agregados de DMARC não serão enviados. Esta limitação inclui cenários híbridos em que o correio é entregue no ambiente no local antes de ser encaminhado para o Microsoft 365 através de um conector.

  Dica

  Quando um dispositivo ou serviço que não seja da Microsoft estiver na frente do fluxo de emails para o Microsoft 365, a Filtragem Avançada para Conectores (também conhecida como ignorar listagem) identifica corretamente a origem dos emails da Internet para SPF, DKIM (se o serviço modificar as mensagens) e para a validação de DMARC.

Resolução de problemas do DMARC

Para obter uma tabela de referência rápida de erros, causas e correções DMARC, consulte Resolver problemas de autenticação de e-mail no Microsoft 365.

Esta seção ajuda você a diagnosticar e resolver falhas comuns de DMARC, entender como o Microsoft 365 lida com diferentes políticas de DMARC e interpretar relatórios DMARC agregados e forenses.

Diagnóstico de falha de alinhamento

Conforme descrito em Configurar DMARC para validar o domínio do endereço De para remetentes na nuvem, uma mensagem será aprovada no DMARC se pelo menos uma verificação de alinhamento for aprovada (SPF ou DKIM). Uma mensagem falha DMARC apenas se ambas as verificações de alinhamento falharem.

Modos de alinhamento

As tags aspf (SPF) e adkim (DKIM) no registro TXT do DMARC determinam quão estritamente o domínio do remetente deve corresponder ao domínio autenticado. Ambas são opcionais e predefinidas para r (relaxadas), mas s (estritas) também estão disponíveis. O exemplo a seguir mostra um registro TXT DMARC que usa alinhamento SPF estrito (aspf=s) e alinhamento de DKIM relaxado (adkim=r):

Hostname: _dmarc
TXT value: v=DMARC1; p=reject; aspf=s; adkim=r; pct=100; rua=mailto:dmarc@contoso.com

• Relaxado (r, predefinição): os domínios organizacionais (domínios de raiz) têm de corresponder. São permitidos subdomínios.
• Estrito (s): os FQDNs devem corresponder exatamente. Não existem correspondências de subdomínios.

Observação

As aspf etiquetas e adkim são independentes. Pode utilizar diferentes modos para cada um, conforme mostrado no exemplo. Uma mensagem é aprovada no DMARC se qualquer uma das verificações de alinhamento for bem-sucedida, portanto uma falha estrita em uma das verificações não importa se a outra verificação passar com alinhamento flexível.

Exemplos:

Endereço de remetente	Endereço MAIL FROM /DKIM-Signature d=	Relaxado (r)	Estrito (s)
user@contoso.com	contoso.com	✅ Aprovado	✅ Aprovado
user@contoso.com	bounces.contoso.com	✅ Aprovado	❌ Falha
user@marketing.contoso.com	contoso.com	✅ Aprovado	❌ Falha
user@contoso.com	contoso.onmicrosoft.com	❌ Falha	❌ Falha
user@contoso.com	adatum.net	❌ Falha	❌ Falha

Cenários comuns de falha de alinhamento

A tabela a seguir lista cenários comuns de falha de alinhamento DMARC, seus sintomas, causas raiz e correções recomendadas.

Cenário	Sintoma	Causa raiz	Resolução
O serviço que não é da Microsoft envia em seu nome	SPF passa para adatum.com mas DMARC falha	MAIL FROM utiliza o domínio do serviço (por exemplo, bounce.adatum.com) e nenhuma assinatura DKIM com seu domínio	Configure a assinatura DKIM com seu domínio no serviço, ou altere MAIL FROM para seu domínio/subdomínio
Encaminhamento automático do Microsoft 365	DMARC falha no destino	O encaminhamento altera o remetente do envelope; A assinatura DKIM pode ser interrompida	Use seladores confiáveis do ARC no destino ou use o DKIM (sobreviverá ao encaminhamento se o corpo não for modificado)
O subdomínio envia com alinhamento estrito	aspf=s provoca falhas para remetentes de subdomínios	MAIL FROM é sub.contoso.com, mas De é contoso.com	Altere para aspf=r (relaxado) ou certifique-se de que o endereço do remetente corresponda ao subdomínio
Incompatibilidade no domínio de assinatura DKIM	O DKIM passa, mas o DMARC continua a falhar	O valor DKIM d= (por exemplo, adatum.com) não corresponde ao domínio From (contoso.com)	Configurar a assinatura DKIM personalizada no serviço usando seu domínio
Caixa de correio partilhada ou grupo de distribuição	O DMARC falha intermitentemente	Responder ou redirecionar as alterações de endereços de envelope	Verifique se o DKIM está intacto; considerar o ARC para serviços intermediários

Diagnosticar falhas de alinhamento a partir de cabeçalhos de mensagens

Etapa 1: abra os cabeçalhos da mensagem e localize o cabeçalho Autenticação-Resultados de Microsoft 365. O exemplo a seguir mostra um cabeçalho Authentication-Results em que SPF e DKIM são aprovados individualmente, mas DMARC falha porque nenhum dos domínios está alinhado com o domínio do endereço From:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Passo 2: identificar a falha de alinhamento:

Verificar	Campo do cabeçalho	Valor no exemplo	Alinha-se com From (contoso.com)?
Alinhamento SPF	smtp.mailfrom=	bounces.adatum.com	❌ Não (domínio de organização diferente)
Alinhamento de DKIM	header.d=	adatum.com	❌ Não (domínio de organização diferente)
Resultado DMARC	dmarc=	fail	Ambas as verificações falharam

Passo 3: determinar a correção ao responder às seguintes perguntas:

1. Você pode alterar o endereço MAIL FROM para seu domínio (por exemplo, bounces.contoso.com em vez de bounces.adatum.com)?
   • Sim: Configure a alteração MAIL FROM no serviço para corrigir o alinhamento do SPF.
   • Não: utilize antes o alinhamento de DKIM (ir para o passo 2).
2. O serviço pode assinar com o seu domínio (d=contoso.com)?
   • Sim: Configurar a assinatura DKIM personalizada no serviço.
   • Não: Considere uma estratégia de subdomínio:
     • Enviar a partir de um subdomínio (por exemplo, sub.contoso.com).
     • Publique um registo DMARC separado para esse subdomínio.
     • Configure o serviço para assinar DKIM com d=sub.contoso.com.

Verificar o alinhamento de mensagens recentes no PowerShell

Ligue-se ao Exchange Online PowerShell e execute os seguintes comandos:

# Get recent messages and check authentication results
$messages = Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -PageSize 100

foreach ($msg in $messages) {
    $details = Get-MessageTraceDetail -MessageTraceId $msg.MessageTraceId -RecipientAddress $msg.RecipientAddress
    $authEvent = $details | Where-Object { $_.Event -eq "Receive" }
    if ($authEvent.Detail -match "dmarc=fail") {
        Write-Output "DMARC FAIL: From=$($msg.SenderAddress), Subject=$($msg.Subject)"
    }
}

Efeito de política DMARC no comportamento do Microsoft 365

Conforme descrito em DMARC para correio de entrada, o comportamento do Microsoft 365 depende da definição de política de registo Honor DMARC . Para obter detalhes completos, consulte Proteção contra falsificação e políticas de DMARC do remetente.

O resumo seguinte mostra o comportamento geral das mensagens de entrada que falham no DMARC quando a política de registo Honor DMARC está Ativada (recomendado):

Política DMARC do remetente	Destino da mensagem	Resultados da autenticação	CompAuth
p=none	Nenhuma ação específica de DMARC. Ainda se aplica outra filtragem.	dmarc=fail action=none	Com base na autenticação composta (SPF, DKIM, inteligência contra falsificação)
p=quarantine	Pasta de Email de lixo (configurável para quarentena)	dmarc=fail action=quarantine	compauth=fail reason=100
p=reject	Rejeitado durante o SMTP (550 5.7.1)	dmarc=fail action=oreject	compauth=fail reason=100

Cuidado

Tenha cuidado ao substituir p=reject para remetentes legítimos. Se a sua organização receber legitimamente correio de um remetente cujo DMARC falhe (por exemplo, correio reencaminhado, listas de correio), utilize uma destas abordagens:

• Configure o remetente como um selador ARC confiável (preferencial).
• Crie uma regra de fluxo de correio com condições específicas (ip do remetente + domínio do remetente) para ignorar a filtragem de spam.
• Adicione uma entrada de permissão na Lista de Permissões/Bloqueios do Inquilino (temporária, expira dentro de 30 dias).

Valores de ação do DMARC em Authentication-Results

No cabeçalho Authentication-Results(Resultados da Autenticação ), poderá ver estes valores de ação DMARC:

Valor da ação	Significado
action=none	O remetente publicou p=none; nenhuma ação foi tomada
action=quarantine	O remetente publicou p=quarantine; mensagem colocada em quarentena ou na Lixeira
action=oreject	Remetente publicou p=reject; mensagem rejeitada ("o" = origem)
action=pct.quarantine	O remetente publicou p=quarantine com pct= inferior a 100; esta mensagem estava incluída na porcentagem amostrada
action=pct.reject	O remetente publicou p=reject com pct= inferior a 100; esta mensagem estava incluída na porcentagem amostrada

Interpretação do relatório DMARC

Esta seção ajuda você a interpretar os relatórios agregados do DMARC e os relatórios forenses que os servidores de recebimento enviam aos seus endereços rua e ruf. Para obter informações sobre como configurar os valores rua e ruf no registro TXT DMARC, consulte Sintaxe para registros TXT DMARC.

Relatórios agregados

O exemplo seguinte mostra a estrutura XML de um relatório agregado:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>microsoft.com</org_name>           <!-- Reporting organization -->
    <email>dmarceng@microsoft.com</email>
    <report_id>unique-report-id</report_id>
    <date_range>
      <begin>1700000000</begin>                   <!-- Unix timestamp: start -->
      <end>1700086400</end>                       <!-- Unix timestamp: end -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>contoso.com</domain>                  <!-- Your domain -->
    <adkim>r</adkim>                              <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                <!-- SPF alignment mode -->
    <p>reject</p>                                 <!-- Domain policy -->
    <sp>quarantine</sp>                           <!-- Subdomain policy -->
    <pct>100</pct>                                <!-- Percentage -->
  </policy_published>

  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>        <!-- Sending IP -->
      <count>1523</count>                         <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>           <!-- What receiver did -->
        <dkim>pass</dkim>                         <!-- DKIM alignment result -->
        <spf>fail</spf>                           <!-- SPF alignment result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contoso.com</header_from>      <!-- From address domain -->
      <envelope_from>bounces.adatum.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contoso.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>bounces.adatum.com</domain>
        <result>pass</result>                     <!-- SPF passed but... -->
      </spf>
    </auth_results>
  </record>
</feedback>

Ler relatórios agregados

Use a tabela a seguir para interpretar os campos mais importantes em um relatório de agregação DMARC e determinar quais ações de solução de problemas devem ser tomadas.

elemento XML	O que isso informa	Ação de resolução de problemas
<source_ip>	O endereço IP que enviou as mensagens	Identificar se se trata de um remetente legítimo ou não autorizado
<count>	Número de mensagens desta origem	Contagem alta de um IP desconhecido = possível falsificação
<disposition>	Ação que o recetor tomou (none, quarantine, reject)	Verifique se o recetor está a respeitar a sua política
<dkim> em <policy_evaluated>	Se o DKIM está alinhado (não apenas aprovado)	fail = O domínio DKIM não corresponde ao domínio do remetente
<spf> em <policy_evaluated>	Se o SPF está alinhado (não apenas aprovado)	fail = O domínio MAIL FROM não corresponde ao domínio do From
<domain> em <auth_results><spf>	Domínio em que o SPF foi verificado	Se for diferente do domínio From = problema de alinhamento
<domain> em <auth_results><dkim>	Domínio de assinatura DKIM	Deve corresponder ao domínio De para o alinhamento de DMARC
<result> em <auth_results>	Aprovado/reprovado bruto de SPF/DKIM (antes da verificação de alinhamento)	pass + alinhamento fail = problema de alinhamento clássico

Dica

As informações mais importantes dos relatórios agregados são identificar o intervalo entre o passe de autenticação e o passe de alinhamento:

• <auth_results><spf><result>pass</result> + <policy_evaluated><spf>fail</spf> = O SPF passou, mas os domínios não se alinham.
• Esta combinação significa que o remetente está autorizado (passe SPF), mas não está corretamente configurado para DMARC (falha de alinhamento).

Padrões e correções de relatórios de agregação comuns

A tabela a seguir mostra padrões comuns que você pode encontrar em relatórios de agregação e as ações que eles normalmente exigem.

Padrão no relatório	Interpretação	Corrigir
IP conhecido, autenticação SPF=aprovada, SPF alinhado=falhou	Serviço legítimo com domínio MAIL FROM incorreto	Configurar o serviço para utilizar o seu domínio no MAIL FROM ou configurar a assinatura DKIM com o seu domínio
IP conhecido, DKIM auth=pass, DKIM aligned=fail	O serviço assina o DKIM com o seu próprio domínio	Configurar o DKIM personalizado no serviço com d=contoso.com
IP desconhecido, volume elevado, tudo falha	Possível campanha de falsificação/phishing	Não é necessária nenhuma ação. A sua política DMARC está a proteger os destinatários.
IP conhecido (Microsoft 365), SPF aligned=pass	Fluxo de correio normal do Microsoft 365	Saudável. Não é necessária nenhuma ação.
Baixo volume de serviço legítimo, SPF+DKIM falham	Serviço não incluído no SPF e que não assina com DKIM	Adicionar serviço ao registo SPF e/ou configurar o DKIM
E-mail encaminhado (IPs da lista de distribuição), tudo falhou	O encaminhamento de e-mail quebra o SPF; a modificação no corpo da mensagem quebra o DKIM	Normal para correio reencaminhado. Utilize o ARC ou aceite algumas falhas.

Relatórios forenses

Conforme indicado na secção DMARC para correio de entrada , o Microsoft 365 não envia relatórios forenses. No entanto, poderá recebê-los de outros fornecedores. A tabela seguinte compara os dois tipos de relatório:

Aspeto	Relatórios agregados (rua)	Relatórios forenses (ruf)
Frequency	Diariamente (normalmente)	Quase em tempo real (a cada falha)
Conteúdo	Estatísticas de resumo por IP de origem	Detalhes de mensagens individuais
Volume	Um relatório por dia por repórter	Um relatório por falha (pode ser um alto volume)
Privacidade	Somente endereços IP e contagens	Pode incluir cabeçalhos/corpo de mensagens (redigido)
Suporte	Amplamente suportado pelos recetores	Suporte limitado (muitos recetores não enviam ruf)
Caso de uso	Análise de tendências, identificando remetentes desconhecidos	Depuração de falhas específicas, investigação forense

Observação

Se precisar de detalhes de falha por mensagem do Microsoft 365, utilize o rastreio de mensagens e a análise de cabeçalhos de mensagens em vez de relatórios forenses.

O exemplo a seguir mostra a estrutura de um relatório forense DMARC (formato AFRF/RFC 6591) que um receptor envia para seu ruf endereço quando uma mensagem falha no DMARC. Procure os campos Feedback-Type, Source-IP e Authentication-Results para identificar os detalhes da falha:

From: noreply-dmarc-support@fabrikam.com
To: ruf@contoso.com
Subject: Report Domain: contoso.com Submitter: fabrikam.com

Feedback-Type: auth-failure
User-Agent: fabrikam.com/dmarc-reporter
Version: 1
Original-Mail-From: bounces@adatum.com
Arrival-Date: Mon, 15 Jan 2024 10:30:00 -0000
Source-IP: 198.51.100.10
Authentication-Results: fabrikam.com; dmarc=fail (p=reject)
  header.from=contoso.com
Reported-Domain: contoso.com
Original-Envelope-Id: <abc123@mail.adatum.com>

Melhores práticas para relatórios DMARC

Use as práticas recomendadas a seguir para gerenciar relatórios DMARC com eficiência.

Recomendação	Detalhes
Utilizar uma caixa de correio dedicada para rua	Criar uma caixa de correio partilhada (por exemplo, dmarc-reports@contoso.com). Não utilize caixas de correio de utilizador individuais.
Utilizar um Grupo do Microsoft 365	Os grupos proporcionam uma melhor colaboração e acesso partilhado à equipa de segurança
Considerar um serviço de relatórios DMARC	Os serviços de relatórios DMARC analisam XML em dashboards. Procure DMARC no Catálogo MISA.
Começar apenas com rua	Adicione ruf mais tarde, se necessário. Os relatórios forenses podem gerar um volume elevado.
Monitorizar regularmente	Revisar relatórios agregados semanalmente durante a implantação inicial; mensalmente quando estiver estável
Definir expectativas realistas	Nem todos os recetores enviam relatórios. Normalmente, a cobertura é de 70 a 90% do volume total de correio

Relatórios entre domínios

Se o seu DMARC rua ou ruf endereço estiver num domínio diferente do domínio que está a ser monitorizado, o domínio de receção tem de publicar um registo TXT DNS que autorize a entrega do relatório:

Exemplo: DMARC para contoso.com enviar relatórios para dmarc@fabrikam.com

Para autorizar fabrikam.com a receber relatórios DMARC em nome de contoso.com, o administrador fabrikam.com deve publicar o seguinte registro TXT DNS:

Hostname: contoso.com._report._dmarc
Type: TXT
Value: v=DMARC1;

Sem este registo, os recetores não entregam relatórios DMARC ao endereço externo.

Guia rápido de solução de problemas do DMARC

A tabela a seguir fornece uma referência rápida para sintomas DMARC comuns, suas causas prováveis, etapas de diagnóstico e resoluções.

Sintoma	Causa provável	Passo de diagnóstico	Resolução
dmarc=fail mas o SPF e o DKIM são aprovados individualmente	Falha de alinhamento: domínios não coincidem De	Verifique smtp.mailfrom= e header.d= vs header.from= em Authentication-Results	Configurar o SPF/DKIM com domínios alinhados
dmarc=bestguesspass	Nenhum registro DMARC publicado para o domínio do remetente	Consultar _dmarc.domain.com registro TXT	A Microsoft infere uma aprovação. Publicar um registo DMARC explícito.
dmarc=fail action=oreject mas a mensagem foi entregue	A opção Respeitar DMARC está desativada ou há uma lista de permissões/substituição	Verificar as definições de política anti-phishing e a Lista de Permissões/Bloqueios de Inquilinos	Ativar Respeitar a política do registro DMARC se desejar aplicação estrita
dmarc=fail para mensagens encaminhadas	O encaminhamento quebra o alinhamento do SPF; alterações no corpo da mensagem invalidam o DKIM	Verificar se a mensagem passou por um intermediário (cabeçalhos X-MS-Exchange)	Configurar o selador ARC confiável para o serviço de encaminhamento
dmarc=fail para remetentes SaaS que não sejam da Microsoft	O serviço utiliza o seu próprio domínio em MAIL FROM e DKIM d=	Verificar relatórios agregados para o IP do serviço	Configurar assinatura DKIM personalizada para o serviço + alinhar o MAIL FROM
dmarc=temperror ou dmarc=permerror	Problemas de DNS ao obter o registo DMARC (tempo limite, erro de sintaxe)	Validar a sintaxe do registro DMARC com nslookup -type=TXT _dmarc.domain.com	Corrigir erros de sintaxe do DNS; garantir que existe apenas um _dmarc registro TXT
compauth=fail reason=000	Falha na autenticação composta (falha explícita)	Verificar todos os resultados de autenticação (SPF, DKIM, DMARC, ARC)	Corrigir problemas de SPF/DKIM/DMARC subjacentes
compauth=fail reason=100	Falha explícita do DMARC com a imposição de políticas	A política DMARC do remetente causou a falha	Corrija o alinhamento na fonte ou configure ARC/override, se for legítimo.
Relatórios agregados não recebidos	rua endereço inacessível ou autenticação entre domínios em falta	Verificar se a caixa de correio existe e se o registro de autorização de DNS para domínios externos está presente	Corrigir o roteamento da caixa de correio; adicionar registro TXT domain._report._dmarc

Fluxo de trabalho de diagnóstico DMARC

Utilize os seguintes passos para diagnosticar uma mensagem com dmarc=fail:

1. Identifique o domínio do remetente: Localize o valor header.from= no cabeçalho Authentication-Results.

2. Verificar o alinhamento do SPF: o domínio smtp.mailfrom= corresponde ao domínio header.from=?

   • Sim (o mesmo domínio organizacional com aspf=r): O SPF está alinhado.
   • Não: O alinhamento do SPF falha.
   • O SPF foi aprovado (spf=pass vs. spf=fail)? Se spf=fail, corrija primeiro o SPF ao adicionar o remetente ao registo SPF.

3. Verificar o alinhamento de DKIM: o valor de header.d= na assinatura DKIM corresponde ao domínio header.from=?

   • Sim (mesmo domínio organizacional com adkim=r): O DKIM está alinhado.
   • Não: o alinhamento do DKIM falha.
   • O DKIM foi aprovado (dkim=pass vs. dkim=fail)? Se dkim=fail, corrija o DKIM publicando a chave e verificando a assinatura.

4. Se ambos os alinhamentos falharem, o DMARC falhará. Opções de resolução:

   • Corrigir o alinhamento SPF: altere o endereço MAIL FROM para o seu domínio.
   • Corrigir o alinhamento do DKIM: assine com d=contoso.com.
   • Use um subdomínio: Envie usando sub.domain.com com seu próprio registro DMARC.
   • Se a mensagem for encaminhada: configure um selador ARC confiável.

5. Verifique a ação de política:

   • p=none: Sem efeito na entrega (somente monitorar).
   • p=quarantine: a mensagem é enviada para o Email de Lixo (se a política Honor DMARC estiver ativada).
   • p=reject: a mensagem é rejeitada (se a política Honor DMARC estiver ativada). Se o correio legítimo for rejeitado, utilize o ARC, uma lista de permissões ou corrija a autenticação na origem.

Comandos úteis do PowerShell para resolução de problemas do DMARC

Conecte-se ao Exchange Online PowerShell e use os seguintes comandos para verificar as configurações de DMARC da política anti-phishing, verificar registros DNS DMARC e DKIM, examinar falhas de DMARC recentes e inspecionar a configuração do ARC:

# Check your organization's anti-phishing policy DMARC settings
Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

# Verify DMARC record for a domain
Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

# Check DKIM configuration (alignment prerequisite)
Get-DkimSigningConfig | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

# Review messages that failed DMARC in the last 24 hours
Get-MailDetailSpamReport -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
  Where-Object { $_.MessageTraceId } |
  Select-Object Date, SenderAddress, RecipientAddress, Subject, SpamScore

# Check ARC configuration (for forwarding scenarios)
Get-ArcConfig | Format-List ArcTrustedSealers

# View anti-phishing policy DMARC override actions
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" |
  Select-Object HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

Dica

Ao resolver problemas de falhas DMARC para um remetente específico:

1. Comece com o cabeçalho Authentication-Results para identificar o tipo de falha.
2. Compare com seus relatórios agregados de DMARC para ver o volume e os endereços IP de origem.
3. Utilize Get-MessageTrace para localizar mensagens específicas e Get-MessageTraceDetail para examinar eventos de entrega.
4. Se o remetente for legítimo, trabalhe com ele para corrigir o alinhamento de SPF/DKIM antes de criar exceções.

Próximas etapas

Para emails que chegam ao Microsoft 365, talvez também seja necessário configurar seladores ARC confiáveis se você usar serviços que modificam mensagens em trânsito antes da entrega à sua organização. Para obter mais informações, consulte Configurar emissores de selos 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.