Microsoft 365 / Registros DNS de email: verificar MX, SPF, DKIM e DMARC

Para e-mail do Microsoft 365, registros DNS (Sistema de Nomes de Domínio) direcionam o e-mail recebido e suportam a autenticação do e-mail enviado. Um registro de trocador de correio (MX) identifica o servidor receptor; Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) e Domain-based Message Authentication, Reporting, and Conformance (DMARC) fornecem diferentes verificações de autenticação e informações de políticas. Verifique a propriedade do domínio e faça um inventário dos serviços de envio do Microsoft 365 e de serviços externos antes de alterar esses registros.

Funções dos quatro registros

O guia da Microsoft para implantação da autenticação de email explica como configurar SPF, DKIM e DMARC em domínios personalizados. A aprovação de SPF ou DKIM, sozinha, não garante a aprovação de DMARC: o domínio autenticado também precisa estar alinhado com o domínio do remetente exibido.

O SPF declara quais fontes de envio estão autorizadas. Com o DKIM, o remetente usa uma chave privada para assinar partes da mensagem, e o destinatário usa uma chave pública publicada via DNS para verificar a assinatura. O DMARC verifica o alinhamento com o domínio visível no campo De e publica a política solicitada para o tratamento de falhas e o destino do relatório. Essas capacidades de autenticação estão incluídas na proteção integrada para caixas de correio em nuvem; outros recursos do Defender podem ter requisitos adicionais de licenciamento.

O SPF verifica o domínio usado no MAIL FROM, o endereço do remetente do envelope usado entre os servidores de e-mail. Isso pode ser diferente do endereço From mostrado ao leitor. Um domínio de assinatura DKIM também pode pertencer ao provedor de serviços. Portanto, um serviço de gerenciamento de relacionamento com o cliente (CRM) pode passar SPF e DKIM com o domínio do provedor, mas ainda falhar no DMARC para o domínio da empresa mostrado no From. O requisito principal é que pelo menos um resultado de SPF alinhado ou DKIM alinhado seja aprovado.

O alinhamento pode ser relaxado (mesmo domínio organizacional, permitindo subdomínios) ou estrito (uma correspondência exata do nome de domínio). As tags opcionais aspf e adkim controlam o alinhamento de SPF e DKIM separadamente; ambas usam o modo relaxado por padrão (r). Verifique esses modos quando um serviço de envio usar um subdomínio.

Investigue o caminho de envio antes da configuração

• Emails enviados por funcionários a partir do Exchange Online
• Emails enviados por sistemas externos, como formulários de contato de sites, CRM, serviços de marketing e dispositivos multifuncionais
• Serviços de envio que usam subdomínios separadamente
• O caminho através de um gateway de segurança de email ou servidor de retransmissão

Se a fonte de envio for omitida, emails legítimos podem ser rejeitados após o fortalecimento do SPF, DKIM e DMARC. Remova as fontes de envio que não são usadas e autentique os serviços necessários de acordo com a orientação oficial do respectivo provedor.

Ordem de verificação no Microsoft 365

1. No centro de administração do Microsoft 365, abra o domínio de destino em [Configurações] → [Domínios] e verifique o status da configuração de DNS. Use os valores MX mostrados no assistente de domínio para esse domínio.

2. Verifique os registros SPF TXT atuais com seu provedor de hospedagem de DNS. Se fontes de envio fora do Microsoft 365 precisarem ser incluídas, integre-as nos valores existentes.
3. Nas configurações de autenticação de e-mail do portal do Microsoft Defender, verifique o status DKIM do domínio personalizado e os registros de DNS necessários. Após adicionar os valores sugeridos ao DNS, verifique se a assinatura está ativada.

4. Introduza o DMARC gradualmente. Analise os remetentes reais e as falhas de autenticação através dos relatórios, e então decida sobre o fortalecimento da política. Se você apenas adicionar a declaração de política sem ler os relatórios, será difícil detectar problemas.
5. Envie um e-mail de teste para um endereço externo fora da organização e verifique os resultados e o alinhamento de SPF, DKIM e DMARC nos cabeçalhos recebidos. Mesmo que o status do DNS esteja normal, você precisa testar o caminho de envio real.

Condições sob as quais o exemplo de SPF pode ser usado como está

Para um domínio personalizado cujo DNS público você gerencia, o seguinte valor TXT é um exemplo básico quando Microsoft 365 é o único serviço de envio. Este exemplo se aplica ao serviço comercial mundial da Microsoft; nuvens especiais governamentais ou operadas na China podem exigir domínios diferentes no mecanismo include. Use os valores específicos do serviço no seu centro de administração e na documentação. Se um site ou serviço de marketing também enviar diretamente usando o mesmo domínio, não substitua sua política atual apenas por este exemplo. Compare o assistente de domínio com as orientações oficiais de configuração de cada remetente.

