DMARC de p=none para p=reject sem perder email legítimo: a implantação faseada (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.

Passe o DMARC de p=none para p=reject em quatro etapas: monitorize os relatórios rua durante 2–4 semanas, corrija todos os remetentes legítimos, suba p=quarantine com pct, depois rejeite — nunca salte diretamente para reject. 70.368.600 de 261.086.232 domínios classificados estão parados em SPF brando sem aplicação de DMARC, segundo o censo do Defaults.Exposed.

Este é o runbook operacional: uma tabela de etapas com critérios de saída, o registo para cada etapa, a subtileza do pct do RFC 7489 que muda o que “50%” significa em reject, e a tag sp= para subdomínios. Se está a decidir se deve aplicar, leia primeiro as 6 etapas da maturidade DMARC — esse é o enquadramento; e se os próprios níveis de política são novos para si, o que p=none, p=quarantine e p=reject realmente significam é a introdução. Esta página é o fazer.

Porque é que não pode saltar diretamente para p=reject?

Porque p=reject diz a todos os recetores que a honram para devolver o correio que falha o DMARC — e até ter observado os seus relatórios, não sabe o que falha. Quase todos os domínios que ligam a monitorização descobrem remetentes legítimos de que se esqueceram: o CRM, a ferramenta de faturação, um formulário de contacto. Salte para reject no primeiro dia e esse correio não vai para o spam; desaparece no momento SMTP. Perder uma remessa de faturas ensina uma organização a temer o DMARC, e o registo é revertido para p=none permanentemente — de 261.086.232 domínios classificados, 37.312.637 estão estacionados exatamente aí, e só 10,59% (27.640.987) chegam alguma vez a uma política aplicada.

A outra razão é o alinhamento. O DMARC só passa quando o SPF ou o DKIM passam e alinham com o domínio do From visível — o SPF contra o domínio do Return-Path (RFC5321.MailFrom), o DKIM contra o d= da assinatura. Os remetentes de terceiros normalmente passam o SPF no domínio deles, não no seu, e é por isso que a etapa de corrigir todas as origens é sobretudo ativar o DKIM de domínio próprio de cada fornecedor — desmontado em DMARC falha mas SPF e DKIM passam.

Quais são as quatro etapas da implantação?

Etapa	Registo de política	pct	O que acontece ao correio que falha	Critérios de saída
1. Monitorizar	`p=none; rua=mailto:…`	—	Entregue normalmente; você recebe relatórios agregados	2–4 semanas de relatórios; todos os remetentes neles identificados como legítimos ou não
2. Corrigir origens	`p=none` (inalterado)	—	Ainda entregue normalmente	Todas as origens legítimas passam o DMARC alinhadas (DKIM de domínio próprio por remetente); as falhas restantes são só tráfego desconhecido/falsificado
3. Rampa de quarantine	`p=quarantine`	10 → 25 → 50 → 100	A fatia amostrada vai para as pastas de spam; a fatia fora da amostra é tratada como p=none (entregue)	1–2 semanas em pct=100 com zero correio legítimo em quarentena
4. Reject	`p=reject`	100	Devolvido no momento SMTP; o remetente recebe uma devolução, o destinatário não vê nada	Contínuo — mantenha o `rua` ligado para sempre para apanhar remetentes novos

Dados a 2026-06-29; comportamento da política segundo o RFC 7489.

A etapa 3 é onde os domínios empancam ou entram em pânico. Ir para a pasta de spam é recuperável — os utilizadores encontram o correio, você afrouxa o pct, corrige a origem. A rejeição não é recuperável, e é por isso que o quarantine em pct=100 a correr limpo é o bilhete de entrada para a etapa 4.

Como se executa a implantação, passo a passo?

Execute a verificação gratuita em defaults.exposed antes de tocar no DNS. Confirma a sua política atual e se o SPF e o DKIM estão montados por baixo — as duas pernas em que a aplicação assenta.
Ligue a monitorização se ainda não o fez. Publicar p=none com rua= é o passo de cinco minutos em “Política DMARC não ativada”. Recolha 2–4 semanas de relatórios — o suficiente para apanhar remetentes mensais como remessas de faturação.
Inventarie todas as origens nos relatórios. Classifique os remetentes em seus, dos seus fornecedores, e desconhecidos. Os relatórios em bruto chegam como XML — uma ferramenta de processamento de relatórios (ou o painel do seu fornecedor) transforma-os num inventário de remetentes legível.
Faça cada origem legítima passar alinhada. Ative o DKIM de domínio próprio de cada fornecedor (normalmente dois registos CNAME no painel deles) para que as assinaturas transportem o seu domínio, não o deles. Prefira o DKIM para o alinhamento: sobrevive ao reencaminhamento, o SPF não.
Espere por uma quinzena limpa. Saia da etapa 2 só quando as falhas reportadas forem exclusivamente tráfego que não reconhece — a falsificação que quer bloquear.
Passe a p=quarantine; pct=10 — edite o registo TXT _dmarc existente (exemplo trabalhado: configuração de DMARC na IONOS), e cuidado com a sintaxe: uma gralha na tag de política pode anular o registo por completo. Suba o pct para 25, 50, 100 ao longo de 2–4 semanas, acompanhando relatórios e tickets de suporte. Alguma coisa legítima no spam: recue o pct, corrija a origem, retome.
Passe a p=reject depois de 1–2 semanas limpas em pct=100. Mantenha o rua= ligado permanentemente — cada ferramenta nova que a sua empresa adota é um futuro remetente a falhar.

O que faz realmente o pct? A subtileza do RFC 7489

O pct pede aos recetores que apliquem a sua política a essa percentagem do correio que falha. A subtileza, do RFC 7489 §6.6.4: o correio que fica fora da amostra não recua para “entregar normalmente” — recebe a política imediatamente menos severa. Sob p=quarantine; pct=25, os outros 75% são tratados como p=none e entregues. Mas sob p=reject; pct=50, os outros 50% são postos em quarentena, não entregues. Não existe reject suave: no momento em que o seu registo diz reject, cada mensagem que falha vai no mínimo para a pasta de spam nos recetores que honram a política.

Usado deliberadamente, isso é uma funcionalidade — p=reject; pct=1 comporta-se como “quarentena para quase tudo, rejeição a conta-gotas”, uma rampa final legítima. Duas cautelas: os recetores não implementam todos a amostragem de forma idêntica, portanto trate o pct como um botão aproximado; e remova a tag (ou defina pct=100) quando a etapa 4 estabilizar, para que o seu registo diga o que quer dizer.

E os subdomínios — a tag sp=?

Por omissão, os subdomínios herdam a política do domínio organizacional: p=reject em yourdomain.com cobre também mail.yourdomain.com. A tag sp= deixa-os divergir, em direções úteis e perigosas. Útil: p=quarantine; sp=reject tranca os subdomínios de que nunca envia enquanto o apex ainda está a meio da rampa — os falsificadores visam deliberadamente subdomínios de domínios monitorizados. Perigoso: um sp=none esquecido isenta silenciosamente todos os subdomínios da política de reject que levou seis semanas a conquistar. Verifique-o na etapa 4; se um subdomínio precisar genuinamente de uma política mais frouxa, publique um registo _dmarc nesse subdomínio em vez de os afrouxar a todos.

A NIS2 significa que as empresas da UE têm de fazer isto?

O DMARC funciona de forma idêntica em todo o lado — nada neste runbook muda numa fronteira da UE. O que muda é a pressão de conformidade. O artigo 21.º, n.º 2, alínea j), da NIS2 exige que as entidades abrangidas protejam as suas comunicações, e o Regulamento de Execução (UE) 2024/2690 da Comissão detalha os requisitos técnicos para as entidades de infraestrutura digital que cobre — o seu anexo (ponto 6.7.2(k)) exige um plano de implementação para a adoção de normas modernas de segurança de email acordadas internacionalmente, e o ponto 6.7.2(l) exige boas práticas de segurança de DNS. Uma política DMARC aplicada, com SPF e DKIM por baixo, é o controlo auditável reconhecido contra a falsificação; p=none é demonstravelmente monitorizar, não proteger. Se os seus clientes estão abrangidos, os questionários de fornecedores deles perguntam cada vez mais exatamente isto.

