Defaults.Exposed › Correções › Guides
DKIM passa mas o DMARC falha: a armadilha da assinatura por omissão gappssmtp.com / onmicrosoft.com (2026)
Publicado 2026-07-08
Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.
O seu correio passa o DKIM com a assinatura por omissão do fornecedor — d= a terminar em gappssmtp.com (Google Workspace) ou onmicrosoft.com (Microsoft 365) — mas esse domínio não corresponde ao seu domínio do From, portanto o DMARC não obtém nenhum pass alinhado. Ative a assinatura com domínio próprio para o corrigir. De 12.145.313 domínios que autorizam os servidores de correio da Google, só 18,5% aplicam o DMARC, segundo o censo do Defaults.Exposed de 261.086.232 domínios classificados.
A correção é das mais limpas em autenticação de email: ligar a assinatura DKIM com domínio próprio. No Google Workspace é o ecrã “Autenticar email” da consola de administração — gere a chave, publique um registo TXT, ligue. No Microsoft 365 é a página DKIM do portal Defender — publique dois CNAMEs de seletor, ative. Vinte minutos de trabalho, e o DMARC recebe finalmente o pass alinhado por que esperava.
Porque é que o DKIM passa mas o DMARC continua a falhar?
Porque o DMARC não pergunta “existe uma assinatura DKIM válida?” — pergunta “existe uma assinatura DKIM válida para o domínio do cabeçalho From?” Essa segunda condição chama-se alinhamento, e é todo o propósito do DMARC: provar que o domínio que o seu destinatário vê é o domínio que assinou.
De fábrica, o Google Workspace assina o seu correio com um domínio como yourdomain-com.20230601.gappssmtp.com (o carimbo de data varia por domínio) e o Microsoft 365 assina com yourtenant.onmicrosoft.com. Ambas as assinaturas são criptograficamente válidas — os verificadores de DKIM dizem pass — mas o domínio d= pertence à Google ou à Microsoft, não a si. Mesmo sob o alinhamento relaxado do DMARC, que só exige que os domínios organizacionais coincidam, gappssmtp.com não é yourdomain.com. Sem correspondência não há pass alinhado, e se o SPF também não alinhar (muitas vezes não pode — os recetores avaliam o SPF contra o domínio do Return-Path, não contra o cabeçalho From, e o reencaminhamento parte-o por completo), o DMARC falha.
Esta é a armadilha definidora das omissões dos fornecedores: a omissão dá-lhe entregabilidade, não proteção — o alinhamento é a volta da chave que falta. O censo mostra quantos remetentes param na omissão: dos 12.145.313 domínios que autorizam os servidores de correio da Google via _spf.google.com (de 138.927.207 publicadores de SPF em todo o mundo), só 18,5% aplicam o DMARC. O quadro da Microsoft tem a mesma forma: 10.205.070 domínios autorizam spf.protection.outlook.com, 85,0% transportam o registo SPF estrito que a configuração do M365 lhes entrega — e só 21,7% aplicam o DMARC. Comparação completa na nossa tabela classificativa de SPF por fornecedor de email.
A armadilha é invisível no dia a dia: o correio entrega, os testes de caixa de entrada parecem bem, nada dá erro — até publicar uma política DMARC e o seu próprio correio começar a falhá-la. A nossa verificação gratuita expõe exatamente esta lacuna.
Como identifico a armadilha da assinatura por omissão no Authentication-Results?
Abra uma mensagem que enviou (para uma caixa Gmail ou Outlook), veja o código-fonte original e encontre o cabeçalho Authentication-Results. O sinal denunciador é um pass de DKIM com o d= errado — um exemplo recebido no Gmail parece-se com:
Authentication-Results: mx.google.com;
dkim=pass [email protected];
spf=pass smtp.mailfrom=yourdomain.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com
Leia-o como três perguntas:
| Fragmento do cabeçalho | O que significa | Veredicto |
|---|---|---|
dkim=pass header.d=yourdomain.com | Assinatura válida E corresponde ao seu domínio do From | Alinhado — este é o objetivo |
dkim=pass header.d=…gappssmtp.com ou …onmicrosoft.com | Assinatura válida mas é o domínio por omissão do fornecedor — o DMARC ignora-a para o alinhamento | A armadilha: pass sem proteção |
dkim=fail (qualquer d=) | Assinatura inválida — problema diferente | Veja como corrigir o DKIM |
Em correio recebido pela Microsoft, a mesma história aparece como dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com ao lado de compauth=fail — o padrão coberto no guia de rejeições do Outlook.
Se o seu cabeçalho mostrar em vez disso ambos dkim=pass e spf=pass com um fail de DMARC, está no caso mais amplo de alinhamento — o guia “DMARC falha mas SPF e DKIM passam” percorre o alinhamento relaxado vs estrito por inteiro.
Como ativo a assinatura DKIM com domínio próprio?
- Execute a verificação gratuita em defaults.exposed antes de tocar em alguma coisa. Mostra se o seu domínio tem DKIM alinhado, qual é realmente a sua política DMARC e se mais alguma coisa (SPF, sintaxe do registo DMARC) ainda o bloqueará depois desta correção — para fazer o trabalho todo de uma vez.
- Identifique com que omissão está a assinar. Verifique
header.d=no Authentication-Results como acima:gappssmtp.comsignifica a omissão do Google Workspace,onmicrosoft.comsignifica a omissão do Microsoft 365. - Google Workspace: gere e publique a sua própria chave. Na consola de administração vá a Apps → Google Workspace → Gmail → Autenticar email, selecione o seu domínio e clique em Gerar novo registo (2048 bits, a menos que o seu alojamento de DNS não o consiga armazenar). Publique o registo TXT que lhe dá em
google._domainkey.yourdomain.com, espere pelo DNS (até 48 horas), e depois — o passo que as pessoas esquecem — clique em Iniciar autenticação. Gerar o registo não faz nada até ligar a assinatura. Passo a passo completo: configurar o DKIM no Google Workspace. - Microsoft 365: publique os dois CNAMEs de seletor e ative. No portal Defender vá a Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, selecione o seu domínio personalizado e crie as chaves. Publique ambos os CNAMEs —
selector1._domainkeyeselector2._domainkey, a apontar para os alvos que a Microsoft lhe mostra (copie os alvos exatos do portal — domínios ativados antes de maio de 2025 terminam no.onmicrosoft.comdo seu tenant; os mais recentes terminam em.dkim.mail.microsoft) — e depois ative a assinatura. Dois seletores não é opcional: a Microsoft roda as chaves entre eles. Passo a passo completo: configurar o DKIM no Microsoft 365. - Verifique a nova assinatura. Envie uma mensagem nova para uma caixa de correio externa e volte a verificar o Authentication-Results:
dkim=passdeve agora mostrarheader.d=yourdomain.com. Se o seu painel de DNS acrescentou automaticamente a sua zona ao alvo do CNAME ou estropiou o valor TXT longo, a assinatura não vai mudar — as manias dos painéis, não o fornecedor, causam a maioria das falhas aqui. - Volte a verificar e leve o pass alinhado a algum lado. Confirme que a verificação mostra DKIM alinhado, e depois use-o: uma política DMARC em
p=nonenão protege nada. Em todos os 261.086.232 domínios classificados, só 10,59% aplicam o DMARC (dados a 2026-06-29) — o DKIM alinhado é o que torna a aplicação segura de apertar. Comece em como corrigir o DMARC.
Ativar o DKIM personalizado vai partir alguma coisa?
Não — esta é a rara correção de autenticação de email essencialmente sem raio de explosão: o correio que saía com a assinatura por omissão passa simplesmente a sair com uma melhor, e o fornecedor continua a gerir as chaves (a Microsoft roda automaticamente entre os dois seletores). O verdadeiro modo de falha é fazê-lo pela metade — publicar o TXT da Google mas nunca clicar em Iniciar autenticação, ou publicar um seletor do M365 em vez de ambos. E não apague os registos DNS mais tarde “para arrumar”; a assinatura para no momento em que a chave desaparece.
Uma nota de âmbito: isto corrige o correio enviado através da Google ou da Microsoft. As ferramentas de newsletters e os CRMs também assinam com as suas próprias omissões, e cada um precisa do seu próprio DKIM de domínio personalizado ligado — esse padrão, e as regras de remetentes em massa do Gmail que agora o exigem, estão cobertos no guia do 550-5.7.26.
Perguntas frequentes
O DKIM mostra “pass” em todas as ferramentas de teste — porque é que algo precisa de correção?
Porque as ferramentas respondem a uma pergunta mais estreita do que o DMARC. A assinatura é válida — mas é a de gappssmtp.com ou de onmicrosoft.com, não a sua, portanto não conta para nada no alinhamento do DMARC. É por isso que tantos remetentes param na omissão: de 12.145.313 domínios que autorizam a Google, só 18,5% aplicam o DMARC (dados a 2026-06-29).
O alinhamento relaxado do DMARC deixa passar a assinatura por omissão?
Não. O alinhamento relaxado só afrouxa a correspondência para domínios organizacionais — mail.yourdomain.com alinha com yourdomain.com. O domínio organizacional da assinatura por omissão é gappssmtp.com ou onmicrosoft.com, que não partilha nada com o seu. Nenhum modo de alinhamento salva um d= de terceiros.
A assinatura gappssmtp.com / onmicrosoft.com é má? Devo removê-la? Não é má — garante que o seu correio transporta alguma assinatura válida, o que ajuda a filtragem de spam. Só não é sua. Não a remove; substitui-a ao ativar a assinatura com domínio próprio.
O meu domínio está no Microsoft 365 com SPF estrito — já estou coberto?
Provavelmente não: esse registo estrito é a omissão do M365 a fazer a sua única tarefa. De 10.205.070 domínios que autorizam spf.protection.outlook.com, 85,0% têm SPF estrito mas só 21,7% aplicam o DMARC (dados a 2026-06-29). O SPF também se parte com o reencaminhamento, porque é avaliado contra o Return-Path e não contra o cabeçalho From — o DKIM alinhado é a perna que sobrevive, e é exatamente por isso que esta correção importa.
Quanto tempo demora a correção? O trabalho na consola são minutos por fornecedor. O DNS é a espera: a Google diz para contar com até 48 horas antes de iniciar a autenticação; os CNAMEs da Microsoft costumam estar ativos em horas. Conte com um dia útil de ponta a ponta, a maior parte dele à espera.
Envie o relatório ao proprietário
Se está a corrigir isto para um cliente ou para o seu empregador, feche o ciclo com evidência. Volte a executar a verificação gratuita assim que a nova assinatura estiver ativa e reencaminhe o relatório classificado ao dono do negócio: datado, em linguagem simples, a mostrar o DKIM alinhado com o domínio dele. É o comprovativo para a renovação do seguro cibernético e para o próximo questionário de segurança de fornecedor — prova de que o domínio se autentica como ele próprio, não como um subinquilino de gappssmtp.com.
Verifique o seu alinhamento DKIM gratuitamente
Veja se o seu correio assina como o seu próprio domínio — e exatamente o que corrigir — em privado e apenas para o proprietário.
Verifique o seu domínio → · DMARC falha mas SPF e DKIM passam → · Corrigir o DKIM → · Configurar o DKIM no Google Workspace → · Apenas dados agregados. Dados armazenados e processados na UE.