v=spf1 include:spf.protection.outlook.com -all

include refere-se ao escopo de envio do Microsoft 365 e -all declara que fontes de envio não autorizadas pelos mecanismos SPF devem ser tratados como falhas de SPF. Criar dois registros TXT de SPF com o mesmo nome para incluir separadamente o Microsoft 365 e serviços externos é uma configuração incorreta. Reúna as fontes de envio necessárias em uma única política de SPF e remova remetentes desnecessários. Registros TXT para verificação de propriedade diferentes de SPF têm um propósito diferente e não estão sujeitos à remoção. Selecione com base nos cenários de envio no Guia de configuração do SPF da Microsoft.

Ao combinar serviços, verifique também o limite de 10 consultas DNS do SPF durante a avaliação. Mecanismos de inclusão aninhados também contam: menos de 10 provedores ou entradas de inclusão não garantem que a avaliação permaneça dentro do limite.

Valores para selecionar ao configurar DKIM e DMARC

No portal do Defender, abra o domínio personalizado em Email & colaboração → Políticas & regras → Políticas contra ameaças → Configurações de autenticação de email → DKIM. Gere as chaves se necessário, depois insira os nomes e destinos dos dois registros CNAME (nome canônico) mostrados nos detalhes do domínio no seu provedor de DNS. Um registro CNAME aponta um nome de DNS para outro; nesta configuração, ele conecta a consulta DKIM aos registros de chave da Microsoft. Copie os nomes de seletor e os destinos fornecidos para seu tenant em vez de construí-los a partir de um blog antigo. A Microsoft introduziu um novo formato de destino para novos domínios personalizados em maio de 2025, enquanto os domínios existentes podem manter o formato antigo.

Após a propagação do DNS, ative a opção de assinatura DKIM para o domínio e verifique se está realizando a assinatura. Se o CNAME estiver ausente, verifique novamente o nome inserido, o provedor real de DNS e o tempo de detecção. Não presuma que a assinatura está habilitada apenas porque ambos os registros foram salvos. Você pode verificar o procedimento a seguir de acordo com o status atual no procedimento oficial de configuração do DKIM .

A política inicial de DMARC pode ser configurada como uma configuração focada em relatórios que pode analisar remetentes legítimos. Abaixo está um exemplo usando example.com como um domínio de exemplo. Publique o registro TXT em _dmarc para o seu próprio domínio e substitua dmarc@example.com no valor rua=mailto: por uma caixa de correio real de relatórios controlada pela sua organização. O endereço de exemplo não é um destino para uso sem alterações.

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none é uma política inicial que não solicita quarentena nem rejeição para falhas de DMARC em si, e não desativa outros filtros de spam ou de segurança. O parâmetro rua indica o destino dos relatórios agregados. Você precisa estar pronto para realmente receber e analisar nesse endereço, e se estiver usando um endereço de serviço de relatórios externo, também deve verificar condições adicionais de aprovação de DNS. Após verificar o alinhamento dos remetentes legítimos e o caminho de entrega, você fortalece a política para os passos quarantine e reject. Condições detalhadas seguem as diretrizes de implementação de DMARC.

Verifique registros DNS e autenticação em e-mails recém-enviados

Envie novos e-mails para um endereço de teste para cada caminho de envio, como e-mail de funcionário, formulários de consulta na web, CRM, etc. No lado do recebimento, abra a mensagem original e os cabeçalhos da internet para verificar os resultados de SPF, DKIM e DMARC no Authentication-Results do sistema de recebimento, e também compare o domínio de assinatura do DKIM com o From exibido. Você precisa dos resultados das mensagens recém-enviadas após as mudanças, em vez de "e-mails antigos estavam normais."

Se o DNS estiver normal, mas um CRM específico falhar, verifique primeiro o domínio de envio e as configurações de assinatura para esse caminho. Se o corpo assinado mudar ou o servidor de envio for diferente durante o processo de entrega, os resultados podem variar. A autenticação bem-sucedida não garante a entrega na caixa de entrada, e reputação, políticas de spam e de conteúdo também têm impacto.

Os valores dos registros variam dependendo do domínio e do momento da configuração. O objetivo deste artigo não é memorizar os valores, mas comparar os valores fornecidos pelo centro de gerenciamento , os valores reais no DNS e os resultados de autenticação no lado receptor. Se houver problemas com o recebimento ou envio de e-mails, identifique o escopo de impacto com base nos registros DNS antes das alterações. Se e-mails legítimos forem afetados, compare a política anterior e a configuração do remetente para reverter apenas as alterações problemáticas e teste novamente. Não exclua todos os registros SPF, DKIM e DMARC nem mantenha uma política DMARC rigorosa sem conhecer a causa. No relatório, diferencie falhas de remetentes legítimos de envios suspeitos ou forjados, e determine as ações de acompanhamento de acordo.