2026-07-24 · PESQUISA · A equipe da Offensive Technology

p=none é suficiente? Por que publicar DMARC não é o mesmo que aplicá-lo

DMARC p=none é suficiente? Não. O p=none não impede o spoofing. Ele apenas monitora. Se o seu domínio está em p=none, os destinatários enviam relatórios para você, mas ainda entregam e-mails forjados com o seu nome, portanto seu domínio ainda pode ser forjado. Resolvemos 300 dos principais domínios via DNS público e lemos seus registros de autenticação de e-mail para ver quão comum é esse erro. A publicação parece saudável: 84.7% publicam um registro DMARC. A aplicação é onde tudo falha. Apenas 67.3% realmente aplicam o DMARC com uma política de quarentena ou rejeição. Entre os 261 domínios que recebem e-mails, cerca de 30% não aplicam nada, porque estão em p=none, não publicam nenhuma tag de política útil ou não publicam DMARC de forma alguma. Se você herdou um registro DMARC e supôs que ele o protege, este é o gargalo em que você se encontra.

Publicar DMARC não é o mesmo que aplicá-lo

A autenticação de e-mail consiste em três registros que as pessoas tendem a tratar como uma única caixa de seleção. O SPF (RFC 7208) lista quais servidores podem enviar em nome de um domínio. O DKIM (RFC 6376) assina uma mensagem para que o destinatário possa verificar se ela não foi alterada. O DMARC (RFC 7489) vincula essas verificações ao endereço From visível e diz aos destinatários o que fazer quando elas falham.

Essa última cláusula é onde a publicação e a aplicação do DMARC se separam. Um registro pode existir e ainda assim instruir os destinatários a não fazerem nada. A política reside na tag p=, e possui três configurações. Isto é tudo sobre p=none vs reject:

• p=reject diz aos destinatários para recusarem e-mails que falhem. É isso que realmente impede que alguém forje seu domínio.
• p=quarantine diz aos destinatários para tratarem e-mails com falhas como suspeitos, geralmente direcionando-os para o spam. É uma forma de aplicação, embora mais fraca que o reject.
• p=none diz aos destinatários para enviarem relatórios e, de resto, entregarem e-mails com falhas normalmente. E-mails forjados ainda chegam. Isso é monitoramento, não defesa.

Portanto, a pergunta honesta não é "este domínio tem DMARC", mas sim "o DMARC deste domínio é aplicado". O que significa a aplicação do DMARC na prática? Significa que o destinatário é instruído a agir diante de uma falha em vez de apenas registrá-la. Em nossa amostra, os dois números divergem em quase dezoito pontos: 84.7% publicam um registro, 67.3% aplicam um. Essa lacuna de dezoito pontos representa domínios que fizeram o trabalho visível, editaram seu DNS, colocaram um registro em vigor e pararam um passo antes da parte que realmente bloqueia algo.

Os dados: publicado versus aplicado

Aqui está a amostra completa. Controles de publicação estão em alta, enquanto a aplicação e as camadas de transporte estão em baixa.

Agora a distribuição das políticas. Esta é a tabela que responde à pergunta diretamente: dos domínios que realmente recebem e-mails, quantos estão em p=none ou pior.

Leia as três últimas linhas juntas. Isso representa 29.9% dos domínios receptores de e-mail onde e-mails forjados levando seu nome não são interrompidos pelo DMARC. Estes são domínios que recebem e-mails ativamente, portanto não se trata de uma particularidade técnica sobre zonas estacionadas ou que não enviam e-mails. É a mesma brecha de personificação que descrevemos em nosso guia sobre o que atacantes podem ver sobre sua empresa, ainda aberta em quase um terço dos domínios de e-mail ativos próximos ao topo da web. Se você possui um registro DMARC mas ainda sofre spoofing, a linha p=none é quase certamente onde você está.

A lacuna de aplicação

Chamamos o espaço entre 84.7% publicados e 67.3% aplicados de lacuna de aplicação do DMARC, e este é o ponto central desta medição. Publicar um registro é barato e visível, por isso acontece. Transformar esse registro em algo que bloqueia e-mails exige que a organização conheça seus próprios remetentes bem o suficiente para rejeitar o restante sem interromper e-mails corporativos legítimos. É nesse segundo passo que os domínios estagnam, e essa estagnação é mensurável.

