Implementar DANE para Exchange Online e Microsoft 365

Q: Quanto tempo leva a ativação do DANE no Exchange Online?

A ativação é feita em duas fases. A migração MX ( Enable-DnssecForVerifiedDomain ) leva alguns minutos, mas a propagação DNS depende dos seus TTLs. A publicação TLSA ( Enable-SmtpDaneInbound ) leva de 15 a 30 minutos. Conte algumas horas no total, principalmente pelas propagações DNS.

Por CaptainDNS
Publicado em 24 de fevereiro de 2026

Esquema mostrando o fluxo DANE entre um remetente SMTP e o Exchange Online com DNSSEC e TLSA

TL;DR

O Microsoft 365 suporta DANE inbound (SMTP) desde março de 2024 para o Exchange Online, com publicação automática dos registros TLSA
O pré-requisito principal é DNSSEC: seu domínio deve estar assinado e os registros DS publicados no seu registrar
A ativação migra seu MX de mail.protection.outlook.com para o-v1.mx.microsoft, um domínio assinado com DNSSEC. A Microsoft publica automaticamente os TLSA, você não precisa gerenciá-los
O Google Workspace não suporta DANE inbound, apenas o DANE outbound (verificação) está ativo
Verifique sua implementação com nosso inspetor DANE/TLSA que testa DNSSEC, TLSA e a cadeia de certificados em um único clique

A Microsoft anunciou a disponibilidade geral do DANE inbound para o Exchange Online em março de 2024. Na prática, os domínios hospedados no Microsoft 365 agora podem receber emails protegidos por DANE: os servidores remetentes que verificam DANE/TLSA validam o certificado TLS do Exchange Online via DNS assinado, em vez de confiar cegamente nas autoridades certificadoras.

Porém, ativar DANE no Microsoft 365 não se faz com um simples botão. O pré-requisito fundamental é DNSSEC: sem uma zona DNS assinada, os registros TLSA publicados pela Microsoft não têm nenhum valor. E a configuração DNSSEC depende do seu registrar e do seu provedor DNS, não da Microsoft.

Este guia cobre o procedimento completo: verificar os pré-requisitos, ativar DNSSEC no seu domínio, ativar DANE no Exchange Online e validar a implementação de ponta a ponta. Ele também compara as diferenças com o Google Workspace (que não suporta DANE inbound) e os servidores on-premise como Postfix ou Exchange Server.

Público-alvo: administradores Microsoft 365, gestores de TI corporativos, MSPs que gerenciam tenants M365. Para os fundamentos de DANE e TLSA, consulte o primeiro artigo desta série (link no final da página).

Como funciona o DANE com o Exchange Online?

Quando um servidor remetente envia um email para um domínio hospedado no Exchange Online e protegido por DANE:

Resolução MX: o servidor resolve o MX de captaindns.com e obtém captaindns-com.o-v1.mx.microsoft (o novo formato MX para domínios DANE)
Verificação DNSSEC: ele verifica que a resposta DNS está assinada com DNSSEC. A cadeia de confiança passa por root → .microsoft → mx.microsoft → o-v1.mx.microsoft, inteiramente assinada
Consulta TLSA: ele solicita o registro TLSA em _25._tcp.captaindns-com.o-v1.mx.microsoft
Conexão TLS: ele se conecta em STARTTLS na porta 25 e compara o certificado apresentado pelo Exchange Online com o hash TLSA
Entrega: se tudo corresponde, o email é entregue. Caso contrário, é rejeitado ou adiado conforme a política do servidor remetente

Um ponto importante: outlook.com não é assinado com DNSSEC. Por isso a Microsoft criou a infraestrutura mx.microsoft sob o TLD .microsoft, que é assinado com DNSSEC de ponta a ponta. A ativação do DANE migra automaticamente seu MX do formato antigo mail.protection.outlook.com para o novo o-v1.mx.microsoft.

A diferença principal em relação a um servidor self-hosted (Postfix, Exchange Server on-premise): a Microsoft gerencia a migração MX, os registros TLSA e os certificados TLS. Você não publica os TLSA por conta própria. Sua única responsabilidade é ativar DNSSEC no seu domínio.

Fluxo DANE entre um servidor remetente e o Exchange Online

Pré-requisitos antes de ativar o DANE

Domínio com DNSSEC ativo

O DANE depende inteiramente do DNSSEC. Sem assinaturas DNS válidas, os registros TLSA são ignorados pelos servidores remetentes. Verifique o estado atual:

dig +dnssec captaindns.com SOA +short

Se a resposta incluir uma flag ad (Authenticated Data) no header, seu domínio está assinado. Caso contrário, você precisa ativar o DNSSEC.

