SPF, DKIM & DMARC para Microsoft 365.
O Microsoft 365 (Exchange Online) não autentica seu domínio com um único assistente do jeito que um ESP hospedado faz — ele divide a tarefa entre dois consoles. O SPF é um include compartilhado de verdade (include:spf.protection.outlook.com) que você mescla no único registro SPF TXT do seu domínio, e o DKIM são dois registros CNAME de "selector" que você publica e depois ativa no portal do Microsoft Defender. O DMARC é um terceiro registro, à parte, que a Microsoft nunca cria para você. Deixe os três alinhados e o Exchange Online passa a enviar totalmente autenticado como o seu próprio domínio, em vez de se apoiar na assinatura padrão onmicrosoft.com.
Por que autenticar o Microsoft 365?
Autenticar um domínio do Microsoft 365 decide se o seu e-mail chega à caixa de entrada, e o M365 tem uma armadilha específica que silenciosamente quebra o DMARC. Desde fevereiro de 2024, o Gmail e o Yahoo exigem que todo remetente em massa (aproximadamente 5.000+ mensagens por dia) passe em SPF, DKIM e DMARC com alinhamento, e a partir de maio de 2025 a própria Microsoft começou a aplicar o mesmo ao e-mail de alto volume destinado ao Outlook.com/Hotmail/Live — então o e-mail corporativo que cai em caixas de entrada Microsoft de consumidores também precisa se autenticar. O detalhe exclusivo do M365: por padrão, o Exchange Online assina com DKIM o seu e-mail de saída usando o domínio onmicrosoft.com do tenant (d=contoso.onmicrosoft.com), que não alinha com o seu domínio From personalizado (contoso.com). O SPF da Microsoft alinha, então o e-mail direto consegue arranhar um DMARC pass só no SPF — mas no momento em que uma mensagem é encaminhada (listas de discussão, regras .forward, gateways de filtragem) o SPF quebra, e como o DKIM está assinando com o domínio errado não sobra nada para sustentar o DMARC. Configurar o DKIM de domínio personalizado é o que fecha essa lacuna e permite que a reputação de envio que você constrói se acumule no seu próprio domínio.
A realidade do SPF para o Microsoft 365
O Microsoft 365 é um provedor de "include" de verdade — ao contrário dos ESPs de delegação por CNAME (Mailchimp, Klaviyo) ou dos remetentes por conta (Amazon SES), existe um único include compartilhado real que você adiciona ao seu SPF raiz: include:spf.protection.outlook.com. Publique-o dentro de um único registro SPF TXT no domínio, por exemplo v=spf1 include:spf.protection.outlook.com -all. Duas coisas tornam o SPF do M365 excepcionalmente bem-comportado. Primeiro, o include resolve para um registro plano que contém apenas faixas ip4:/ip6: e o seu próprio -all — sem includes aninhados — de modo que custa apenas UMA das suas 10 consultas DNS de SPF (um mito comum diz 2–3; o registro ao vivo não tem sub-includes). Segundo, como o Exchange Online usa o seu próprio domínio como o SMTP MAIL FROM (envelope/Return-Path) por padrão, o SPF de fato ALINHA com o seu domínio, então o include do M365 contribui para um DMARC pass por conta própria — algo que os ESPs donos do Return-Path não conseguem fazer. A Microsoft recomenda explicitamente o qualificador -all (hard fail) porque também espera que você execute DKIM e DMARC. Duas ressalvas: apenas nuvens soberanas/governamentais diferem — GCC High e DoD usam include:spf.protection.office365.us, e o 21Vianet (China) usa include:spf.protection.partner.outlook.cn; e cada subdomínio de envio precisa do seu próprio registro SPF (o registro de contoso.com não cobre marketing.contoso.com).
Passo a passo
- 1
Confirme o domínio e localize seus registros DNS
Entre em admin.microsoft.com e vá até Configurações → Domínios, selecione o seu domínio e abra a aba de registros DNS. Se você delegou seus nameservers à Microsoft, ela pode já ter publicado o SPF e o MX (yourdomain-com.mail.protection.outlook.com). Se o seu DNS fica num registrador/host, saiba que o M365 não tem controles de SPF ou DMARC aqui — você mesmo vai adicionar esses registros no seu provedor de DNS.
- 2
Publique ou mescle o registro SPF
No seu provedor de DNS, crie UM registro TXT na raiz (host @): v=spf1 include:spf.protection.outlook.com -all. Se já existir um registro v=spf1 (Google Workspace, uma ferramenta de marketing etc.), mescle o include nesse único registro — nunca adicione um segundo SPF TXT. A Microsoft recomenda terminar com -all (hard fail). GCC High/DoD usam spf.protection.office365.us; o 21Vianet usa spf.protection.partner.outlook.cn.
- 3
Abra a aba DKIM
O DKIM personalizado NÃO está no centro de administração do M365. Vá até security.microsoft.com → E-mail e colaboração → Políticas e regras → Políticas de ameaças → Configurações de autenticação de e-mail e então selecione a aba DKIM.
- 4
Revele os dois valores CNAME
Clique no seu domínio personalizado. Um domínio que nunca foi configurado mostra Status = NoDKIMKeys e o botão Desabilitado. Deslize o botão para Habilitar — como os CNAMEs ainda não existem, ele abre uma caixa de diálogo de 'Erro do cliente' e o Status muda para CnameMissing. Isso é esperado, não uma falha: a seção 'Publicar CNAMEs' agora mostra os destinos CNAME exatos de selector1 e selector2. Copie-os (ou execute Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME,Selector2CNAME no Exchange Online PowerShell).
- 5
Adicione os dois CNAMEs de selector DKIM
Crie selector1._domainkey e selector2._domainkey como registros CNAME apontando para os destinos exatos que o portal lhe deu. Domínios mais novos (o formato que a Microsoft introduziu em maio de 2025) recebem destinos como selector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft (o <char>, por exemplo n ou r, é um caractere de partição que a Microsoft atribui); domínios configurados antes disso recebem selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com. Use o formato que o portal mostrar — os dois formatos não podem ser misturados no mesmo selector. Não os altere para TXT.
- 6
Mude o DKIM para Habilitado
Depois que os CNAMEs propagarem (geralmente minutos, até 48 horas), volte à aba DKIM, selecione o domínio e deslize o botão para Habilitar de novo. O Status muda para Válido e 'Rotacionar chaves DKIM' fica disponível. A partir de agora, o M365 assina com d=yourdomain.com em vez do padrão onmicrosoft.com, então o DKIM alinha.
- 7
Adicione o registro DMARC
O M365 não cria o DMARC. Adicione um registro TXT no host _dmarc: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Comece em p=none — o modo de monitoramento 'não tomar nenhuma ação' da Microsoft — para que nada seja afetado enquanto você confirma que tanto o SPF quanto o DKIM alinham, e aperte depois.
- 8
Envie um teste e leia os cabeçalhos
De uma caixa de correio no domínio, envie um e-mail para si mesmo no Gmail, abra a mensagem e escolha ⋮ → Mostrar original. Você quer SPF: PASS mostrando o seu domínio, DKIM: PASS com d=yourdomain.com (NÃO onmicrosoft.com) e DMARC: PASS. Depois, confirme que cada registro resolve com uma verificação de saúde de domínio.
Registros a adicionar
O Microsoft 365 gera os valores exatos no seu assistente de configuração — estes mostram o formato do que você vai adicionar no seu provedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| TXT | @ | v=spf1 include:spf.protection.outlook.com -allSPF raiz — mantenha exatamente UM registro SPF; mescle este include se você já tiver um registro v=spf1. Custa ~1 consulta DNS. |
| CNAME | selector1._domainkey | selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftChave DKIM 1 (rotacionada automaticamente). Ilustrativo — copie o destino exato do portal do Defender; domínios criados antes de maio de 2025 terminam em .onmicrosoft.com em vez de .n-v1.dkim.mail.microsoft. |
| CNAME | selector2._domainkey | selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftChave DKIM 2 (o segundo selector permite que a Microsoft rotacione as chaves). Ilustrativo — use o valor exato do portal. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVocê mesmo adiciona isto — o M365 nunca o cria. Um por domínio; comece em p=none. |
| MX | @ | contoso-com.mail.protection.outlook.comRoteia o e-mail de entrada para o Exchange Online (prioridade 0). Não é um registro de autenticação, mas faz parte da configuração do M365; os pontos no seu domínio viram hifens. |
Mantenha exatamente um registro TXT de SPF (v=spf1) no seu domínio raiz — combine todos os remetentes nele. Ter dois registros SPF já é, por si só, um erro.
O limite de 10 consultas de DNS
O SPF tem um limite rígido de 10 consultas de DNS — se passar disso, ele retorna um permerror e para de validar em todo lugar. Veja quanto a configuração do Microsoft 365 consome desse limite.
O Microsoft 365 usa 1 das suas 10 consultas; os mecanismos ip4: e ip6: são gratuitos.
DKIM
O DKIM no Microsoft 365 é a parte que as pessoas erram, porque o M365 já está 'assinando' o e-mail antes de você fazer qualquer coisa — só que com o domínio errado. Por padrão, o Exchange Online assina com DKIM o e-mail de saída usando o domínio onmicrosoft.com inicial do seu tenant (d=contoso.onmicrosoft.com). Essa assinatura é válida, mas não alinha com o seu domínio From personalizado, então não faz nada pelo DMARC em contoso.com. Para corrigir isso, você habilita o DKIM de domínio personalizado: dois registros CNAME, selector1._domainkey e selector2._domainkey, que delegam as chaves públicas de volta à Microsoft. Como são CNAMEs (e não registros TXT que você cola), a Microsoft mantém as chaves privadas e usa os dois selectors para rotacionar as chaves automaticamente sem que você jamais toque no DNS de novo. O formato do destino mudou em maio de 2025: domínios personalizados mais novos recebem selector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft (o <char>, por exemplo n ou r, é um caractere de partição que a Microsoft atribui), enquanto domínios configurados antes disso ainda usam selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com — o portal (ou Get-DkimSigningConfig no Exchange Online PowerShell) mostra exatamente qual deles o seu tenant recebeu, e os dois formatos não podem coexistir para um selector. Fluxo de trabalho: revele os CNAMEs no portal do Defender (Configurações de autenticação de e-mail → DKIM), publique ambos no seu provedor de DNS, aguarde a propagação e então acione o botão de DKIM do domínio para Habilitado até que o Status mostre Válido. As chaves são de 1024 bits por padrão; 2048 bits está disponível via New-DkimSigningConfig (com -KeySize 2048). Só depois que o botão estiver Habilitado é que o M365 assina com d=yourdomain.com e o DKIM começa a alinhar.
DMARC
O DMARC é um registro TXT de política à parte no seu domínio que o Microsoft 365 não cria — você o adiciona no seu provedor de DNS. Publique-o em _dmarc.yourdomain.com começando com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é o modo de monitoramento 'não tomar nenhuma ação' recomendado pela Microsoft: ele não altera nada na entrega enquanto você observa os relatórios agregados (rua) para confirmar que o M365 (e quaisquer outros remetentes) passam em SPF e DKIM alinhados ao seu domínio. A própria orientação da Microsoft é colocar a assinatura DKIM e o DMARC em modo de monitoramento no ar rapidamente e então escalar a política — apertando para p=quarantine e depois p=reject, assim que o alinhamento estiver consistente. Mantenha apenas um registro _dmarc para todo o domínio organizacional; os subdomínios herdam a política do pai automaticamente (você pode substituir a de um subdomínio específico com o seu próprio registro _dmarc ou a tag sp=). Como o SPF do M365 alinha e, depois que você configura o DKIM personalizado, o DKIM também alinha, um domínio M365 corretamente configurado passa no DMARC por ambos os mecanismos — a configuração resiliente que sobrevive ao encaminhamento.
Confirme que funcionou de verdade
Não confie apenas no selo 'Válido' do portal do Defender — confirme numa mensagem real. Envie a si mesmo um teste de uma caixa de correio no domínio, abra-o no Gmail e escolha ⋮ → Mostrar original: você quer SPF: PASS, DKIM: PASS com d=yourdomain.com (o sinal revelador da falha é d=yourtenant.onmicrosoft.com, que significa que o DKIM personalizado ainda não está habilitado) e DMARC: PASS. No portal do Defender, a aba DKIM deve mostrar Status = Válido e Botão = Habilitado para o domínio. Depois, passe o seu domínio pela verificação de saúde de domínio da Qualisend para confirmar que o SPF, os dois CNAMEs de selector DKIM e o registro DMARC resolvem todos sem problemas e, assim que os relatórios agregados de DMARC começarem a chegar, coloque um deles no analisador de relatórios DMARC — o Outlook.com / Exchange Online deve aparecer como uma fonte alinhada e aprovada.
Pegadinhas comuns
- Cobertura
A armadilha nº 1 do M365: até você habilitar o DKIM de domínio personalizado, o e-mail é assinado como d=yourtenant.onmicrosoft.com, que NÃO alinha — então o DMARC não recebe ajuda do DKIM e quebra no momento em que uma mensagem é encaminhada. Só SPF não basta.
- Configuração de DNS
A caixa de diálogo de 'Erro do cliente' / o status CnameMissing que você recebe quando desliza o botão de DKIM para Habilitar pela primeira vez é esperado, não um bug — é assim que o portal revela os valores CNAME. Publique os dois CNAMEs, depois volte e acione Habilitar de novo.
- Configuração de DNS
Os destinos CNAME de DKIM mudaram em maio de 2025: domínios personalizados configurados desde então apontam para <tenant>.<char>-v1.dkim.mail.microsoft, os mais antigos para <tenant>.onmicrosoft.com. Copie o destino exato do portal do Defender (ou Get-DkimSigningConfig) — os formatos antigo e novo não podem ser misturados no mesmo selector.
- Quebra a autenticação
Mantenha exatamente UM registro SPF TXT no domínio. Se você já envia via Google Workspace, SendGrid etc., mescle include:spf.protection.outlook.com nesse único registro — dois registros SPF TXT já são, por si só, um PermError.
- Cobertura
M365 provisionado pela GoDaddy ou IONOS costuma vir com um SPF padrão de include:secureserver.net, que NÃO autoriza as caixas de correio do Exchange Online. Ele precisa resolver para include:spf.protection.outlook.com.
- Configuração de DNS
Os registros DKIM do M365 são CNAMEs, então se o seu DNS estiver atrás do Cloudflare configure cada registro de selector como 'DNS only' (nuvem cinza) — um CNAME com proxy de nuvem laranja não resolve para o host da Microsoft e a habilitação do DKIM falha.
- Configuração de DNS
Fique atento aos erros de sintaxe de SPF que a Microsoft aponta: sem ponto no final (include:spf.protection.outlook.com. está errado), dois-pontos em vez de sinal de igual depois de 'include' e sem espaço depois dos dois-pontos. Muitos registradores também acrescentam automaticamente o seu domínio aos campos de CNAME/host, duplicando-o.
- Cobertura
Cada subdomínio de envio precisa do seu próprio SPF (e do seu próprio DKIM). O registro em contoso.com não cobre marketing.contoso.com — ferramentas de envio em massa/marketing que enviam de um subdomínio precisam de SPF, DKIM e, normalmente, do seu próprio tratamento de DMARC ali.
Monte seu registro SPF
O Microsoft 365 já vem pré-selecionado abaixo. Adicione as outras plataformas pelas quais você envia e publique o registro único e combinado.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF do Microsoft 365 — Perguntas frequentes
Leituras relacionadas
Depois de publicado, confirme se tudo resolve corretamente com o verificação de saúde do domínio e, em seguida, veja quem está enviando em seu nome com o analisador de relatórios DMARC. Explore todas as fontes de envio no gerador. A autenticação, porém, é só metade da entregabilidade — um IP ou domínio de envio que esteja listado ainda te joga no spam por mais limpo que seu SPF esteja, então vale a pena acompanhar as blacklists com o monitoramento de blacklists.
Autenticado — agora mantenha a lista limpa
Passar em SPF, DKIM e DMARC te leva à caixa de entrada; uma lista limpa te mantém lá. Verifique a sua — comece grátis com 100 créditos, sem precisar de cartão.