Pense a partir da perspectiva do atacante, porque é essa perspectiva que decide se um controle importa. Você deseja enviar um e-mail que pareça vir do próprio domínio do alvo, para a equipe financeira desse alvo ou para um de seus clientes, solicitando a transferência de um pagamento ou a redefinição de uma credencial. Você verifica o DNS do alvo primeiro, da mesma forma que fizemos. Se o domínio publica p=reject, seu e-mail forjado é recusado no lado receptor e nunca chega à caixa de entrada. Esse plano morreu. Se o domínio publica p=none, nada muda para você. O destinatário registra a falha em um relatório que vai para o proprietário do domínio, não para a sua vítima, e entrega sua mensagem da mesma forma. Então meu domínio pode sofrer spoofing em p=none? Sim, com a mesma facilidade de não ter DMARC de forma alguma.

O que torna nosso número digno de citação é a forma como o obtivemos. Esta é uma medição passiva independente, não telemetria de fornecedor. Não estamos relatando e-mails filtrados por nosso próprio produto, nem extrapolando a partir do fluxo de entrada de um único provedor. Lemos a política pública que todo receptor na internet lê, o próprio registro, para uma amostra fixa em uma data fixa. Esse é um ponto de vista diferente e mais neutro do que o de um fornecedor de segurança relatando sobre o tráfego que por acaso ele enxerga.

Como verificar seu próprio domínio

Você não precisa de uma ferramenta ou de um cadastro para isso. Leia seu próprio DNS público e observe uma tag. Qualquer pessoa pode executar essas consultas em qualquer domínio, porque uma consulta DNS é uma leitura passiva de registros que já são públicos.

• Verifique a política DMARC. Execute dig TXT _dmarc.yourdomain.com +short e leia a tag p=. p=reject ou p=quarantine significa que você está aplicando. p=none, ou nenhuma tag p=, ou nenhum registro, significa que você não está aplicando e seu domínio pode sofrer spoofing.
• Verifique o SPF. Execute dig TXT yourdomain.com +short e procure por um registro começando com v=spf1. A ausência de SPF enfraquece o alinhamento do qual o DMARC depende.
• Verifique as camadas de transporte e integridade. Execute dig DS yourdomain.com +short para DNSSEC e dig TXT _mta-sts.yourdomain.com +short para um anúncio de MTA-STS. Ambos geralmente estão ausentes, como mostram os dados acima.

Se a consulta DMARC retornar com p=none, você tem sua resposta: o registro está publicando, não aplicando, e você está apenas em modo de monitoramento.

Saindo de p=none para a aplicação

O caminho de none para reject é bem conhecido, e a verdade é que a edição do DNS é a parte fácil. O trabalho consiste em confirmar que você não vai interromper e-mails legítimos quando os destinatários começarem a agir diante de falhas. Veja como migrar o DMARC de none para reject sem cortar seus próprios remetentes:

• Permaneça em p=none apenas o tempo suficiente para fazer o inventário. Aponte a tag rua= para uma caixa de e-mail ou um analisador de relatórios e leia os relatórios agregados até conseguir mapear todas as fontes que enviam e-mails em nome do seu domínio, incluindo plataformas de marketing, sistemas de chamados e terceiros.
• Mude para p=quarantine, escalonando com pct se quiser ser cauteloso. A pct= O valor aplica a política a uma fração dos e-mails com falha para que você possa observar se remetentes legítimos falham no alinhamento antes de aplicá-la a tudo. Corrija qualquer remetente real que falhe no alinhamento de SPF ou DKIM antes de expandir.
• Mude para p=reject assim que os relatórios estiverem limpos. Quando nenhuma fonte legítima estiver falhando, reject é a configuração que interrompe a falsificação de forma definitiva. Este é o único estado em que a resposta para "p=none é suficiente" se torna irrelevante, porque você deixou o p=none para trás.

Aproveitando que você já está mexendo no DNS, anuncie o MTA-STS para que e-mails de entrada não possam ser silenciosamente rebaixados para texto puro, e assine sua zona com DNSSEC para que as consultas que buscam sua política não possam ser forjadas. A adoção do MTA-STS está em apenas 4.7% em nossa amostra, portanto implementá-lo coloca você à frente de quase todos. O DNSSEC também é pré-requisito para esquemas mais fortes como o DANE, e sua raridade em 20.0% limita até onde a segurança de e-mail pode ir para quatro em cada cinco desses domínios. O discernimento por trás da aplicação sem interrupções é o mesmo por trás de saber quais dos seus controles de emissão de certificados e superfícies expostas realmente importam e quais são apenas ruído.

