Durante años, autenticar el correo fue una buena práctica: algo que los expertos recomendaban y casi nadie hacía. Eso se acabó. Desde 2024, los grandes proveedores de correo convirtieron esas recomendaciones en requisitos, y quien no los cumple ya no cae en spam: directamente le rechazan los correos. En el centro de todo está DMARC.
Qué es DMARC, en una frase
DMARC (*Domain-based Message Authentication, Reporting and Conformance*) es el registro que ata SPF y DKIM y le dice al proveedor receptor qué hacer con los correos que dicen venir de tu dominio pero no superan las comprobaciones de identidad. Además, activa informes diarios sobre quién envía en tu nombre.
Dicho simple: SPF y DKIM comprueban; DMARC decide y avisa. Sin DMARC, tu dominio no da instrucciones, y cada proveedor improvisa.
Qué cambió en 2024 (y en 2025)
En octubre de 2023, Google y Yahoo anunciaron juntos un conjunto de requisitos para quien envía correo. La aplicación empezó en febrero de 2024. En mayo de 2025, Microsoft se sumó con reglas equivalentes para sus dominios de consumo (Outlook.com, Hotmail, Live).
Las reglas distinguen dos niveles. Todo el que envía correo debe autenticar con SPF y DKIM y mantener su infraestructura limpia. Y los remitentes masivos —quien envía unos 5.000 correos o más al día a direcciones de ese proveedor— tienen obligaciones adicionales:
– Publicar un registro DMARC (como mínimo `p=none`).
– Lograr alineación : el dominio del «De:» debe coincidir con el validado por SPF o DKIM.
– Mantener la tasa de quejas de spam por debajo del 0,3% (el objetivo recomendado es 0,1%).
– Ofrecer baja en un clic (RFC 8058) en los correos de marketing, y procesarla en un máximo de dos días.
Un apunte importante: aunque el umbral «duro» son los 5.000 diarios, la autenticación beneficia a todos. Incluso por debajo de ese volumen, un dominio sin SPF/DKIM tiene muchas más papeletas de acabar en spam.
Qué pasa si no cumples
Aquí está el cambio de fondo. Antes, un correo mal autenticado iba a la carpeta de spam. Ahora, a partir de ciertos umbrales, se rechaza en el propio servidor : no llega ni al buzón ni al spam, rebota. Google, Yahoo y Microsoft devuelven errores concretos (códigos 550) que significan, en la práctica, «no me fío de este dominio, fuera».
Para una empresa, eso puede traducirse en presupuestos que no llegan, facturas que se pierden, campañas que nunca se entregan. Y como el rebote es silencioso para el destinatario, muchas veces te enteras tarde.
¿Basta con poner `p=none` y ya?
Técnicamente, publicar `p=none` cumple el requisito de «tener DMARC». Pero `p=none` no bloquea nada: solo observa. No te protege de la suplantación, y los proveedores miran cada vez con más recelo a los dominios que llevan años estancados en `p=none` sin avanzar hacia el bloqueo. Es un mínimo de partida, no una meta.
De hecho, la propia norma ha subido de categoría: en mayo de 2026 se publicó la revisión del estándar (conocida como DMARCbis) como especificación formal del IETF, lo que endurece las expectativas de implementación en todo el ecosistema. La dirección es clara: autenticar bien va a ser cada vez más exigible, no menos.
El objetivo real: llegar a `p=reject` sin romper nada
Cumplir de verdad significa avanzar de `p=none` a `p=quarantine` y, finalmente, a `p=reject`, que es el único nivel que impide que alguien suplante tu dominio. Pero ese avance no se hace de golpe: hay que identificar primero todas las fuentes legítimas que envían en tu nombre —a menudo más de las que la empresa cree— para no bloquear tus propios correos por el camino.
Ese es exactamente el trabajo que hacemos en Reliant: llevar tu dominio de «sin protección» a `p=reject` de forma segura y por fases, y vigilarlo después para que siga cumpliendo cuando cambien las reglas.
¿Quieres saber si tu dominio cumple los requisitos actuales? Pide tu diagnóstico gratuito y te decimos en qué punto estás y qué te falta.