La checklist DMARC 2026: de cero a p=reject

Paso 3 — Implementación de DKIM

Donde SPF autoriza servidores, DKIM firma criptográficamente los mensajes: cada correo lleva una firma que el destinatario verifica mediante una clave pública publicada en el DNS. Una firma válida sobrevive a los reenvíos, allí donde SPF se rompe —por eso DKIM es el pilar de alineación más robusto—. El punto que despista al principio es el selector: esa etiqueta (s1._domainkey, google._domainkey…) que permite a un dominio llevar varias claves en paralelo. El selector DKIM explicado levanta el velo; el pilar DKIM cubre la generación de claves y lo demás. Conviene apuntar a una clave de 2048 bits.

Paso 4 — Publicación de DMARC en p=none con rua

Solo ahora se publica DMARC, y se publica en p=none. No es una protección, es un microscopio: p=none no bloquea nada, solo pide recibir informes. La etiqueta decisiva en esta fase es rua, la dirección que recopila los informes agregados diarios. Sin rua, se avanza a ciegas; con ella, por fin se ve quién emite en nombre del dominio. Un registro mínimo se parece a v=DMARC1; p=none; rua=mailto:informes@ejemplo.es. Conviene resistir la tentación de ir más rápido: p=none es el peldaño de observación, y saltárselo es bloquear a ciegas.

Paso 5 — Lectura de los informes agregados

Una vez que los informes llegan, hay que leerlos, y ahí es donde mucha gente abandona, porque el formato en bruto es XML ilegible a simple vista. Estos informes agregados dicen, fuente por fuente, cuántos mensajes pasaron o fallaron SPF y DKIM y, sobre todo, la alineación. Aprender a descifrarlos es el verdadero punto de inflexión del proyecto: es lo que transforma «publico DMARC» en «sé qué hace mi dominio». Entender los informes agregados DMARC explica qué mirar y en qué orden. Conviene tomar dos o tres semanas de datos antes de concluir nada.

Paso 6 — Corrección de la alineación, fuente por fuente

Es el corazón del trabajo, y el peldaño más largo. Los informes van a revelar fuentes legítimas que fallan la alineación: un proveedor que firma bajo su propio dominio (d=), un servidor olvidado, un include SPF que falta. Para cada una se corrige: publicar la clave DKIM del proveedor, añadir el include, activar la firma. El objetivo: que el 100 % del correo legítimo pase SPF o DKIM alineado. No hay que endurecer mientras quede una fuente legítima fallando; es ella la que saltará. Esta fase de remediación metódica es exactamente lo que describe la checklist de none a reject: marcar cada fuente antes de avanzar.

Paso 7 — Subida a quarantine

Cuando los informes están limpios —ninguna fuente legítima fallando ya—, se sube el primer peldaño de aplicación de la política: p=quarantine. El correo que falla DMARC se va entonces a spam en lugar de entregarse. Y aquí es donde DMARCbis cambia el método: hay que olvidar el antiguo pct=25, imprevisible y retirado del estándar. En su lugar se pone el modo de prueba t=y, que dice a los destinatarios «estoy experimentando, notifíquenme los fallos sin endurecer todavía estrictamente». Se pilota la subida observando los informes, no con un porcentaje al azar. La etiqueta t de DMARCbis detalla este mecanismo; para captar bien la diferencia de fondo entre los dos niveles, quarantine o reject, cuál elegir zanja la cuestión.

Paso 8 — Subida a p=reject

Es el peldaño que todo lo demás preparaba. En p=reject, el correo fraudulento es rechazado antes de llegar a la bandeja del destinatario —la suplantación del dominio se vuelve imposible, no solo señalada—. Si los pasos 1 a 7 se han hecho en serio, este paso es un no-evento: las fuentes están alineadas, los informes están limpios, solo quedan los defraudadores por bloquear. El método completo, con las precauciones para no romper ningún flujo, se describe en llegar a p=reject sin romper el correo. No hay que hacer el cambio hasta que varias semanas de informes en quarantine confirmen que solo lo ilegítimo falla.

Paso 9 — Blindaje de los subdominios

p=reject protege el dominio raíz, pero un atacante es astuto: apuntará a facturas.ejemplo.es o a un subdominio que nunca ha existido. Dos etiquetas cierran esa puerta. sp fija la política de los subdominios existentes; np, novedad de DMARCbis, cubre los subdominios inexistentes —el blanco favorito, porque forjar un nombre que no existe no dispara ninguna alerta del lado del DNS—. Poner np=reject es gratis y sin el menor riesgo para el correo legítimo. La política de subdominio (sp) y la etiqueta np para los subdominios inexistentes detallan cada uno su papel. Es aquí donde el DNS Tree Walk de DMARCbis hace su trabajo entre bastidores, vinculando limpiamente cada subdominio con su política.

Paso 10 — La recompensa: BIMI

Una vez en p=reject, se desbloquea un beneficio visible: BIMI muestra el logotipo oficial de la marca junto a los mensajes en las bandejas compatibles (Gmail, Apple Mail…). No es solo una coquetería: es una señal de confianza que mejora la apertura y complica la imitación. BIMI exige p=reject o p=quarantine: es literalmente la zanahoria al final del recorrido. Configurar BIMI y mostrar el logotipo en Gmail muestra cómo publicar el registro y, en su caso, obtener el certificado que lo acompaña. Es la medalla merecida tras la subida.

Lo que la checklist no dice con suficiente fuerza

Al releer los diez pasos, una cosa salta a la vista: ocho de cada diez no son configuración, sino observación y corrección. Publicar tres etiquetas lleva cinco minutos; saber cuándo endurecerlas lleva semanas de lectura de informes. Es todo lo contrario de la intuición, y es precisamente ahí donde la mayoría de los dominios se atascan: no por no saber escribir un registro, sino por no haber mantenido la disciplina de alineación el tiempo suficiente. El escenario 2026 no cambia esta verdad: DMARCbis moderniza las herramientas (Tree Walk, np, t=), no acorta la subida. El cambio completo al nuevo estándar una vez en p=reject está señalizado por separado, pero nunca es la primera urgencia: la aplicación de la política lo es.

Un matiz que salva proyectos: una checklist no es una carrera. Nadie da un premio por llegar a p=reject en una semana, y nadie penaliza por haber tardado tres meses. Lo que cuenta no es la velocidad de la subida, sino su seguridad. Un dominio que pasó demasiado rápido a p=reject, que bloquea sus propias facturas un lunes por la mañana, ha fracasado más completamente que un dominio que se quedó pacientemente en quarantine el tiempo de alinear su última fuente. Se avanza un peldaño cuando el anterior es sólido, no antes. Es tan aburrido como eso, y tan eficaz como eso.

En qué punto está el dominio, ahora mismo

El primer peldaño es gratis y lleva diez segundos. Basta con pasar el dominio por nuestro analizador DMARC gratuito: devuelve un veredicto inmediato sobre la política actual, los registros SPF y DKIM, y el paso exacto de la checklist en el que se sitúa. Para comparar la postura de un dominio con la de su sector —y comprobar cuántos dominios siguen estancados en p=none—, el Observatorio DMARC da el panorama.

Llevar esta checklist a mano, fuente por fuente y semana tras semana, es factible pero tedioso. Es exactamente lo que Thomas, el CISO virtual, automatiza: inventaría las fuentes a partir de los informes, nombra cada una, genera el DNS exacto que publicar (etiquetas DMARCbis incluidas: np, t), mide la preparación por dominio e indica el peldaño preciso en el que endurecer sin riesgo. Analizar un dominio gratis · explorar el Observatorio · empezar con Thomas.