Registrar compatível com DNSSEC

Nem todos os registrars suportam DNSSEC da mesma forma:

Registrar	DNSSEC	Método
Cloudflare	Automático	Um clique no dashboard, DS publicado automaticamente
OVH	Suportado	Ativação manual, DS a ser publicado no registrant
Gandi	Suportado	Chave KSK a fornecer, DS publicado automaticamente
GoDaddy	Suportado	Ativação manual nas configurações DNS avançadas
Route 53 (AWS)	Suportado	Criação da cadeia KSK/ZSK, DS a ser publicado manualmente

Se o seu registrar não suporta DNSSEC, você precisará migrar seu DNS para um provedor compatível antes de poder ativar o DANE.

MX apontando para o Exchange Online

Antes de ativar o DANE, seus MX apontam para *.mail.protection.outlook.com. Verifique:

dig MX captaindns.com +short

O resultado deve ser semelhante a:

0 captaindns-com.mail.protection.outlook.com.

Ao ativar o DANE, a Microsoft pedirá que você migre esse MX para um novo formato: captaindns-com.o-v1.mx.microsoft. Esse novo domínio é hospedado sob o TLD .microsoft, assinado com DNSSEC de ponta a ponta. Como o antigo outlook.com não é assinado com DNSSEC, a cadeia de confiança seria impossível sem essa migração.

Se seus MX passam por um relay terceiro (Proofpoint, Mimecast, Barracuda), o DANE protegerá apenas o último salto até o Exchange Online. O próprio relay também precisa suportar DANE para uma proteção de ponta a ponta.

Ativar DNSSEC no seu domínio

O procedimento varia conforme seu provedor DNS. Aqui estão as etapas gerais comuns.

Se seu DNS está na Cloudflare

Faça login no dashboard da Cloudflare
Selecione seu domínio
Vá em DNS → DNSSEC
Clique em Enable DNSSEC
A Cloudflare exibe as informações DS a publicar no seu registrar
Se a Cloudflare também é seu registrar, é automático

A Cloudflare assina a zona e publica o DS em poucos minutos. Em seguida, verifique:

dig +dnssec captaindns.com DNSKEY +short

Se seu DNS está em outro provedor

O processo se divide em duas etapas:

Ativar a assinatura de zona no seu provedor DNS (geração das chaves KSK/ZSK, assinatura automática)
Publicar o registro DS no seu registrar (a chave DS faz a ligação entre sua zona assinada e a zona pai)

O DS deve corresponder exatamente à chave KSK da sua zona. Um erro no DS quebrará a resolução DNS do seu domínio. Sempre teste em ambiente de staging ou com um subdomínio primeiro.

Guia em 4 etapas para implementar DANE no Microsoft 365

Ative a assinatura DNSSEC no seu provedor DNS e publique o registro DS no seu registrar. Verifique com dig +dnssec captaindns.com SOA que a flag ad aparece na resposta. Conte de 24 a 48 horas para a propagação completa do DS.
Reduza o TTL do seu MX atual ao mínimo (não menos que 30 segundos) e aguarde a expiração do TTL antigo. Execute Enable-DnssecForVerifiedDomain -DomainName captaindns.com no Exchange Online PowerShell. O comando retorna o novo valor MX: captaindns-com.o-v1.mx.microsoft. Adicione esse novo MX com prioridade 20, verifique se funciona, depois passe-o para prioridade 0 e remova o antigo MX mail.protection.outlook.com.
Uma vez que o MX esteja migrado e funcional, execute Enable-SmtpDaneInbound -DomainName captaindns.com. A Microsoft gera e publica automaticamente os registros TLSA em _25._tcp.captaindns-com.o-v1.mx.microsoft. A propagação leva de 15 a 30 minutos.
Use dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft para confirmar a presença do TLSA. Teste a conexão TLS com openssl s_client -starttls smtp -connect captaindns-com.o-v1.mx.microsoft:25. Valide tudo com a ferramenta de verificação DANE/TLSA do CaptainDNS.

Ativar DANE no Exchange Online

A ativação é feita em duas fases distintas: primeiro a migração DNSSEC (novo MX), depois a ativação DANE (publicação TLSA). O procedimento é gerenciado via Exchange Online PowerShell.

Fase 1: migração MX para mx.microsoft

Esta primeira fase ativa o DNSSEC e migra seu MX para a infraestrutura mx.microsoft, assinada com DNSSEC.

# Conexão com o Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@captaindns.com

# Ativar DNSSEC para o domínio
Enable-DnssecForVerifiedDomain -DomainName captaindns.com

O comando retorna o novo valor MX:

Result	DnssecMxValue
`Success`	`captaindns-com.o-v1.mx.microsoft`

