Defaults.Exposed › Correções › Guides

"Política DMARC não ativada": o que os verificadores querem dizer, e o primeiro passo honesto de 5 minutos (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.

“Política DMARC não ativada” significa uma de duas coisas diferentes: o seu domínio não tem registo DMARC nenhum, ou tem um definido como p=none. Só 10,59% dos domínios — 27.640.987 de 261.086.232 — aplicam uma política DMARC, segundo o censo do Defaults.Exposed. Publicar um registo de monitorização leva cinco minutos; a aplicação é um projeto.

Este guia descodifica o aviso, dá-lhe o registo TXT exato a publicar e o sítio exato onde o pôr, percorre os deslizes de sintaxe que fazem falhar as primeiras tentativas, e define uma expectativa honesta de como será a sua primeira semana de relatórios DMARC. Deliberadamente, não é um guia “corrija o DMARC em 5 minutos” — os cinco minutos dão-lhe visibilidade, não proteção.

O que significa realmente “política DMARC não ativada”?

Verificadores como o MXToolbox condensam dois achados diferentes num único aviso laranja, e o caminho da correção depende de qual deles tem:

Dados a 2026-06-29.

A primeira linha é onde vive a maior parte da internet: 75,11% dos domínios classificados não publicam registo DMARC nenhum, e outros 14,29% estão parados em p=none. O inverso da última linha é o número que interessa: 89,41% dos domínios não têm política DMARC aplicada — de 261.086.232 domínios classificados no censo. Se o seu verificador mostra o aviso, está na esmagadora maioria. Isso não é consolo; é a razão pela qual a falsificação continua barata.

Uma clarificação que poupa confusões mais tarde: o DMARC é a camada de política por cima do SPF e do DKIM, verificada contra o cabeçalho From que o seu destinatário realmente vê. “Não ativada” significa que ainda não disse aos recetores para fazerem seja o que for. Se os três valores de política são novos para si, a explicação em linguagem simples está em o que é o DMARC: none, quarantine, reject.

O que pode honestamente corrigir em cinco minutos?

Publicar um registo. É essa a totalidade da afirmação honesta.

v=DMARC1; p=none; rua=mailto:[email protected]

Cinco minutos depois de este registo TXT entrar em vigor, os recetores que verificam o DMARC começam a compilar relatórios diários sobre quem anda a enviar correio como o seu domínio — servidores legítimos e impostores por igual. Essa visibilidade é genuinamente valiosa e genuinamente instantânea.

O que não faz: p=none não protege nada. O correio falsificado é entregue exatamente como era ontem, e um verificador que volte a analisar amanhã pode ainda dizer “política não ativada” — corretamente, porque o visto verde está reservado para quarantine ou reject. Explicámos porquê em p=none não é proteção; o caminho faseado para uma política que realmente bloqueia a falsificação está em de p=none a p=reject. O passo de cinco minutos abaixo é como começa; esse guia é como termina.

Como se publica o primeiro registo DMARC?

1. Execute a verificação gratuita antes de tocar no DNS. Diz-lhe qual dos dois achados realmente tem — nenhum registo vs. p=none — e se o SPF e o DKIM estão montados por baixo, o que decide a rapidez com que poderá avançar para a aplicação mais tarde.
2. Escolha um endereço para receber os relatórios. Uma caixa de correio dedicada como dmarc-reports@oseudominio chega para começar. Se em vez disso usar um serviço de análise de relatórios, veja as perguntas frequentes abaixo — os endereços de terceiros têm uma armadilha silenciosa.
3. Adicione um registo TXT no host _dmarc. Na maioria dos painéis de DNS (veja o guia de configuração de DMARC na IONOS para um exemplo trabalhado) introduz _dmarc no campo host/nome — o painel acrescenta o seu domínio automaticamente, produzindo _dmarc.oseudominio.com. Valor: v=DMARC1; p=none; rua=mailto:[email protected]
4. Verifique que resolveu. dig TXT _dmarc.yourdomain.com (ou qualquer verificador online) deve devolver exatamente um registo que começa por v=DMARC1. A maioria das alterações de DNS fica visível em minutos; um TTL baixo ajuda.
5. Volte a verificar. O seu relatório vai mostrar o DMARC presente em modo de monitorização — um reflexo honesto de onde está: relatórios ligados, aplicação pendente.

Um registo cobre também os seus subdomínios: os recetores que não encontram registo em mail.oseudominio.com recorrem à política do domínio organizacional, portanto não precisa de um registo por subdomínio para começar a monitorizar.

Quais são os erros mais comuns ao adicionar o registo?

Quase todas as primeiras tentativas falhadas são um destes — e importam, porque um registo que não se consegue interpretar é tratado como registo nenhum. O censo conta 48.648 registos DMARC publicados que falham a interpretação; as gralhas que as pessoas realmente publicam estão catalogadas em o censo de gralhas do DMARC.

• Host errado. O registo tem de viver em _dmarc.oseudominio.com, não no apex. No domínio nu não faz nada, e os verificadores continuam a reportar “no DMARC record found”.
• Domínio acrescentado em duplicado. Escrever _dmarc.oseudominio.com num painel que acrescenta automaticamente dá-lhe _dmarc.oseudominio.com.oseudominio.com. Introduza apenas _dmarc.
• Vírgulas em vez de pontos e vírgulas. As tags são separadas por ;. Um registo que não se consegue interpretar é tratado como registo nenhum.
• v=DMARC1 em falta ou fora do sítio. Tem de ser a primeira tag, escrita exatamente assim; registos que começam por p= falham a interpretação.
• mailto: em falta no rua. rua=dmarc@yourdomain é inválido; tem de ser rua=mailto:[email protected].
• Dois registos DMARC. Os recetores que encontram mais de um registo v=DMARC1 ignoram-nos todos — a mesma família de falha do SPF com múltiplos registos.
• Aspas curvas do copiar-colar. Aspas curvas ou espaços inseparáveis contrabandeados de um documento partem a interpretação. Volte a digitar o registo se um verificador disser que está malformado mas ele parecer certo.

Como vão ser os relatórios rua na primeira semana?

Ajuste as expectativas já, para não concluir que está avariado:

• Chegam mais ou menos diariamente, por recetor. A Google normalmente envia um relatório agregado a cada 24 horas; a Microsoft, a Yahoo e outros nos seus próprios ciclos. Para um domínio pequeno, a primeira semana costuma significar uma mão-cheia de emails, sobretudo de [email protected].
• São anexos XML comprimidos, não um painel. Em bruto, são quase ilegíveis; um analisador gratuito transforma-os numa tabela de remetentes.
• O volume acompanha o seu volume de correio. Se envia pouco correio, ou sobretudo para fornecedores que não reportam, conte com dados esparsos. Duas semanas caladas é normal para um domínio de baixo volume — verifique o registo com dig em vez de assumir que falhou.
• Conte com surpresas. A maioria dos domínios descobre remetentes de que se esqueceu — o CRM, a ferramenta de faturação, o formulário de contacto. Cada um precisa de SPF ou DKIM alinhado antes de poder aplicar. Se os relatórios mostrarem o DMARC a falhar enquanto o SPF e o DKIM passam individualmente, isso é um problema de alinhamento — veja DMARC falha mas SPF e DKIM passam.

E peça de facto os relatórios: 64,3% dos domínios com registo DMARC não publicam endereço rua= nenhum, portanto não recebem relatórios dele — o corte do censo sobre isso está em DMARC a publicar às cegas. Tudo o que aprender aqui alimenta a implantação da aplicação — a monitorização é a primeira semana desse projeto, não um destino. Estacionar em p=none indefinidamente é a forma mais comum de os domínios acabarem nos 89,41%.

Perguntas frequentes

Publicar p=none prejudica a entregabilidade do meu email? Não. p=none não muda nada na forma como os recetores tratam o seu correio — apenas pede relatórios. Pode ajudar: os requisitos para remetentes em massa da Google e da Yahoo exigem pelo menos um registo DMARC p=none aos remetentes de alto volume, portanto publicar um é um piso de conformidade, não um risco.

Publiquei o registo — porque é que o verificador ainda diz “policy not enabled”? Porque está a dizer-lhe a verdade: a sua política é none, e os verificadores reservam o aprovado para quarantine ou reject. Juntou-se aos domínios que monitorizam mas não aplicam — a 2026-06-29, só 10,59% de 261.086.232 domínios classificados aplicam. O aviso desaparece quando completar a implantação até à aplicação.

Preciso de ter o SPF e o DKIM montados antes de adicionar o DMARC? Precisa de pelo menos um deles, alinhado, para o seu correio passar o DMARC — mas não precisa de os ter perfeitos antes de publicar p=none. A monitorização é precisamente como descobre o que está partido: 70.368.600 de 261.086.232 domínios classificados (a 2026-06-29) têm SPF brando e nenhuma aplicação de DMARC, e os relatórios são a forma de descobrirem o que os está a travar.

Posso enviar os relatórios para um analisador de terceiros em vez da minha própria caixa de correio? Pode — mas um endereço rua num domínio diferente exige que o fornecedor publique um registo de autorização (yourdomain._report._dmarc.vendor.com), ou os recetores retêm os relatórios silenciosamente. Os serviços de confiança fazem-no automaticamente; se os relatórios nunca chegarem, verifique isto primeiro.

Envie o relatório ao proprietário

Se está a corrigir isto para um cliente ou empregador, não deixe o trabalho ficar invisível. Volte a executar a verificação gratuita depois de o registo resolver e reencaminhe o relatório classificado: mostra o DMARC a passar de ausente a monitorizado, com carimbo de data e em linguagem simples — e mostra o que se segue no caminho para a aplicação. Os proprietários precisam cada vez mais exatamente desta evidência para renovações de seguro cibernético e questionários de segurança de fornecedores, e um relatório classificado de uma página responde a essas perguntas melhor do que alguma vez responderá uma captura de ecrã de um painel de DNS.

Verifique o seu domínio gratuitamente

Veja qual dos dois achados tem — nenhum registo ou p=none — e o que está por baixo, em privado e apenas para o proprietário.

Verifique o seu domínio → · Corrigir o DMARC → · De p=none a p=reject → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.