Como Ler a Política DMARC de uma Empresa em Dez Segundos (E o Que Ela Não Lhe Diz)

Uma consulta DNS lhe diz o que uma empresa pediu aos servidores de correio do mundo para fazer com e-mails falsificados enviados em seu nome. O registo é público, e o comando é uma linha: dig +short TXT _dmarc.example.com. O que volta é uma cadeia curta de configurações, e dentro dela há uma instrução — p=none, p=quarantine ou p=reject — que expressa a preferência do proprietário do domínio quando uma mensagem que usa esse domínio falha na autenticação.

A especificação atual, RFC 9989, publicada em maio de 2026 como um documento da IETF Standards Track, substituiu a antiga RFC 7489. Define os três valores de forma quase lacónica:

• p=none — "O Proprietário do Domínio não expressa qualquer preferência."
• p=quarantine — "O Proprietário do Domínio considera tal correio suspeito. É possível que o correio seja válido, embora a falha crie uma preocupação significativa."
• p=reject — "O Proprietário do Domínio considera todas essas falhas como uma indicação clara de que o uso do nome de domínio não é válido."

Releia essas palavras, porque são mais fracas do que a maioria das explicações do DMARC admite. Uma política é uma preferência, publicada pelo remetente para que os receptores considerem. Não é uma instrução que o receptor é obrigado a cumprir. RFC 9989 diz isso numa frase: "O tratamento final de qualquer mensagem é sempre uma questão de política local e fica a critério do Receptor de Correio." A mesma secção acrescenta ambas as metades da consequência — receptores "PODEM optar por rejeitar ou colocar em quarentena uma mensagem mesmo que passe na validação DMARC," e "NÃO DEVEM rejeitar mensagens apenas por causa de uma política publicada de 'rejeição'," precisamente para que o correio legítimo enviado de formas que DMARC não consegue descrever, e listas de distribuição, não sejam destruídos no processo.

Então o que p=none realmente confessa? Menos do que é geralmente acusado. Nos termos da especificação, é Modo de Monitorização: o proprietário do domínio está a recolher relatórios agregados e "não expressa qualquer preferência de tratamento para mensagens que falham na validação DMARC," enquanto um receptor que implementa DMARC "ainda pode" validar o uso do domínio. O que não faz é desativar nada no lado do receptor. A filtragem de spam do seu fornecedor, pontuação de reputação, verificações de URL e análise de anexos são máquinas separadas que funcionam independentemente do que o remetente publicou. Uma mensagem falsificada que chega a um domínio p=none não é promovida para sua caixa de entrada pelo registo; é simplesmente entregue ao receptor sem uma preferência declarada, e o receptor decide.

A outra metade do mal-entendido funciona de forma contrária. DMARC não lê a parte perigosa de um e-mail de phishing. Sua própria especificação lista o que está deliberadamente fora do escopo, e "análise de conteúdo" está nessa lista, nessas palavras. Também afirma que DMARC "não aborda o uso de nomes de domínio visualmente semelhantes ou abuso do nome de exibição legível para humanos RFC5322.From" — os dois truques que carregam a maioria do correio de falsificação de marca. E sobre o valor de um resultado favorável: "uma aprovação DMARC por si só não garante que a entrega à caixa de entrada do destinatário seria segura ou desejável." Uma mensagem devidamente autenticada de um domínio descartável passa no DMARC limpa. DMARC responde quem foi autorizado a usar o domínio no cabeçalho From:. Nada mais.

É aqui que as regras de remetente em massa de 2024 são rotineiramente mal reportadas, incluindo na primeira versão deste artigo. As diretrizes de remetente do Google exigem que remetentes de 5.000 ou mais mensagens por dia para contas do Gmail "Configure a autenticação de e-mail DMARC para seu domínio de envio," e depois dizem, no mesmo fôlego: "Sua política de execução DMARC pode ser definida como none." O próprio Sender Hub do Yahoo, que deve ser lido separadamente em vez de se assumir que copia o Google, afirma o requisito como "Publique uma política DMARC válida com pelo menos p=none - DMARC deve passar," e não publica qualquer limiar de volume numérico. Ambos os conjuntos de requisitos entraram em vigor a partir de fevereiro de 2024. Nenhum força ninguém para longe de p=none. O que ambos realmente forçam é autenticação que se alinhe: Google exige que "o domínio no cabeçalho From: do remetente deve estar alinhado com o domínio SPF ou o domínio DKIM," e Yahoo diz que o alinhamento relaxado é aceitável. Alinhamento, não severidade, é o pré-requisito.

O que deixa a verdadeira razão pela qual domínios ficam em modo de monitorização, e é operacional em vez de covarde. Mudar para quarantine ou reject significa primeiro encontrar cada serviço que envia correio em seu nome — folha de pagamento, emissão de bilhetes, marketing, uma mesa de apoio que ninguém documentou — e autenticar cada um para que se alinhe. O próprio padrão reconhece os perigos que tornam isso lento: remetentes terceirizados não são introduzidos nem excluídos por DMARC, encaminhamento e listas de distribuição podem quebrar o alinhamento sem culpa do remetente, e a especificação aponta receptores para RFC 7960 exatamente para esses modos de falha. Uma organização que publica p=none e lê seus relatórios está fazendo o trabalho na ordem que a especificação descreve. Uma que publica p=none e ignora os relatórios não está. De fora, o registo sozinho não pode lhe dizer em qual das duas você está olhando.

Você não precisa de um terminal para procurar. Ferramentas de consulta gratuitas — verificador de domínio do dmarcian, verificação DMARC do MXToolbox — obtêm o registo e imprimem a política para você. Faça isso para seu banco, seu fornecedor de folha de pagamento, a companhia aérea que você voa. Apenas leia a resposta pelo que é: uma declaração de intenção pelo proprietário do domínio, uma entrada entre muitas numa decisão que seu fornecedor de correio faz por conta própria, sobre um tipo específico de falsificação. É uma coisa genuinamente útil para poder ler em dez segundos. Não é um veredicto sobre se a próxima mensagem que afirma ser dessa marca é segura.

Correção, 20 de outubro de 2026. Uma versão anterior deste artigo descrevia p=none como entregando falsificações à caixa de entrada e p=reject como a única configuração que bloqueia uma mensagem falsificada, dizia que as regras de remetente em massa de 2024 do Google e Yahoo forçavam remetentes para longe de p=none, e citava um número de aproximadamente um em três domínios em execução. As descrições de política foram corrigidas em relação a RFC 9989; Google e Yahoo na verdade aceitam p=none, citado acima de sua própria documentação; e a figura de execução foi removida porque o relatório subjacente não publica sua amostra ou denominador. O artigo agora também afirma o que DMARC não examina.

@@END@@