Procedimento de migração MX:

Reduzir o TTL do seu MX atual ao mínimo (não menos que 30 segundos)
Aguardar a expiração do TTL antigo
Adicionar o novo MX captaindns-com.o-v1.mx.microsoft com prioridade 20
Verificar que o novo MX recebe emails corretamente
Alternar as prioridades: novo MX em 0, antigo em 30
Remover o antigo MX captaindns-com.mail.protection.outlook.com
Definir o TTL do novo MX para 3600 segundos

Se você utiliza MTA-STS, mude a política para modo testing e adicione o novo hostname no arquivo de política antes da migração. Restaure o modo enforce após a conclusão.

Fase 2: ativação DANE (publicação TLSA)

Uma vez que o MX esteja migrado e funcional:

# Ativar DANE (publicação dos TLSA)
Enable-SmtpDaneInbound -DomainName captaindns.com

# Verificar o status completo
Get-DnssecStatusForVerifiedDomain -DomainName captaindns.com

O status passa por várias fases:

Status	Significado
`DnssecFeatureNotEnabled`	DNSSEC não ativado
`DnssecValidationPending`	A Microsoft está verificando o DNSSEC no seu domínio
`DnssecEnabled`	DNSSEC validado, MX migrado, TLSA ainda não publicado
`DaneEnabled`	DANE ativo, TLSA publicado e funcional
`DnssecValidationFailed`	Falha na validação DNSSEC, verifique seu DS

Prazos

Migração MX: alguns minutos para o comando, depois o tempo de propagação DNS (variável conforme o TTL)
Publicação TLSA: 15 a 30 minutos após Enable-SmtpDaneInbound
Ponta a ponta: conte algumas horas, principalmente devido às propagações DNS

Verificar a implementação

Verificar os TLSA com dig

dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft +short

Resultado esperado:

3 1 1 A4B5C6D7E8F9...  (hash SHA-256 do certificado Exchange Online)

A Microsoft publica vários registros TLSA 3 1 1 (DANE-EE, SPKI, SHA-256) e 3 1 2 (DANE-EE, SPKI, SHA-512) para garantir redundância. É normal que alguns não correspondam ao certificado atual: apenas um match é suficiente para validar o DANE.

Verificar a conexão TLS

openssl s_client -starttls smtp \
  -connect captaindns-com.o-v1.mx.microsoft:25 \
  -servername captaindns-com.o-v1.mx.microsoft

Verifique se o certificado apresentado corresponde a um dos hashes TLSA publicados.

Verificar com o CaptainDNS

O inspetor DANE/TLSA mencionado no TL;DR testa automaticamente:

A presença e a validade DNSSEC no seu domínio
A resolução MX para o-v1.mx.microsoft
A presença dos registros TLSA na zona assinada
A correspondência entre o TLSA e o certificado TLS

Matriz de compatibilidade DANE por provedor de email

Erros comuns e soluções

DNSSEC validation failed

Causa: o registro DS no seu registrar não corresponde à chave KSK da sua zona.

Solução: verifique a correspondência entre o DS publicado e a chave KSK com dig DNSKEY captaindns.com +short e compare com o DS no seu registrar. Regenere o DS se necessário.

TLSA não publicado após ativação

Causa: o MX não foi migrado para o-v1.mx.microsoft, a Microsoft não conseguiu validar o DNSSEC, ou a propagação ainda está em andamento.

Solução: verifique se seu MX aponta para *.o-v1.mx.microsoft e que o antigo mail.protection.outlook.com foi removido. Verifique o status com Get-DnssecStatusForVerifiedDomain. Se o status for DnssecValidationFailed, corrija sua configuração DNSSEC antes de tentar novamente.

Antigo MX não removido

Causa: o antigo MX mail.protection.outlook.com coexiste com o novo o-v1.mx.microsoft, o que impede o DANE de funcionar corretamente.

Solução: siga o procedimento completo de migração MX. O novo MX deve estar com prioridade 0 e o antigo deve ser removido antes de ativar Enable-SmtpDaneInbound.

Relay terceiro bloqueando o DANE

Causa: um serviço de filtragem (Proofpoint, Mimecast) intercepta os MX e não suporta DANE.

Solução: o DANE protege apenas o último salto SMTP. Se seu relay não suporta DANE, você precisará escolher entre a filtragem terceirizada e o DANE. Alguns relays começam a suportar DANE em 2025-2026, verifique com seu provedor.

Emails rejeitados por servidores rigorosos

Causa: seu DANE está mal configurado e os servidores remetentes que aplicam uma política DANE estrita rejeitam as mensagens.

