Configurar o DMARC para validar o domínio do endereço do remetente para remetentes na cloud

Sugestão

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 e-mail utilizado na transmissão da mensagem entre servidores de e-mail SMTP. Este endereço também é conhecido como endereço 5321.MailFrom , remetente P1 ou remetente de envelope.
  • O endereço do remetente: o endereço de e-mail no campo de cabeçalho De apresentado nos clientes de e-mail como o remetente da mensagem. 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. Este resultado requer efetivamente que as origens válidas para a mensagem estejam no domínio de endereço De.

  • O DMARC utiliza o resultado do DKIM para verificar se o domínio que assinou a mensagem (o valor d= num campo do 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 instruções, consulte Usar o centro de administração do Microsoft 365 para adicionar registos DMARC TXT 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. Também tem de configurar a assinatura DKIM utilizando o domínio personalizado ou o subdomínio, para que o domínio usado para assinar a mensagem esteja alinhado com o domínio no endereço do campo 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 DMARC do correio de entrada podem precisar de assistência: se utilizar um serviço de correio eletrónico que modifique mensagens em trânsito antes de serem entregues ao Microsoft 365, poderá conseguir identificar esse serviço como um selador ARC de confiança. Os sealers ARC fidedignos impedem que as mensagens modificadas falhem automaticamente nas verificações DMARC. Para mais informações, consulte Próximos Passos.

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.

Sugestão

Para criar o registo DMARC TXT para o seu domínio *.onmicrosoft.com no centro de administração do Microsoft 365, veja Usar o centro de administração do Microsoft 365 para adicionar registos DMARC TXT 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 registos TXT 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: Diz ao sistema de email de destino o que fazer com mensagens que falham em DMARC (rejeição, 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 aceites, 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. Utiliza-se este valor para testar e ajustar a política DMARC.

  Sugestão

  As mensagens de correio de saída de domínios no Microsoft 365 que não passem nas verificações DMARC efetuadas pelo serviço de correio eletrónico de destino são encaminhadas através do grupo de entrega de alto risco para mensagens de saída se a política 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. Usas 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 agregado 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 são aprovados ou reprovados 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).

    Sugestão

    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órios DMARC descrevem quaisquer valores personalizados necessários no registo TXT 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).

  Sugestão

  Deve rever regularmente os relatórios agregados do DMARC para monitorizar de onde provém o e-mail dos seus domínios e verificar a existência de falhas não intencionais do 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 formação sobre DMARC do M³AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
• 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 os seguintes passos para adicionar um registo DMARC TXT para o 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>Definiçõ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 verificação 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.

     Sugestão

     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

Sugestão

Antes de configurar DMARC para domínios ou subdomínios personalizados, precisa de criar registos SPF TXT e configurar a assinatura DKIM para todos os domínios e subdomínios personalizados que usa para enviar emails no 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:

   Registo TXT 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 algum tempo a monitorizar os efeitos de p=none, pode aumentar a política DMARC para p=quarantine para o domínio. Por exemplo:

   Registo TXT 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, pode mover-se nos seguintes incrementos:

   • 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 algum tempo a monitorizar os efeitos de p=quarantine, pode aumentar a política DMARC para p=reject para o domínio. Por exemplo:

   Registo TXT 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.

   Sugestão

   Bloquear e-mails legítimos em grande volume é inaceitável para os utilizadores, mas é quase inevitável que venham a ocorrer 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 definições do registo DMARC TXT do domínio principal, que podem ser substituídas por um registo DMARC TXT 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

Sugestão

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.
   • Pode argumentar-se que os valores rua=mailto: e ruf=mailto: não são necessários neste cenário, porque nenhum e-mail válido deverá alguma vez provir de remetentes do 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

As seguintes funcionalidades e comportamentos influenciam a forma como o Microsoft 365 avalia o DMARC para mensagens recebidas 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 deteção de spoofing está ativada ou desativada na política de anti-phishing que verificou a mensagem. Desativar a inteligência de falsificação desativa a proteção implícita contra falsificação apenas nas verificações de autenticação composta.
  • Se a definição Respeitar a política de registo DMARC quando a mensagem é detetada 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 registo DMARC TXT).

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

  Para ver os valores predefinidos destas definições em políticas anti-phishing, verifique os valores de definição na tabela em Definições de políticas 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 encaminhar o correio eletrónico da Internet através de um serviço ou dispositivo não pertencente à Microsoft antes da entrega ao Microsoft 365 (ou seja, se o registo MX apontar para outro local que não o Microsoft 365), os relatórios agregados do DMARC não sã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.

  Sugestão

  Quando um serviço ou dispositivo que não seja da Microsoft estiver à frente do fluxo de correio para o Microsoft 365, a Filtragem Avançada para Conectores (também conhecida como omissão da listagem) identifica corretamente a origem das mensagens da Internet para efeitos de validação de SPF, DKIM (se o serviço modificar as mensagens) e 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 secção ajuda-o a diagnosticar e resolver falhas comuns do DMARC, compreender como o Microsoft 365 atua em diferentes políticas DMARC e interpretar relatórios forenses e agregados DMARC.