Perguntas frequentes

Quanto tempo demora a implantação inteira? Seis a dez semanas é o típico: 2–4 semanas de monitorização, 1–3 semanas a corrigir origens, 2–4 semanas a subir o quarantine, depois reject. É tempo de calendário, não esforço — sobretudo à espera de que os relatórios confirmem cada alteração. Os 89,41% de 261.086.232 domínios classificados sem política aplicada (dados a 2026-06-29) na sua maioria não estão a meio da implantação; nunca puseram o relógio a contar.

Posso saltar o quarantine e usar p=reject com um pct baixo? Pode — segundo o RFC 7489 §6.6.4, p=reject; pct=10 significa 10% rejeitado e 90% em quarentena, aproximadamente o fim da etapa 3. Mas p=quarantine primeiro é mais fácil de raciocinar, e os recetores variam na fidelidade da amostragem. De qualquer forma, as etapas 1–2 são inegociáveis: nenhum sabor de aplicação é seguro enquanto remetentes legítimos ainda falharem.

E o correio que não posso corrigir — reencaminhadores e listas de correio? O reencaminhamento parte o SPF por conceção, e algumas listas de correio reescrevem conteúdo, partindo também o DKIM. O DKIM alinhado sobrevive ao reencaminhamento vulgar, o que resolve a maior parte; o pequeno resíduo é a razão de existir a etapa de quarantine — o correio na pasta de spam é recuperável enquanto avalia. Detalhes em email reencaminhado falha o SPF.

Parar em p=quarantine chega? É a maior parte do valor, e muito melhor do que os 37.312.637 domínios estacionados em p=none (de 261.086.232 classificados, dados a 2026-06-29) — mas o correio falsificado ainda chega às pastas de spam, de onde as pessoas o pescam. O reject é o ponto final: só 10,59% dos domínios classificados aplicam sequer, e terminar é o que os verificadores, as seguradoras e os questionários creditam.

Envie o relatório ao proprietário

Se está a executar esta implantação para um cliente ou empregador, a meta é mostrável. Volte a executar a verificação gratuita depois de p=reject resolver e reencaminhe o relatório classificado: o domínio a passar para uma política aplicada, com carimbo de data e em linguagem simples. Essa única página responde à linha de segurança de email das renovações de seguro cibernético e dos questionários de fornecedores movidos pela NIS2 melhor do que uma captura de ecrã de um painel de DNS — e torna visíveis seis semanas de trabalho cuidadoso e invisível à pessoa que o paga.

Verifique a sua política DMARC gratuitamente

Veja qual é atualmente a sua política — e se o SPF e o DKIM aguentam a aplicação — em privado e apenas para o proprietário.

Verifique o seu domínio → · Corrigir o DMARC → · “Política DMARC não ativada” — o primeiro passo honesto → · Apenas dados agregados. Dados armazenados e processados na UE.