Solução: utilize a metodologia de solução de problemas descrita no nosso guia de troubleshooting DANE/TLSA (link no final da página) para diagnosticar o erro exato. Verifique prioritariamente a cadeia DNSSEC e a correspondência TLSA/certificado.

Microsoft 365 vs Google Workspace vs on-premise

Funcionalidade	Microsoft 365	Google Workspace	On-premise (Postfix)
DANE inbound	Sim (desde março de 2024)	Não	Sim (nativo)
DANE outbound	Sim	Sim	Sim (nativo)
Migração MX	Sim (`o-v1.mx.microsoft`)	N/A	Não (MX inalterado)
Gestão TLSA	Automática (Microsoft)	N/A	Manual
Gestão de certificado	Automática (Microsoft)	N/A	Manual (Let's Encrypt, etc.)
Pré-requisitos	DNSSEC + migração MX	-	DNSSEC + TLSA + certificado
Complexidade	Média (DNSSEC + migração)	N/A	Alta (tudo para gerenciar)
Rotação de certificado	Transparente	N/A	Deploy-hook necessário

Google Workspace

O Google suporta DANE em saída (verificação dos TLSA dos destinatários) desde 2023, mas não suporta DANE em entrada. Os domínios hospedados no Google Workspace não podem publicar TLSA pelo Google. Se você usa Google Workspace e deseja DANE inbound, atualmente não existe nenhuma solução.

Exchange Server on-premise

Para um servidor Exchange on-premise (2016, 2019), o DANE funciona como qualquer servidor SMTP auto-hospedado:

Você gerencia por conta própria o DNSSEC, os TLSA e os certificados
A configuração é semelhante à do Postfix (veja nosso tutorial Postfix/Bind/Let's Encrypt nos guias relacionados)
Você deve automatizar a rotação TLSA ao renovar os certificados

Complementar o DANE com MTA-STS e TLS-RPT

DANE e MTA-STS são complementares, não concorrentes:

DANE verifica o certificado via DNS/DNSSEC (forte, mas requer DNSSEC)
MTA-STS impõe TLS via política HTTPS (mais simples, mas depende das CAs)
TLS-RPT reporta falhas TLS e DANE por email diário

O Microsoft 365 suporta os três protocolos. Para segurança de email máxima:

Ative o DANE (este guia)
Publique uma política MTA-STS com nosso gerador MTA-STS
Ative o TLS-RPT para receber os relatórios de falha

FAQ

O Microsoft 365 suporta DANE?

Sim. A Microsoft lançou o suporte DANE inbound para o Exchange Online em disponibilidade geral em março de 2024. A ativação migra seu MX de mail.protection.outlook.com para o-v1.mx.microsoft, um domínio sob o TLD .microsoft assinado com DNSSEC. A Microsoft publica em seguida automaticamente os registros TLSA.

É necessário publicar os registros TLSA manualmente com o Microsoft 365?

Não. Ao contrário de um servidor self-hosted, a Microsoft gerencia automaticamente a publicação e a rotação dos registros TLSA na zona o-v1.mx.microsoft. Sua responsabilidade é ativar o DNSSEC no seu domínio e migrar o MX para o novo formato.

O Google Workspace suporta DANE inbound?

Não. O Google Workspace suporta apenas DANE em saída (verificação dos TLSA dos destinatários). Não existe uma forma de ativar DANE inbound para os domínios hospedados no Google Workspace.

Quanto tempo leva a ativação do DANE no Exchange Online?

A ativação é feita em duas fases. A migração MX (Enable-DnssecForVerifiedDomain) leva alguns minutos, mas a propagação DNS depende dos seus TTLs. A publicação TLSA (Enable-SmtpDaneInbound) leva de 15 a 30 minutos. Conte algumas horas no total, principalmente pelas propagações DNS.

O que acontece se o DNSSEC falhar no meu domínio?

Se o DNSSEC falhar (assinatura expirada, DS incorreto), a resolução DNS do seu domínio será comprometida. Os servidores DANE-aware não conseguirão mais validar os TLSA e rejeitarão ou adiarão os emails. Por isso o monitoramento DNSSEC é crítico.

O DANE funciona com um relay terceiro (Proofpoint, Mimecast)?

Parcialmente. O DANE protege apenas o último salto SMTP. Se seus MX apontam para um relay terceiro que retransmite para o Exchange Online, o DANE protege apenas o salto relay → Exchange. O salto remetente → relay não é coberto, a menos que o relay também suporte DANE.

É possível usar DANE e MTA-STS ao mesmo tempo?

Sim, e é recomendado. O DANE verifica o certificado via DNS/DNSSEC, o MTA-STS impõe TLS via HTTPS. Os dois protocolos são complementares. O Microsoft 365 suporta ambos simultaneamente.