O DMARC conquistou seu lugar como pedra angular da autenticação de e-mail em nível de domínio. Configure sua política como p=reject, alinhe corretamente seus registros SPF e DKIM, e a grande maioria das tentativas de falsificação externa que abusam do nome do seu domínio será bloqueada antes de chegar à caixa de entrada de qualquer destinatário. Essa proteção é real, mensurável e vale a pena ter.
Mas o DMARC foi projetado para responder a uma pergunta específica: esta mensagem está autorizada a usar este domínio? Ele nunca foi projetado para protegê-lo de atacantes que encontrem uma forma de entrar na sua própria infraestrutura de envio de e-mail. Uma vulnerabilidade na biblioteca SMTP do Netty – divulgada no final de 2025 e ainda presente em muitas aplicações Java rodando sem patch em produção – torna essa distinção criticamente clara.
CVE-2025-59419: Injeção de Comandos SMTP no Netty
O CVE-2025-59419 (GitHub Advisory GHSA-jq43-27x9-3v86) afeta a biblioteca netty-codec-smtp do Netty e tem pontuação CVSS de 7.7, classificada como Alta. O Netty é um framework de rede assíncrono e orientado a eventos que sustenta um número enorme de aplicações empresariais Java, microsserviços, gateways de API e cargas de trabalho nativas em nuvem. Se sua organização executa Java em escala, algo na sua stack quase certamente depende do Netty.
A vulnerabilidade é uma injeção CRLF clássica. A classe DefaultSmtpRequest não saneia os caracteres de retorno de carro (\r) e avanço de linha (\n) em parâmetros fornecidos pelo usuário – endereços de destinatários, nomes de host e valores semelhantes. Um atacante que controle qualquer uma dessas entradas (o envio de um formulário de contato, um payload de API, um endereço de e-mail fornecido pelo usuário em um fluxo transacional) pode incorporar uma sequência CRLF que rompe o comando SMTP atual e injeta novos comandos arbitrários no fluxo de e-mail de saída.
O impacto, conforme descrito no aviso de segurança publicado pelos mantenedores do Netty, é a falsificação de e-mail em escala: atacantes podem falsificar e-mails de alvos de alto valor como executivos corporativos ou funcionários do governo e enviá-los a jornalistas, instituições financeiras ou ao público em geral. O tráfego injetado se origina do seu próprio servidor, que é o detalhe que torna essa categoria de vulnerabilidade especialmente perigosa.
Patches estão disponíveis: Netty 4.2.7.Final e 4.1.128.Final contêm a correção. Qualquer aplicação executando uma versão anterior de netty-codec-smtp deve ser atualizada sem demora. Execute uma auditoria completa de dependências que cubra dependências transitivas, pois o Netty é frequentemente incluído por outras bibliotecas em vez de declarado diretamente na lista de dependências do próprio projeto.
Por Que o DMARC Não Impede Isso
Entender a lacuna exige entender o que o DMARC realmente verifica.
O SPF verifica se o endereço IP que envia a mensagem está listado como remetente autorizado para o domínio no endereço de envelope MAIL FROM. O DKIM verifica uma assinatura criptográfica aplicada aos cabeçalhos e ao corpo da mensagem. O DMARC vincula ambos os mecanismos ao cabeçalho From: visível e permite que proprietários de domínio especifiquem o que deve acontecer quando nenhuma verificação passa.
Quando um atacante explora o CVE-2025-59419, os comandos SMTP injetados trafegam pelo seu próprio servidor. O IP do seu servidor está na sua lista de permissões SPF por definição – é sua infraestrutura de envio autorizada. Se sua aplicação assina o e-mail de saída com DKIM, a assinatura pode ocorrer em uma camada acima do ponto de injeção. A mensagem chega ao seu destino parecendo exatamente com qualquer outra mensagem que seu servidor envia, porque em todo sentido relevante, ela veio do seu servidor.
Isso não é uma falha no DMARC. É o DMARC funcionando exatamente como foi projetado, sob a suposição de que sua infraestrutura de envio autorizada não foi comprometida no nível de protocolo. A suposição falha quando sua biblioteca de e-mail tem uma vulnerabilidade de injeção CRLF sem patch que permite que entradas fornecidas pelo atacante escapem do contexto de parâmetro e se tornem comandos SMTP brutos.
O DMARC fecha a porta contra a falsificação externa. Essa categoria de ataque não entra por essa porta.
Um Padrão em Todo o Ecossistema
O CVE-2025-59419 não é um incidente isolado. A injeção de comandos SMTP por saneamento CRLF insuficiente apareceu em múltiplas bibliotecas e implementações de servidor ao longo dos anos. O padrão é consistente: o código de envio SMTP tende a ser tratado como infraestrutura de plomeria em vez de um limite sensível à segurança, e os dados fornecidos pelo usuário chegam aos manipuladores de protocolo SMTP sem validação suficiente.
Em 2026, uma falha semelhante surgiu no namespace System.Net.Mail da Microsoft (CVE-2026-32178). A complicação no caso do .NET é significativa: o .NET 6 chegou ao fim da vida útil sem receber um patch, deixando uma grande base instalada de aplicações permanentemente sem uma correção fornecida pelo fornecedor, a menos que migrem para um runtime com suporte.
A recorrência dessa classe de vulnerabilidade nos principais ecossistemas transmite uma mensagem importante para organizações conscientes da segurança: onde quer que o código da aplicação aceite entrada externa e a incorpore em parâmetros de e-mail de saída, esse limite merece o mesmo escrutínio que qualquer outro ponto de injeção sensível à segurança.
O Que Fazer
A resposta exige atenção em múltiplos níveis:
Atualize o Netty imediatamente. Qualquer componente usando netty-codec-smtp abaixo da versão 4.2.7.Final ou 4.1.128.Final é vulnerável. A varredura de dependências deve cobrir o grafo transitivo completo, não apenas declarações de primeiro nível.
Valide todas as entradas destinadas ao SMTP. Em qualquer lugar onde sua aplicação aceite dados fornecidos pelo usuário e os inclua em parâmetros de e-mail de saída, valide e saneie essa entrada antes que ela chegue à camada SMTP. Remova ou rejeite os caracteres \r e \n de endereços, nomes de exibição e qualquer outro campo que possa ser refletido em comandos ou cabeçalhos em nível de protocolo.
Mantenha o DMARC em aplicação. p=reject é sua rede de segurança contra falsificação externa. Ele não protege contra infraestrutura de envio comprometida, mas elimina a superfície de ataque externa pela qual o DMARC é responsável. Não reduza sua política em resposta a preocupações de entregabilidade sem entender qual proteção você está abrindo mão.
Monitore seus relatórios agregados de DMARC. Os relatórios RUA mostram resultados de autenticação para todos os e-mails enviados sob seu domínio em todas as fontes. Picos de volume inesperados ou fontes de envio desconhecidas que aparecem nesses relatórios podem indicar que algo na sua infraestrutura está se comportando de maneiras que você não autorizou, mesmo quando os resultados de autenticação estão passando.
Inclua a infraestrutura de e-mail no seu perímetro de segurança. Varredura de dependências, análise de composição de software e frameworks de validação de entrada devem cobrir os caminhos de código que interagem com bibliotecas SMTP, não apenas o nível web voltado ao usuário. Um formulário de contato que alimenta diretamente um mailer baseado em Netty sem saneamento de entrada é um possível ponto de entrada para injeção SMTP.
A Realidade da Defesa em Profundidade
O panorama de ameaças de e-mail em 2026 apresenta às organizações ataques que operam em múltiplas camadas simultaneamente: falsificação de domínio de fora, comprometimento de infraestrutura de dentro, roubo de credenciais na camada de aplicação e engenharia social na camada humana. Nenhum controle único aborda todos eles.
O DMARC em p=reject é um controle necessário para toda organização que possui um domínio. Ele elimina uma categoria bem definida de ataques. Mas opera com a suposição explícita de que a infraestrutura autorizada nos seus registros DNS está sob seu controle e não foi comprometida. O CVE-2025-59419 mostra o que acontece quando essa suposição é violada no nível de biblioteca.
Software com patches aplicados é o que faz essa suposição do DMARC ser verdadeira na prática. Nenhum substitui o outro. Ambos são necessários para uma postura de segurança de e-mail que realmente se sustente.
Manter sua aplicação de DMARC ativa enquanto acompanha o que envia a partir do seu domínio é exatamente para o que o Excello Mail foi construído. Cadastre-se gratuitamente no Excello Mail e tenha visibilidade contínua da saúde da sua autenticação, fontes de envio e padrões de volume em cada fluxo de e-mail sob seu domínio.