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 registo. A maioria dos domínios fica-se pelo p=none, que não bloqueia nada: só pede aos recetores que reportem o correio falsificado que entregaram na mesma.
Sintaxe perfeita, porta aberta
Um registo 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 «monitorização» durante o faseamento em 2023 — e continua em monitorização. p=none diz aos recetores para não tomarem qualquer ação: o correio falsificado entra nas caixas de entrada em seu nome, enquanto o seu painel 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 registo de autorização. Os recetores 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 recetores 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 intermédio correto, sobretudo com pct= em faseamento. Não é o topo.
Monitorização: nada é bloqueado, mas os relatórios chegam, e fica a saber 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á a vigiar. O registo existe só para satisfazer verificadores que testam apenas a existência. Conformidade de fachada no seu estado mais puro.
Os recetores 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 registos v=DMARC1 em _dmarc não se fundem — a deteção falha e os recetores 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 recetores, 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 recetor consulta oseudominio._report._dmarc.dominiodeles à procura de um registo v=DMARC1.
- Sem registo → sem relatório. Silenciosamente. Não chega nenhuma devolução, nada regista o facto — 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 caducada 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 registo 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 registo TXT a _dmarc.oseudominio, confirmamos que existe exatamente um v=DMARC1 (dois significa que os recetores 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 avaliámos conseguem mesmo receber relatórios. Grátis, sem registo.
Diz a todos os recetores: «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 sítio para ficar a viver. Se o seu registo diz p=none há mais de 2 trimestres, não «está a fazer DMARC». Está a ver, em alta definição, outros a fazerem-se passar por si.
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 faturação 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 a meio de uma migração), dê-lhe o seu próprio registo _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 recetor — 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 recetores, incluindo Gmail e Microsoft, já não os envia por razões de privacidade. Trate o ruf= como um bónus vindo de recetores mais pequenos, 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 registo de autorização. A RFC 7489 §7.1 obriga os recetores 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 registo. 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 registo 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 recetores 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 registo 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 a explorar
As ferramentas grátis são só o começo.
O Uptimia cuida dos seus sites.
Uptime, SSL, validade de domínio, velocidade de página, transações — monitorização em 171+ locais em todo o mundo. Grátis por 30 dias.