El equipo de postmaster de 1&1 Mail & Media, la empresa detrás de GMX, WEB.DE y mail.com, informó este trimestre en la lista de correo mailop que está implementando la aplicación total de DMARC en su infraestructura de correo entrante, respetando las políticas p=reject directamente en la transacción SMTP en lugar de tratarlas como una señal más entre otras. El correo de un dominio que publica p=reject y no logra pasar DMARC mediante SPF alineado o DKIM alineado ahora es rechazado directamente, con el servidor emisor recibiendo “554 Transaction failed Reject due to domain’s DMARC policy” antes de que el mensaje llegue siquiera a un buzón. GMX, WEB.DE y mail.com en conjunto sirven a 42 millones de usuarios activos y ocupan una posición líder en Alemania, Austria y Suiza, así que no se trata de un proveedor de correo menor ajustando un detalle. El informe de referencia de entrega Q1 2026 de Postmastery, construido sobre 15.500 millones de transacciones rastreadas, señala este cambio como uno de los movimientos de entregabilidad más importantes del año. En la misma ventana, el informe de adopción de DMARC 2026 de EasyDMARC encontró que 525.996 dominios, más de la mitad de todos los dominios que alguna vez publicaron un registro DMARC, siguen estacionados en p=none. Estos dos hechos están en lados opuestos del mismo problema, y ninguno de los dos tiene sentido sin el otro.
Qué Cambió Realmente en GMX, WEB.DE y mail.com
DMARC técnicamente ha cubierto a GMX y WEB.DE desde 2021, cuando el proveedor dijo por primera vez que respetaría las políticas publicadas por los dominios emisores para ayudar a proteger a los usuarios de direcciones suplantadas. Lo que cambia ahora es la profundidad de la aplicación. Una política p=reject publicada era algo que estos proveedores podían sopesar junto con otras señales. Ahora es una instrucción estricta: sin SPF alineado, sin DKIM alineado, no hay entrega, decidido durante la propia conversación SMTP en lugar de después del hecho. Para un remitente cuya autenticación ya está en orden, esto no cambia nada. Para un remitente que publicó p=reject hace años como una casilla de cumplimiento y nunca verificó que cada fuente de envío legítima, una plataforma de marketing, una herramienta de mesa de ayuda, un relé interno, esté realmente alineada, este es el momento en que el correo mal configurado empieza a rebotar en una de las mayores bases de buzones de la Europa de habla alemana.
La Otra Mitad de la Historia: Dominios Que Nunca Activaron la Política
El informe de EasyDMARC pone en números concretos el otro lado de este problema. De los dominios que alguna vez publicaron un registro DMARC, más de la mitad se encuentra en p=none, la configuración de solo monitoreo que genera reportes agregados pero no toma ninguna acción contra el correo suplantado. Esa cifra coincide casi exactamente con el cronograma de los requisitos de remitentes masivos de Google y Yahoo de 2024, que exigían DMARC en p=none como mínimo. Millones de dominios superaron ese mínimo y se detuvieron ahí. Entre las Fortune 500, el 95% tiene un registro DMARC válido y más del 80% aplica en quarantine o reject; el reporte es casi universal, con un 97,9%. Entre las Inc. 5000, la adopción es un respetable 76,2%, pero solo el 15,2% llega alguna vez a p=reject, y más de la mitad permanece atascada en p=none. El patrón se repite en todos los sectores medidos: publicar un registro DMARC ya es lo mínimo esperado, pero el paso de monitoreo a aplicación real es donde se estanca la gran mayoría de las organizaciones.
Por Qué Esto Importa para DMARC y la Entregabilidad
Estos dos desarrollos describen la misma brecha desde direcciones opuestas. Que GMX, WEB.DE y mail.com apliquen p=reject del lado receptor solo protege a los remitentes que ya hicieron el trabajo de llevar su propia política a p=reject y mantener alineadas todas las fuentes autorizadas. Para los 525.996 dominios que siguen en p=none, este cambio de aplicación no aporta ninguna protección adicional, porque en primer lugar no existe una política de rechazo que los servidores de GMX puedan respetar. Un correo suplantado que se hace pasar por uno de esos dominios sigue llegando a un buzón de GMX, WEB.DE o mail.com exactamente como lo hacía antes. Mientras tanto, para el grupo más pequeño de dominios que sí publicaron p=reject sin confirmar que todas sus fuentes de envío permanecen alineadas, esta aplicación es el momento en que años de configuración sin verificar se convierten en correo rebotado real, facturas perdidas y tickets de soporte. El valor de DMARC nunca estuvo en que el registro existiera. Siempre estuvo en la brecha entre “publicado” y “aplicado y correcto”, y esta semana dos datos independientes aterrizaron exactamente en esa brecha desde ángulos distintos.
Qué Deben Hacer los Remitentes Ahora
Si su dominio ya publica p=reject, audite sus reportes agregados antes, no después, de que el correo empiece a rebotar. Cada plataforma de terceros que envía en su nombre, herramientas de marketing, servicios de correo transaccional, software de mesa de ayuda, necesita tener confirmada la alineación de SPF o DKIM contra su registro DMARC real, no asumida a partir de una guía de configuración que siguió una sola vez.
Si su dominio sigue en p=none, ese registro no está protegiendo a nadie. Está recolectando datos. Use los reportes agregados que genera para identificar cada fuente de envío legítima, corrija la alineación de cada una, y avance de forma deliberada por quarantine hasta reject en lugar de dejar la política en modo de solo monitoreo indefinidamente.
Trate a GMX, WEB.DE y mail.com como un anticipo, no como una excepción. El paso de los proveedores de buzón de un manejo blando de DMARC a un rechazo estricto a nivel SMTP es la dirección hacia la que va toda la industria, siguiendo los movimientos de aplicación anteriores de Gmail y Yahoo. Los dominios que corrigen su alineación ahora evitan quedar mal parados en el próximo proveedor que active el interruptor.
La Conclusión
Un registro DMARC sin aplicación no detiene nada, y una política aplicada con alineación sin verificar empieza a rebotar correo legítimo en el momento en que un proveedor importante como 1&1 Mail & Media decide respetarla a nivel SMTP. Ambos modos de falla son comunes, ambos son medibles en los propios reportes agregados de un dominio, y ambos se pueden corregir mucho antes de que un rebote o un correo suplantado obligue a resolverlo.
Excello Mail convierte sus reportes agregados de DMARC en una imagen clara de exactamente qué fuentes de envío están autenticadas y alineadas, para que pueda avanzar con confianza de p=none a la aplicación total sin adivinar qué cambio de política del próximo proveedor lo tomará por sorpresa. Regístrese gratis en Excello Mail para ver dónde está realmente su dominio.