6 min de leitura Por Excello Mail Team

GMX, WEB.DE e mail.com Começam a Rejeitar Falhas de DMARC no Nível SMTP, Enquanto Meio Milhão de Domínios Ainda Está com o Alarme Desligado

A 1&1 Mail & Media, empresa por trás do GMX, WEB.DE e mail.com, está implementando a aplicação total de DMARC p=reject no correio recebido de 42 milhões de caixas de entrada. Ao mesmo tempo, um novo relatório de adoção de DMARC mostra que mais de meio milhão de domínios que publicaram um registro DMARC ainda estão em p=none, a configuração que não faz nada para impedir a falsificação.

A equipe de postmaster da 1&1 Mail & Media, empresa por trás do GMX, WEB.DE e mail.com, informou neste trimestre na lista de e-mail mailop que está implementando a aplicação total de DMARC em sua infraestrutura de correio recebido, respeitando as políticas p=reject diretamente na transação SMTP em vez de tratá-las como mais um sinal entre outros. O correio de um domínio que publica p=reject e não passa no DMARC via SPF alinhado ou DKIM alinhado agora é rejeitado de forma direta, com o servidor remetente recebendo “554 Transaction failed Reject due to domain’s DMARC policy” antes mesmo de a mensagem chegar a uma caixa de entrada. GMX, WEB.DE e mail.com juntos atendem 42 milhões de usuários ativos e ocupam posição de liderança na Alemanha, Áustria e Suíça, então não se trata de um provedor de e-mail menor ajustando um detalhe qualquer. O benchmark de entrega Q1 2026 da Postmastery, construído sobre 15,5 bilhões de transações rastreadas, aponta essa mudança como um dos movimentos de entregabilidade mais importantes do ano. Na mesma janela, o relatório de adoção de DMARC 2026 da EasyDMARC constatou que 525.996 domínios, mais da metade de todos os domínios que já publicaram um registro DMARC, ainda estão estacionados em p=none. Esses dois fatos estão em lados opostos do mesmo problema, e nenhum deles faz sentido sem o outro.

O Que Realmente Mudou no GMX, WEB.DE e mail.com

O DMARC tecnicamente cobre o GMX e o WEB.DE desde 2021, quando o provedor disse pela primeira vez que respeitaria as políticas publicadas pelos domínios remetentes para ajudar a proteger os usuários contra endereços falsificados. O que muda agora é a profundidade da aplicação. Uma política p=reject publicada era algo que esses provedores podiam ponderar junto com outros sinais. Agora é uma instrução rígida: sem SPF alinhado, sem DKIM alinhado, não há entrega, decidido durante a própria conversa SMTP em vez de depois do fato. Para um remetente cuja autenticação já está correta, isso não muda nada. Para um remetente que publicou p=reject anos atrás como uma caixinha de conformidade e nunca verificou se cada fonte de envio legítima, uma plataforma de marketing, uma ferramenta de helpdesk, um relay interno, realmente está alinhada, este é o momento em que o correio mal configurado começa a ser rejeitado em uma das maiores bases de caixas de entrada da Europa de língua alemã.

A Outra Metade da História: Domínios Que Nunca Ativaram a Política

O relatório da EasyDMARC coloca o outro lado desse problema em números concretos. Dos domínios que já publicaram um registro DMARC, mais da metade está em p=none, a configuração de apenas monitoramento que gera relatórios agregados mas não toma nenhuma ação contra o correio falsificado. Esse número coincide quase exatamente com o cronograma dos requisitos de remetentes em massa do Google e do Yahoo de 2024, que exigiam DMARC em p=none como mínimo. Milhões de domínios cumpriram esse mínimo e pararam por aí. Entre as Fortune 500, 95% têm um registro DMARC válido e mais de 80% aplicam em quarantine ou reject; o relato é quase universal, com 97,9%. Entre as Inc. 5000, a adoção é um respeitável 76,2%, mas apenas 15,2% chegam a p=reject, e mais da metade permanece presa em p=none. O padrão se repete em todos os setores medidos: publicar um registro DMARC já é o mínimo esperado, mas a passagem de monitoramento para aplicação real é onde a grande maioria das organizações estaciona.

Por Que Isso Importa para o DMARC e a Entregabilidade

Esses dois desenvolvimentos descrevem a mesma lacuna a partir de direções opostas. O GMX, WEB.DE e mail.com aplicarem p=reject do lado do destinatário só protege os remetentes que já fizeram o trabalho de levar sua própria política a p=reject e manter todas as fontes autorizadas alinhadas. Para os 525.996 domínios que ainda estão em p=none, essa mudança de aplicação não traz nenhuma proteção adicional, porque não existe, para começar, uma política de rejeição que os servidores do GMX possam respeitar. Um e-mail falsificado se passando por um desses domínios ainda chega a uma caixa de entrada do GMX, WEB.DE ou mail.com exatamente como sempre chegou. Enquanto isso, para o grupo menor de domínios que publicaram p=reject sem confirmar que todas as fontes de envio permanecem alinhadas, esse rollout de aplicação é o momento em que anos de configuração não verificada se transformam em correio rejeitado de verdade, faturas perdidas e chamados de suporte. O valor do DMARC nunca esteve no fato de o registro existir. Sempre esteve na lacuna entre “publicado” e “aplicado e correto”, e nesta semana dois dados independentes caíram exatamente nessa lacuna, vindos de ângulos diferentes.

O Que os Remetentes Devem Fazer Agora

Se seu domínio já publica p=reject, audite seus relatórios agregados antes, não depois, de o correio começar a ser rejeitado. Cada plataforma de terceiros que envia em seu nome, ferramentas de marketing, serviços de e-mail transacional, software de helpdesk, precisa ter o alinhamento de SPF ou DKIM confirmado contra seu registro DMARC real, e não assumido a partir de um guia de configuração seguido uma única vez.

Se seu domínio ainda está em p=none, esse registro não está protegendo ninguém. Ele está apenas coletando dados. Use os relatórios agregados que ele gera para identificar cada fonte de envio legítima, corrija o alinhamento de cada uma, e avance de forma deliberada por quarantine até reject, em vez de deixar a política em modo somente monitoramento indefinidamente.

Trate o GMX, WEB.DE e mail.com como uma prévia, não como uma exceção. A mudança dos provedores de caixa de entrada de um tratamento brando do DMARC para uma rejeição rígida no nível SMTP é a direção para onde toda a indústria está caminhando, seguindo os movimentos de aplicação anteriores do Gmail e do Yahoo. Os domínios que corrigem seu alinhamento agora evitam ser pegos de surpresa no próximo provedor que ativar essa chave.

A Conclusão

Um registro DMARC sem aplicação não impede nada, e uma política aplicada com alinhamento não verificado começa a rejeitar correio legítimo no momento em que um grande provedor como a 1&1 Mail & Media decide respeitá-la no nível SMTP. Os dois modos de falha são comuns, ambos são mensuráveis nos próprios relatórios agregados de um domínio, e ambos podem ser corrigidos bem antes de uma rejeição ou um e-mail falsificado forçar a questão.


A Excello Mail transforma seus relatórios agregados de DMARC em uma imagem clara de exatamente quais fontes de envio estão autenticadas e alinhadas, para que você possa avançar com confiança de p=none até a aplicação total sem precisar adivinhar qual mudança de política do próximo provedor vai pegá-lo desprevenido. Cadastre-se gratuitamente na Excello Mail para ver onde seu domínio realmente está.