Diagnóstico de falha de alinhamento

Como descrito em Configurar DMARC para validar o domínio de endereços From para emissores na cloud, uma mensagem passa por DMARC se pelo menos uma verificação de alinhamento for bem-sucedida (SPF ou DKIM). Uma mensagem falha DMARC apenas se ambas as verificações de alinhamento falharem.

Modos de alinhamento

As etiquetas aspf (SPF) e adkim (DKIM) no registo DMARC TXT controlam o rigor com que o domínio do campo From tem de 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 seguinte mostra um registo DMARC TXT que utiliza alinhamento SPF estrito (aspf=s) e alinhamento 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 têm de corresponder exatamente. Não existem correspondências de subdomínios.

Nota

As aspf etiquetas e adkim são independentes. Pode utilizar diferentes modos para cada um, conforme mostrado no exemplo. Uma mensagem passa DMARC se uma das verificações de alinhamento for bem-sucedida, pelo que uma falha estrita numa verificação não importa se a outra verificação passa com um alinhamento descontraído.

Exemplos:

Endereço de origem	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	❌ Falhar
user@marketing.contoso.com	contoso.com	✅ Aprovado	❌ Falhar
user@contoso.com	contoso.onmicrosoft.com	❌ Falhar	❌ Falhar
user@contoso.com	adatum.net	❌ Falhar	❌ Falhar

Cenários comuns de falha de alinhamento

A tabela seguinte lista cenários comuns de falha no alinhamento DMARC, os seus sintomas, causas raízes e soluções recomendadas.

Cenário	Sintoma	Causa raiz	Resoluçã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 o seu domínio	Configure a assinatura DKIM para o seu domínio no serviço ou altere MAIL FROM para o seu domínio/subdomínio
Encaminhamento automático do Microsoft 365	DMARC falha no destino	O reencaminhamento altera o remetente do envelope; a assinatura DKIM pode ser invalidada	Use seladores ARC fidedignos no destino, ou o DKIM (sobrevive ao reencaminhamento, se o corpo da mensagem 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 From é contoso.com	Altere para aspf=r (relaxado), ou certifique-se de que o endereço do remetente corresponde ao subdomínio
Erro de correspondência do domínio de assinatura DKIM	O DKIM passa, mas o DMARC continua a falhar	O valor DKIM d= (por exemplo, adatum.com) não está alinhado com o domínio From (contoso.com)	Configurar a assinatura DKIM personalizada no serviço com o seu domínio
Caixa de correio partilhada ou grupo de distribuição	O DMARC falha intermitentemente	O Reply-from ou o redirecionamento alteram os endereços do 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

Passo 1: Abra os cabeçalhos da mensagem e localize o cabeçalho Authentication-Results do Microsoft 365. O exemplo seguinte mostra um cabeçalho Authentication-Results em que o SPF e o DKIM são aprovados individualmente, mas o 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 de cabeçalho	Valor no exemplo	Alinha-se com De (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. Pode alterar o endereço MAIL FROM para o 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.
     • Peça ao serviço para assinar o 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 todos os detalhes, consulte Proteção contra falsificação e políticas 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	Tratamento da mensagem	Authentication-Results	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

Atenção

Tenha cuidado ao ignorar 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 fidedigno (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	Publicado pelo remetente p=none; nenhuma ação foi tomada
action=quarantine	Remetente publicado p=quarantine; mensagem colocada em quarentena ou desativada
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 percentagem amostrada
action=pct.reject	O remetente publicou p=reject com pct= inferior a 100; esta mensagem estava incluída na percentagem amostrada

Interpretação do relatório DMARC

Esta secção ajuda-o a interpretar os relatórios agregados e forenses do DMARC que os recetores enviam para os seus endereços rua e ruf. Para obter informações sobre a configuração dos valores rua e ruf no registo TXT do DMARC, consulte Sintaxe dos registos TXT do 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 seguinte para interpretar os campos mais importantes num relatório agregado DMARC e determinar que ação de resolução de problemas tomar.

elemento XML	O que isto lhe diz	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	Número elevado de um IP desconhecido = possível spoofing
<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 passado)	fail = O domínio DKIM não corresponde a Do domínio
<spf> em <policy_evaluated>	Se o SPF está alinhado (não apenas passado)	fail = o domínio MAIL FROM não corresponde ao domínio de 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	Tem de corresponder ao domínio do remetente para alinhamento DMARC
<result> em <auth_results>	SPF/DKIM bruto aprovado/reprovado (antes da verificação de alinhamento)	pass + alinhamento fail = problema de alinhamento clássico

Sugestão

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 seguinte mostra padrões comuns que pode encontrar em relatórios agregados e as ações que normalmente exigem.

Padrão no relatório	Interpretação	Corrigir
IP conhecido, SPF auth=pass, SPF aligned=fail	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 conhecida, autenticação DKIM=aprovada, alinhamento DKIM=falhou	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	Potencial 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	Bom estado de funcionamento. Não é necessária nenhuma ação.
Baixo volume do serviço legítimo, SPF+DKIM falham	Serviço não incluído no SPF e sem assinatura DKIM	Adicionar serviço ao registo SPF e/ou configurar o DKIM
Correio reencaminhado (IPs da lista de correio), tudo falha	O reencaminhamento de e-mail invalida o SPF; a alteração do corpo da mensagem invalida o DKIM	Normal para mensagens reencaminhadas. 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)
Frequência	Diariamente (normalmente)	Quase em tempo real (por falha)
Content	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 ter um volume elevado)
Privacidade	Apenas endereços IP e contagens	Pode incluir cabeçalhos e corpo da mensagem (expurgados)
Suporte	Amplamente suportado pelos recetores	Suporte limitado (muitos recetores não enviam ruf)
Caso de utilização	Análise de tendências, identificando remetentes desconhecidos	Depuração de falhas específicas, investigação forense

