Por quase uma década, o argumento a favor do DMARC repousou sobre um único pilar: era a coisa certa a fazer. Equipes de segurança apontavam para estatísticas de phishing. Consultores de entregabilidade alertavam sobre danos à reputação. Fornecedores criavam painéis para tornar o caminho do p=none ao p=reject mais gerenciável.
Nada disso moveu o ponteiro com rapidez suficiente.
O que está movendo o ponteiro em 2026 é algo a que as organizações respondem de forma muito mais confiável do que orientações de boas práticas: a ameaça de multas. O DMARC cruzou de recomendação para regulação, e os frameworks que agora o exigem carregam consequências financeiras reais.
Se sua organização lida com dados de cartões de pagamento, opera infraestrutura crítica na União Europeia ou está no escopo do Regulamento de Resiliência Operacional Digital, você não está mais sendo convidado a implementar o DMARC. Você está sendo obrigado a fazê-lo.
PCI DSS v4.0: O Mandato Mais Claro Até Agora
O Padrão de Segurança de Dados da Indústria de Cartões de Pagamento versão 4.0 tornou-se a única versão em vigor em 31 de março de 2024. O Requisito 5.4.1 do PCI DSS v4.0 introduz uma obrigação explícita para que as organizações usem controles técnicos antiphishing para todo o tráfego de e-mail. A orientação complementar do PCI Security Standards Council deixa a expectativa concreta: DMARC, juntamente com SPF e DKIM, é o mecanismo técnico para satisfazer esse requisito.
O Requisito 10.4.1.1 vai além. Exige que o e-mail enviado pelo domínio de uma organização seja autenticado de forma verificável pelos sistemas receptores. Um registro DMARC em p=quarantine ou p=reject, combinado com autenticação SPF e DKIM alinhada, é o mecanismo que satisfaz essa cláusula.
O cálculo de conformidade é direto. O não cumprimento do PCI DSS pode gerar multas das bandeiras de cartões e bancos adquirentes que variam de US$ 5.000 a US$ 100.000 por mês por violação. O p=none que satisfaz os requisitos de remetentes em massa do Gmail e do Outlook não satisfaz o PCI DSS. A política em nível de aplicação é o requisito.
NIS2: A União Europeia Define o Padrão para Infraestrutura Crítica
A Diretiva de Segurança de Redes e Informação 2, que os estados membros da UE deviam transpor para o direito nacional até outubro de 2024, estabelece requisitos de cibersegurança para operadores de serviços essenciais e entidades importantes em dezesseis setores: energia, transporte, bancos, infraestrutura de mercados financeiros, saúde, água potável, tratamento de esgoto, infraestrutura digital, gestão de serviços de TIC, administração pública, espaço, serviços postais, gestão de resíduos, produtos químicos, alimentos e manufatura.
A NIS2 não menciona o DMARC em seu texto. O que ela faz é exigir que as entidades cobertas implementem “medidas técnicas e organizacionais adequadas e proporcionais” para gerir os riscos de cibersegurança. Os reguladores nacionais que implementam a NIS2 têm sido explícitos sobre o que essas medidas incluem. A Diretiva Técnica BSI TR-03108 do Escritório Federal Alemão para a Segurança da Informação especifica DMARC em nível de aplicação como um controle exigido para operadores de infraestrutura de e-mail.
O framework de penalidades da NIS2 está à altura da ambição da diretiva. As entidades essenciais enfrentam multas de até 10 milhões de euros ou 2% do volume de negócios anual global, o que for maior. As entidades importantes enfrentam multas de até 7 milhões de euros ou 1,4% do volume de negócios anual global. Essas são consequências em escala similar ao RGPD por não conformidade em cibersegurança.
DORA: Entidades Financeiras sob o Microscópio
O Regulamento de Resiliência Operacional Digital, que se tornou diretamente aplicável em todos os estados membros da UE em 17 de janeiro de 2025, aplica-se a entidades financeiras: bancos, empresas de investimento, seguradoras, instituições de pagamento, instituições de moeda eletrônica, prestadores de serviços de criptoativos e outros participantes do setor financeiro.
O artigo 9.º da DORA exige que as entidades financeiras implementem políticas e procedimentos para proteger seus sistemas de TIC e dados, incluindo controles que abordem a segurança da informação na camada de comunicação. As normas técnicas regulatórias complementares publicadas pelas Autoridades Europeias de Supervisão identificam especificamente os protocolos de autenticação de e-mail como componentes dos frameworks de segurança de TIC exigidos.
A implicação prática para as entidades financeiras no âmbito da DORA: uma política DMARC em p=none é uma lacuna documentada na gestão de riscos de TIC que as autoridades supervisoras podem citar como violação da DORA durante uma inspeção. As penalidades podem chegar a 2% do volume de negócios anual global total para as entidades financeiras.
Por Que Países com Mandatos Nacionais de DMARC Registram Taxas de Phishing Dramaticamente Menores
O Centro Nacional de Cibersegurança do Reino Unido exigiu DMARC em p=reject para todos os domínios do governo central em 2021. Os resultados são mensuráveis: países com mandatos formais de DMARC para domínios governamentais viram as taxas de sucesso de phishing direcionado a domínios governamentais caírem de 69% para 14%, em comparação com uma taxa de vulnerabilidade de 97% em países sem mandatos.
Esse dado é significativo para os responsáveis por conformidade no setor privado. A eficácia do DMARC em nível de aplicação não é teórica. Países e setores que o tornaram obrigatório demonstraram a redução na superfície de ataque que ele proporciona. Os reguladores que escrevem requisitos de cibersegurança em 2026 não estão especulando sobre se o DMARC funciona. Eles estão respondendo a evidências de que sim.
A Lacuna de Conformidade que Agora É uma Responsabilidade
O relatório de 2026 da EasyDMARC constatou que, dos 937.931 domínios com registros DMARC, apenas 411.935 estão em quarantine ou reject. Menos de um em cada quatro domínios que se deram ao trabalho de publicar um registro DMARC chegaram de fato ao nível de política que os reguladores agora exigem. Para organizações no escopo do PCI DSS, NIS2 ou DORA, cada dia que o p=none permanece no DNS é um dia de não conformidade documentada.
O Que o DMARC em Nível de Aplicação Realmente Requer
Passar do p=none para o p=reject não é uma mudança de registro DNS. É um projeto de infraestrutura de e-mail. O caminho é metódico:
Coleta e análise de relatórios agregados. Os relatórios agregados de DMARC (RUA) contêm uma contabilização detalhada de cada servidor que enviou e-mail alegando ser do seu domínio durante o intervalo de relatório. Não é possível aplicar a política com segurança sem analisar várias semanas desses relatórios.
Descoberta de fontes e autenticação. Os relatórios vão revelar fontes de envio que você não sabia que existiam: uma plataforma de automação de marketing de um fornecedor anterior, uma integração SaaS que envia recibos transacionais pelo seu domínio, um escritório regional usando um relay de e-mail local. Toda fonte legítima deve ser autenticada antes da aplicação da política.
Aplicação em fases. A transição do p=none para p=quarantine e depois para p=reject deve ser feita em etapas, com monitoramento em cada passo para detectar qualquer fonte legítima que tenha passado despercebida na fase de descoberta.
A Documentação como Ativo de Conformidade
Um aspecto subestimado da conformidade com o DMARC sob frameworks regulatórios é a documentação. Os avaliadores do PCI DSS e os auditores supervisores da NIS2 não verificam simplesmente se existe um registro DMARC no nível de política correto. Eles avaliam se a organização possui um processo repetível e documentado para manter essa conformidade.
Isso significa:
- Registros da fase de monitoramento e da análise de relatórios agregados que precederam a aplicação
- Documentação de todas as fontes de envio autenticadas e do processo para adicionar novas
- Evidência de revisão periódica dos relatórios DMARC para detectar falhas de autenticação de fontes novas ou alteradas
- Uma política que governe como as alterações de configuração do DMARC são aprovadas e implementadas
Organizações que alcançam o p=reject mas não conseguem demonstrar o processo que as levou até lá e os controles que o mantêm estão apenas parcialmente em conformidade com os frameworks que agora exigem o DMARC. O registro no DNS é o resultado. O processo é o requisito.
A Intersecção com as Leis Globais de Marketing por E-mail
A pressão regulatória sobre a autenticação de e-mail chega junto com uma pressão separada e paralela sobre as práticas de marketing por e-mail. A aplicação da Lei de Spam da Austrália resultou em uma multa de A$702.900 contra a Lululemon em março de 2026. A CEMA do Estado de Washington desencadeou aproximadamente 115 ações coletivas visando linhas de assunto enganosas.
Esses são frameworks legais separados do PCI DSS, NIS2 e DORA, mas reforçam a mesma realidade organizacional: a infraestrutura de e-mail está sob escrutínio regulatório em múltiplos níveis simultaneamente. Organizações que tratam esses como fluxos de trabalho separados vão se encontrar gerenciando lacunas de conformidade separadas. Organizações que abordam o e-mail como uma superfície de conformidade integrada, onde DMARC, higiene de lista, mecanismos de cancelamento de inscrição e documentação operacional fazem parte do mesmo programa, são as que estão posicionadas para demonstrar conformidade em todo o espectro de frameworks aplicáveis.
Gerenciar a conformidade com o DMARC no escopo do PCI DSS, NIS2 e DORA não é um projeto pontual. O Excello Mail oferece à sua equipe monitoramento contínuo, análise de relatórios agregados e orientação de aplicação que se documenta automaticamente ao longo do processo. Comece seu teste gratuito em excello.email →