Migração MX do Microsoft 365 para mx.microsoft: DNSSEC automático, Graph API obrigatória e ações a tomar antes de julho de 2026
Por CaptainDNS
Publicado em 6 de março de 2026
- 1º de julho de 2026: a Microsoft provisiona os MX dos novos Accepted Domains sob
mx.microsoftem vez demail.protection.outlook.com(MC1048624, adiado desde fevereiro de 2026) - Se o seu domínio tem DNSSEC ativo, a cadeia de confiança se estende automaticamente ao MX sob
mx.microsoft: DANE se torna possível sem nenhuma ação adicional - Qualquer automação que constrói o MX a partir do padrão
<domínio>.mail.protection.outlook.comvai quebrar após 1º de julho - A API Graph
serviceConfigurationRecordsse torna a única fonte de verdade - Os domínios existentes não são afetados imediatamente, mas a Microsoft planeja uma migração progressiva após julho de 2026
- Verifique agora mesmo se o seu domínio está pronto para DNSSEC com um diagnóstico DNSSEC : é o pré-requisito para se beneficiar da proteção DANE
Em 4 de abril de 2025, a Microsoft publicou o comunicado MC1048624: a partir de 1º de julho de 2026, todos os novos Accepted Domains adicionados ao Exchange Online receberão seus registros MX sob o domínio mx.microsoft e não mais sob mail.protection.outlook.com. A data inicial de fevereiro de 2026 foi adiada para julho após os feedbacks da comunidade.
Não se trata de uma mudança cosmética. O domínio mail.protection.outlook.com não é assinado com DNSSEC. Já o TLD .microsoft é assinado de ponta a ponta. Ao migrar os MX para mx.microsoft, a Microsoft elimina o principal obstáculo técnico à adoção de DNSSEC e DANE para os emails recebidos no Exchange Online. Os administradores não precisam mais acionar manualmente a migração do MX.
Para as equipes de TI, o impacto é duplo. Por um lado, é uma boa notícia: DNSSEC "gratuito" se o seu domínio já está assinado. Por outro, qualquer automação baseada no padrão <domínio>.mail.protection.outlook.com vai quebrar. Apenas a Graph API serviceConfigurationRecords fornecerá o valor MX correto.
Público-alvo: administradores Microsoft 365, MSPs que gerenciam tenants multi-domínio, equipes DevOps com workflows de provisionamento DNS automatizados.
O que muda concretamente em 1º de julho de 2026
Antes: mail.protection.outlook.com
Até agora, quando você adiciona um domínio personalizado ao Exchange Online, a Microsoft provisiona o MX em um formato previsível:
captaindns.com. 3600 IN MX 0 captaindns-com.mail.protection.outlook.com.
Esse formato permitia deduzir o valor MX a partir do nome de domínio: substitua os pontos por hífens e adicione .mail.protection.outlook.com. Muitas automações (scripts PowerShell, workflows Terraform, ferramentas de provisionamento MSP) exploram esse padrão.
Depois: mx.microsoft
A partir de julho de 2026, os novos Accepted Domains receberão um MX no formato:
captaindns.com. 3600 IN MX 0 captaindns-com.o-v1.mx.microsoft.
O sufixo o-v1.mx.microsoft não pode ser deduzido a partir do nome de domínio sozinho. O valor exato deve ser obtido pelo centro de administração do Exchange ou pela API Graph.
Cronograma detalhado
| Data | Evento |
|---|---|
| 4 de abril de 2025 | Publicação do comunicado MC1048624 |
| Fevereiro de 2026 | Data inicial prevista (adiada) |
| 2 de fevereiro de 2026 | Atualização: adiamento para julho de 2026 |
| Início de julho de 2026 | Início da migração progressiva |
| Final de julho de 2026 | Todos os novos Accepted Domains sob mx.microsoft |
| Após julho de 2026 | Migração progressiva dos domínios existentes (data não comunicada) |
Quem é afetado?
| Situação | Impacto |
|---|---|
| Domínio existente, MX já configurado | Nenhum impacto imediato. O MX atual sob mail.protection.outlook.com continua funcionando |
| Novo domínio adicionado após julho de 2026 | O MX será sob mx.microsoft. As automações baseadas no padrão antigo vão falhar |
| Automação de provisionamento DNS | Ação necessária: migrar para a API Graph serviceConfigurationRecords |
| DNSSEC já ativo no seu domínio | Bônus: DNSSEC se estende automaticamente ao MX, DANE ativável sem fricção |
Por que essa mudança? O problema DNSSEC do outlook.com
O domínio outlook.com, e por extensão mail.protection.outlook.com, não é assinado com DNSSEC. É uma escolha histórica da Microsoft: assinar um domínio tão massivo com tantos subdomínios dinâmicos traz desafios operacionais.
O problema: sem DNSSEC no MX, DANE é impossível. Um servidor remetente quer verificar o certificado TLS do Exchange Online via DANE. Ele precisa poder validar a cadeia DNSSEC de ponta a ponta, do MX até o TLSA. Se o MX aponta para um domínio não assinado, a cadeia se rompe.
A solução da Microsoft: o TLD .microsoft. Esse TLD de marca (brand TLD) é assinado com DNSSEC de ponta a ponta. Ao criar a infraestrutura mx.microsoft, a Microsoft obtém uma zona DNS inteiramente sob seu controle e assinada, sem as limitações herdadas do outlook.com.
A cadeia DNSSEC completa se torna:
root (.) → .microsoft → mx.microsoft → o-v1.mx.microsoft → captaindns-com.o-v1.mx.microsoft
Cada elo é assinado. Os registros TLSA publicados pela Microsoft sob _25._tcp.captaindns-com.o-v1.mx.microsoft são verificáveis por qualquer servidor remetente compatível com DANE.
Para entender em detalhes o funcionamento da cadeia de confiança DNSSEC, consulte nosso guia sobre a cadeia de confiança DNSSEC.
DNSSEC automático: o que você obtém gratuitamente
A mudança MC1048624 tem um efeito colateral importante: se o seu domínio já está assinado com DNSSEC, você se beneficia automaticamente da proteção DNSSEC de ponta a ponta para seus emails recebidos, sem nenhuma ação no centro de administração do Exchange.
Cenário 1: seu domínio não tem DNSSEC
Nada muda funcionalmente. O MX aponta para mx.microsoft em vez de mail.protection.outlook.com, mas a resolução DNS funciona normalmente. Sem DANE, sem verificação TLSA : o comportamento é idêntico ao atual.
Cenário 2: seu domínio tem DNSSEC ativo
A mágica acontece:
- O servidor remetente resolve o MX de
captaindns.com→captaindns-com.o-v1.mx.microsoft - A resposta é assinada com DNSSEC (seu domínio é assinado,
mx.microsofté assinado) - O servidor solicita o TLSA para
_25._tcp.captaindns-com.o-v1.mx.microsoft - A Microsoft publica automaticamente os registros TLSA correspondentes aos certificados do Exchange Online
- O servidor verifica o certificado TLS via DANE : autenticação do servidor sem depender das autoridades de certificação
Resultado: proteção contra ataques man-in-the-middle no transporte de email, automaticamente. Antes dessa mudança, obter DANE no Exchange Online exigia um procedimento manual de ativação. Após julho de 2026, para os novos domínios, é transparente.
A API Graph se torna a única fonte de verdade
Este é o ponto de ação crítico do comunicado MC1048624. A Microsoft afirma explicitamente:
"After July 1, 2026, List serviceConfigurationRecords Graph API will be the only source of truth for your Accepted Domains' MX record value."
O problema das automações atuais
Muitos scripts de provisionamento constroem o MX por convenção:
# ANTES: padrão previsível (VAI QUEBRAR após julho de 2026)
$domain = "captaindns.com"
$mx = $domain.Replace(".", "-") + ".mail.protection.outlook.com"
# Resultado: captaindns-com.mail.protection.outlook.com
Esse padrão não funciona mais com mx.microsoft. O sufixo pode variar e não é previsível.
A solução: serviceConfigurationRecords
# DEPOIS: usar a API Graph (OBRIGATÓRIO após julho de 2026)
Connect-MgGraph -Scopes "Domain.Read.All"
$records = Get-MgDomainServiceConfigurationRecord -DomainId "captaindns.com"
$mxRecord = $records | Where-Object { $_.RecordType -eq "Mx" }
$mxValue = $mxRecord.AdditionalProperties.mailExchange
# Resultado: captaindns-com.o-v1.mx.microsoft (valor real, não deduzido)
O endpoint REST correspondente:
GET https://graph.microsoft.com/v1.0/domains/captaindns.com/serviceConfigurationRecords
Authorization: Bearer {token}
A resposta JSON contém o valor MX exato no campo mailExchange do objeto domainDnsMxRecord:
{
"@odata.type": "microsoft.graph.domainDnsMxRecord",
"isOptional": false,
"label": "captaindns.com",
"recordType": "Mx",
"supportedService": "Email",
"ttl": 3600,
"mailExchange": "captaindns-com.o-v1.mx.microsoft",
"preference": 0
}
Permissões necessárias: Domain.Read.All (mínimo). O usuário conectado deve ter a função Administrador de nome de domínio ou Leitor global.
Outros records retornados pela API
A API também retorna os CNAME DKIM, o Autodiscover, o SPF e os SRV do Teams. É a oportunidade de migrar todas as suas automações DNS para essa fonte única:
| Tipo OData | Record | Campos-chave |
|---|---|---|
domainDnsMxRecord | MX | mailExchange, preference |
domainDnsTxtRecord | TXT (SPF) | text |
domainDnsCnameRecord | CNAME (DKIM, Autodiscover) | canonicalName |
domainDnsSrvRecord | SRV (Teams) | nameTarget, port, priority |
Preparar a transição: MTA-STS e TLS-RPT
Paralelamente ao DNSSEC e DANE, a Microsoft recomenda implantar MTA-STS e TLS-RPT para uma cobertura completa da segurança do transporte de email.
MTA-STS obriga os servidores remetentes a usar TLS para entregar os emails, mesmo que não suportem DANE. É uma rede de segurança complementar:
_mta-sts.captaindns.com. 3600 IN TXT "v=STSv1; id=20260306T000000"
TLS-RPT envia relatórios quando um servidor remetente falha ao estabelecer uma conexão TLS com o seu domínio:
_smtp._tls.captaindns.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
Para a configuração detalhada, consulte nossos guias: MTA-STS para Microsoft 365 e TLS-RPT completo.
Plano de ação antes de julho de 2026
- Auditar suas automações: procure qualquer script, workflow Terraform, playbook Ansible ou ferramenta MSP que constrói um MX a partir do padrão
mail.protection.outlook.com. Essa é a prioridade absoluta - Migrar para a API Graph: substitua a construção por convenção por uma chamada a
serviceConfigurationRecords. Teste agora mesmo em um domínio de teste - Ativar DNSSEC nos seus domínios: no seu registrar ou provedor DNS. É o pré-requisito para se beneficiar do DANE automático após a migração
- Verificar sua configuração DNSSEC: use
dig +dnssec captaindns.com SOApara confirmar que a flag AD está presente - Implantar MTA-STS e TLS-RPT: complete o dispositivo de segurança do transporte antes da migração
- Acompanhar os comunicados da Microsoft: o MC1048624 já foi adiado uma vez. Acompanhe as atualizações no centro de mensagens do Microsoft 365
FAQ
Meus domínios existentes são afetados por essa mudança?
Não, não imediatamente. O MC1048624 se aplica apenas aos novos Accepted Domains adicionados após 1º de julho de 2026. Seus domínios existentes mantêm o MX sob mail.protection.outlook.com. No entanto, a Microsoft planeja uma migração progressiva dos domínios existentes após essa data, sem cronograma definido. É prudente preparar suas automações desde já.
O que acontece se minha automação ainda usar o padrão antigo após julho de 2026?
Se você adicionar um novo domínio ao Exchange Online após julho de 2026 e sua automação construir o MX a partir de mail.protection.outlook.com, o MX estará incorreto. O fluxo de emails não funcionará para esse domínio até que você corrija o valor MX para corresponder ao exibido no centro de administração do Exchange ou retornado pela API Graph.
É necessário ativar o DANE manualmente após essa mudança?
Para os novos domínios provisionados após julho de 2026, se o seu domínio tem DNSSEC ativo, a cadeia DNSSEC se estende automaticamente ao MX sob mx.microsoft e a Microsoft publica os TLSA. Você não precisa de nenhuma ação adicional para o DANE inbound. Para os domínios existentes ainda sob mail.protection.outlook.com, o procedimento manual continua sendo necessário.
Qual é a diferença entre DANE automático e DANE ativado manualmente?
O resultado final é idêntico: um registro TLSA assinado com DNSSEC que autentica o certificado TLS do Exchange Online. A diferença está no caminho. Com a ativação manual (domínios existentes), você precisa acionar a migração do MX via PowerShell. Com os novos domínios após julho de 2026, o MX já está sob mx.microsoft e os TLSA são publicados automaticamente se o DNSSEC estiver ativo no seu domínio.
A API Graph serviceConfigurationRecords está disponível nas nuvens soberanas?
Sim. O endpoint está disponível na nuvem global, US Government L4, US Government L5 (DoD) e 21Vianet (China). As permissões necessárias são idênticas: Domain.Read.All no mínimo.
Como verificar se meu domínio está pronto para DNSSEC?
Execute dig +dnssec captaindns.com SOA e verifique se a flag ad (Authenticated Data) aparece na resposta. Se não aparecer, ative o DNSSEC no seu registrar. Consulte nosso guia de ativação DNSSEC para o procedimento detalhado de acordo com o seu provedor DNS.
Essa mudança afeta SPF, DKIM e DMARC?
Não. SPF (include:spf.protection.outlook.com), DKIM (CNAME para *.onmicrosoft.com) e DMARC não são afetados. Apenas o registro MX muda de sufixo. Os mecanismos de autenticação de email continuam funcionando como antes.
Por que a Microsoft adiou a data de fevereiro para julho de 2026?
A Microsoft não comunicou uma razão oficial. O adiamento foi anunciado em 2 de fevereiro de 2026 em uma atualização do MC1048624 com a menção "Thank you for your patience". É provável que os feedbacks da comunidade sobre a falta de preparação das automações tenham motivado esse prazo adicional.
Baixe as tabelas comparativas
Assistentes conseguem reutilizar os números consultando os ficheiros JSON ou CSV abaixo.
Glossário
- Accepted Domain: domínio personalizado adicionado a um tenant Microsoft 365 no centro de administração do Exchange e configurado para receber emails.
- MC1048624: identificador do comunicado da Microsoft no centro de mensagens do Microsoft 365 que descreve a migração DNS dos MX para mx.microsoft.
- serviceConfigurationRecords: endpoint da API Microsoft Graph que retorna a lista dos registros DNS necessários para ativar os serviços Microsoft 365 em um determinado domínio.
- Brand TLD: domínio de primeiro nível correspondente a uma marca (ex:
.microsoft,.google,.amazon), gerenciado pela empresa proprietária e geralmente assinado com DNSSEC. - DANE (DNS-based Authentication of Named Entities): mecanismo que vincula um certificado TLS a um nome de domínio por meio de um registro TLSA assinado com DNSSEC, eliminando a dependência das autoridades de certificação.