O que isto não prova

Limites honestos, porque um número sem suas ressalvas é apenas marketing.

• A Majestic classifica por backlinks, não por tráfego. O Majestic Million ordena sites por sub-redes e links de referência, o que favorece domínios antigos e amplamente citados. Essa é uma população diferente de uma lista classificada por tráfego, portanto leia estes dados como um recorte honesto, não como a internet inteira.
• É uma amostra de 300 domínios. Toda porcentagem carrega erro de amostragem. Um dado como 67.3% aplicando significa 202 de 300 domínios, e outros 300 domínios alterariam isso em alguns pontos.
• É um retrato momentâneo. O DNS muda diariamente. Estes números descrevem 24 de julho de 2026, não uma tendência. Um domínio em p=none hoje pode estar no meio de uma implementação e aplicar a política no mês que vem.
• É uma visão exclusiva de DNS. Um p=reject publicado não é prova de que o SPF e o DKIM de um domínio estejam alinhados corretamente para seus remetentes reais. Lemos a política sobre a qual os destinatários agem, não o e-mail entregue. É uma declaração sobre a intenção publicada, não sobre uma implantação impecável.
• A aplicação é genérica. Contamos p=quarantine e p=reject como aplicando. Na prática, uma política de quarentena com um baixo pct ou um modo de alinhamento brando ainda deixa passar alguns e-mails forjados, de modo que o número de aplicação é, de certa forma, generoso.

Perguntas frequentes

O p=none é suficiente para impedir o spoofing de e-mail?

Não. p=none é apenas monitoramento. Os destinatários relatam falhas, mas entregam e-mails forjados normalmente, portanto e-mails usando seu domínio ainda chegam às caixas de entrada. É uma boa primeira etapa enquanto você faz o inventário dos remetentes, mas não bloqueia nada até que a política mude para quarantine ou reject.

Meu domínio ainda pode sofrer spoofing se eu tiver um registro DMARC?

Sim, se esse registro estiver em p=none. Ter um registro não é o mesmo que estar protegido. Apenas p=quarantine ou p=reject instrui os destinatários a agirem diante de e-mails que falhem na autenticação.

Qual é a diferença entre publicar e aplicar o DMARC?

Publicar significa que um registro _dmarc existe. Aplicar significa que sua política é p=quarantine ou p=reject. Um registro em p=none não bloqueia nada. Em nossa amostra de julho de 2026, 84.7% publicaram um registro, mas apenas 67.3% aplicaram um.

Qual porcentagem de domínios realmente aplica o DMARC?

Em nossa amostra de 300 domínios, 84.7% publicaram DMARC e 67.3% o aplicaram. Entre os 261 domínios receptores de e-mail, cerca de 30% não aplicam nada.

p=none é o mesmo que não ter DMARC?

Para impedir o spoofing, na prática, sim. Para um atacante, o resultado é idêntico: o e-mail forjado é entregue. A diferença é que o p=none gera relatórios que você pode usar para alcançar a aplicação.

Como migrar o DMARC de none para reject?

Leia seus relatórios agregados em p=none até que todos os remetentes legítimos estejam mapeados, mude para p=quarantine (opcionalmente escalonando com uma tag pct), corrija qualquer remetente real com falha de alinhamento e, em seguida, defina p=reject.

Por que ainda estou sofrendo spoofing mesmo com o DMARC configurado?

Quase sempre porque a política está em p=none, ou porque o SPF e o DKIM não estão alinhados para seus remetentes, de modo que uma política de aplicação não pode ser aprovada. Verifique a tag p= no seu registro _dmarc primeiro.

Leitura relacionada

• Quão expostos estão os domínios mais movimentados do mundo ao email-spoofing? A pergunta sobre presença na qual este artigo se baseia.
• Quantos dos principais domínios restrigem quem pode emitir seus certificados? O mesmo método de DNS passivo, aplicado a registros CAA.
• O que atacantes podem realmente ver sobre sua empresa?