Verificador de DMARC:
a sua política bloqueia alguma coisa?
Introduza um domínio — o verificador analisa cada tag e avalia o que a sua política impõe, não apenas se existe um registro. A maioria dos domínios fica-se pelo p=none, que não bloqueia nada: só pede aos receptores que reportem o correio falsificado que entregaram na mesma.
Sintaxe perfeita, porta aberta
Um registro DMARC pode ser sintaticamente perfeito e operacionalmente inútil. Cada um destes quatro casos passa nos verificadores de existência e deixa, na prática, uma porta aberta.
p=none esquecido depois do faseamento
Definido como «monitoramento» durante o faseamento em 2023 — e continua em monitoramento. p=none diz aos receptores para não tomarem qualquer ação: o correio falsificado entra nas caixas de entrada em seu nome, enquanto o seu dashboard mostra DMARC ✓.
p=none · não bloqueia nadarua= num domínio não autorizado
O seu rua= aponta para um domínio de um fornecedor ou agência que nunca publicou o registro de autorização. Os receptores procuram-no — e descartam silenciosamente todos os relatórios. Sem devolução, sem erro, sem dados. Nunca.
RFC 7489 §7.1A brecha do pct=
p=reject; pct=50 — o regulador do faseamento ficou parado a meio do percurso. Metade do correio falsificado é rejeitado, a outra metade é entregue, à sorte, mensagem a mensagem. Um atacante não se importa de tentar outra vez.
pct=50 · metade aplicadosp=none nos seus subdomínios
Um sp=none explícito, esquecido do faseamento, significa que a sua raiz rejeita falsificações enquanto faturas.oseudominio.com as aceita. Os atacantes também leem o DNS.
sp=none · subdomínios desprotegidosreject, quarantine, none e as lacunas
A tag p= é uma instrução para todos os receptores de correio do planeta. Avaliamo-la como uma escada de maturidade, não como um simples passa/não passa.
«Correio que falha o alinhamento: recusar à porta.» Proteção total — o topo da escada. Só é tão forte quanto o SPF e o DKIM que a alimentam, e só está completa em pct=100.
«Tratar as falhas com desconfiança» — na prática, a pasta de spam. Proteção parcial real, e o degrau intermediário correto, sobretudo com pct= em faseamento. Não é o topo.
Monitoramento: nada é bloqueado, mas os relatórios chegam, e fica sabendo quem envia em nome do domínio. É o correto para os primeiros 90 dias de qualquer faseamento de DMARC — e o estado permanente de demasiados domínios.
Nada é bloqueado e ninguém está vigiando. O registro existe só para satisfazer verificadores que testam apenas a existência. Conformidade de fachada no seu estado mais puro.
Os receptores caem nas suas próprias heurísticas; o risco de falsificação do seu domínio depende de quem está do outro lado. É cada vez mais também um problema de entregabilidade: os grandes remetentes que enviam para o Gmail/Yahoo são obrigados a publicar DMARC.
Vários registros v=DMARC1 em _dmarc não se fundem — a detecção falha e os receptores tratam-no como se não publicasse nada. O mesmo acontece com uma lista de tags mal formada.
Para onde vão os seus relatórios DMARC
O envio de relatórios DMARC é um acordo entre três partes: o titular do domínio, os receptores, e quem lê os relatórios. Quando rua= aponta para um domínio diferente (o painel de um fornecedor, a caixa de entrada de uma agência), a RFC 7489 §7.1 exige que esse domínio dê autorização:
- Antes de enviar um relatório, o receptor consulta oseudominio._report._dmarc.dominiodeles à procura de um registro v=DMARC1.
- Sem registro → sem relatório. Silenciosamente. Não chega nenhuma devolução, nada registra o fato — os seus relatórios simplesmente nunca existiram.
- Os fornecedores a sério publicam um wildcard (*._report._dmarc.example.com) — um domínio de fornecedor mal escrito, uma conta expirada ou a caixa de entrada simples de uma agência não o terão.
- Resolvemos até 5 destinos rua=/ruf= por tag e corremos esta consulta para cada um — a maioria dos verificadores nunca o faz.
A escada de maturidade
o que cada degrau lhe dáO que o dig revela
O registro está a um dig de distância, e a verificação de autorização é só mais um DNS depois de saber que existe. Avaliar o que a política aplica exige mais do que uma linha de comando.
Perguntas frequentes sobre DMARC
Escreva o seu domínio acima. Vamos buscar o registro TXT a _dmarc.oseudominio, confirmamos que existe exatamente um v=DMARC1 (dois significa que os receptores não veem nenhum) e analisamos cada tag segundo a RFC 7489, com as predefinições explicitadas (p=, sp=, pct=, adkim=/aspf=, rua=/ruf=, fo=). Depois avaliamos o nível de aplicação e verificamos se os destinos de relatórios que avaliamos conseguem mesmo receber relatórios. Grátis, sem registro.
Diz a todos os receptores: «quando o correio falha o DMARC, não tome qualquer ação — entregue-o, mas envie-me um relatório.» Nada é colocado em quarentena e nada é rejeitado. Uma fatura falsificada chega à caixa de entrada do seu cliente exatamente como se não existisse DMARC nenhum. O que o p=none lhe dá é visibilidade: os relatórios agregados identificam todos os servidores que enviam como se fossem o seu domínio, legítimos ou não. É por isso que é o primeiro degrau correto de um faseamento, e um péssimo lugar para ficar vivendo. Se o seu registro diz p=none há mais de 2 trimestres, não «está fazendo DMARC». Está vendo, em alta definição, outros fazendo-se passar por você.
Escada, não salto. Primeiro: p=none com rua= durante um trimestre. Leia os relatórios, identifique todos os remetentes legítimos (a ferramenta de faturamento que ninguém mencionou) e corrija o alinhamento SPF/DKIM deles. Depois: p=quarantine; pct=10, subindo o pct para 50 e depois 100 enquanto os relatórios se mantiverem limpos. Depois: p=reject. Se um subdomínio ficar atrasado (uma plataforma de newsletter no meio de uma migração), dê-lhe o seu próprio registro _dmarc.sub em vez de manter o domínio inteiro em none. Condicione cada passo aos dados dos relatórios — os relatórios são a rede de segurança que torna o rigor seguro.
rua= é o relatório agregado: resumos XML diários de cada receptor — que IPs enviaram em nome do domínio, quantos passaram ou falharam, sob que política. É este que interessa; é como se orienta pela escada. ruf= é o relatório forense: cópias de falhas por mensagem. A maioria dos grandes receptores, incluindo Gmail e Microsoft, já não os envia por razões de privacidade. Trate o ruf= como um bônus vindo de receptores menores, não como uma fonte de dados em que possa confiar. Ambos só aceitam URIs mailto:, e ambos ficam sujeitos à verificação de autorização entre domínios que esta ferramenta faz.
A causa clássica é exatamente a verificação que esta ferramenta existe para fazer: o seu rua= aponta para um domínio que não é o seu, e esse domínio nunca publicou o registro de autorização. A RFC 7489 §7.1 obriga os receptores a confirmar primeiro a autorização: consultam oseudominio._report._dmarc.dominiodedestino e esperam uma resposta v=DMARC1. Sem resposta → o relatório é descartado silenciosamente, sem devolução e sem erro que consiga ver. Acontece quando o domínio do fornecedor está mal escrito, ou quando muda de fornecedor mas não o registro. Também acontece quando os relatórios vão para a caixa de correio de uma agência nunca preparada para relatórios entre domínios. Corremos a consulta para cada destino que avaliamos e mostramos-lhe exatamente o registro que falta.
O alinhamento é o que o DMARC usa para ligar o SPF/DKIM à linha From: que o leitor vê. O modo relaxado (a predefinição, r) aceita uma correspondência ao nível do domínio organizacional — correio assinado por news.oseudominio.com alinha com oseudominio.com. O estrito (s) exige uma correspondência exata. O relaxado é a escolha certa para quase todos; o estrito fecha uma brecha estreita (um subdomínio comprometido ou delegado a garantir pela sua raiz) ao preço de quebrar todos os remetentes de subdomínios de que se esqueceu. Só aperte para estrito depois de os relatórios mostrarem um trimestre de alinhamento limpo e de domínio exato.
Trava a falsificação de domínio exato nos receptores que cooperam — que é a maior parte do volume de caixas de correio da internet. Restam três brechas. O DMARC só avalia o alinhamento, por isso é exatamente tão forte quanto o SPF e o DKIM por baixo dele. Um SPF em permerror ou uma chave DKIM revogada enfraquecem o reject sem se notar. Um pct<100 ou um sp= mais fraco deixam brechas deliberadas. E domínios parecidos com o seu (asuaempresa-faturacao.com) ficam fora do alcance, porque nenhum registro DMARC seu pode falar por um domínio que não possui. Verifique a pilha toda: as nossas ferramentas de SPF e DKIM cobrem a primeira brecha.
Continuar explorando
As ferramentas grátis são só o começo.
O Uptimia cuida dos seus sites.
Uptime, SSL, expiração do domínio, velocidade de página, transações — monitoramento em 171+ locais em todo o mundo. Grátis por 30 dias.