Nota

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 seguinte mostra a estrutura de um relatório forense DMARC (formato AFRF/RFC 6591) que um recetor envia para o seu ruf endereço quando uma mensagem falha em 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

Utilize as seguintes melhores práticas para gerir eficazmente os relatórios DMARC.

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. Pesquise 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	Reveja os relatórios agregados semanalmente durante a fase inicial da implementação; mensalmente assim que a situação 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 de fabrikam.com deve publicar o seguinte registo DNS TXT:

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 de referência rápida para resolução de problemas do DMARC

A tabela seguinte fornece uma referência rápida dos sintomas comuns de DMARC, as suas prováveis causas, passos 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: os domínios não coincidem De	Verificar smtp.mailfrom= e header.d= face a header.from= em Authentication-Results	Configurar o SPF/DKIM com domínios alinhados
dmarc=bestguesspass	Não existe nenhum registo DMARC publicado para o domínio do remetente	Consultar o registo TXT _dmarc.domain.com	A Microsoft deduz um passe. Publicar um registo DMARC explícito.
dmarc=fail action=oreject mas a mensagem foi entregue	Honor DMARC desativado ou permitir lista/substituição no local	Verificar as definições de política anti-phishing e a Lista de Permissões/Bloqueios de Inquilinos	Ative Respeitar a política do registo DMARC se pretender uma aplicação rigorosa
dmarc=fail para mensagens reencaminhadas	O reencaminhamento interrompe o alinhamento do SPF; alterações do corpo quebram o DKIM	Verificar se a mensagem passou por um intermediário (cabeçalhos X-MS-Exchange)	Configurar o selador ARC fidedigno para o serviço de reencaminhamento
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 a assinatura DKIM personalizada ao nível do 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 sintaxe do registo DMARC com nslookup -type=TXT _dmarc.domain.com	Corrigir erros de sintaxe DNS; garantir a existência de apenas um registo TXT _dmarc
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	Corrigir o alinhamento na origem ou configurar o ARC ou a substituição, se tal 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 registo de autorização de DNS para domínios externos existe	Corrigir o encaminhamento de correio; adicionar o registo 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. Verifique o alinhamento 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 sequer aprovado (spf=pass vs spf=fail)? Se spf=fail, corrija primeiro o SPF ao adicionar o remetente ao registo SPF.

3. Verificar o alinhamento do DKIM: o valor 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 sequer 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 a partir de sub.domain.com com o seu próprio registo DMARC.
   • Se a mensagem for reencaminhada: configure um selador ARC fidedigno.

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

   • p=none: Sem efeito na entrega (apenas monitorizar).
   • 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

Ligue-se ao PowerShell do Exchange Online e utilize os seguintes comandos para verificar as definições da sua política anti-phishing do DMARC, verificar os registos DNS do DMARC e DKIM, rever falhas recentes do DMARC 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

Sugestão

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. Faça referência cruzada com os seus relatórios agregados DMARC para ver o volume e os IPs 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, colabore com ele para corrigir o alinhamento SPF/DKIM antes de criar exceções.

Passos seguintes

Para o correio recebido no Microsoft 365, também poderá ter de configurar seladores ARC fidedignos se utilizar serviços que modificam as mensagens em trânsito antes da entrega à sua organização. Para obter mais informações, 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.