¿Cuánto tarda un despliegue de DMARC hasta p=reject?

En una pyme con pocos sistemas de envío, entre cuatro y seis semanas: dos semanas de monitoreo en p=none, una o dos arreglando la alineación de cada remitente que aparezca, una semana en quarantine y luego reject. Los dominios con muchas plataformas de marketing y facturación tardan más, porque cada plataforma necesita terminar su propia autenticación de dominio antes de mover la política.

¿Todavía necesito la etiqueta pct en mi registro DMARC?

No. El RFC 9989, publicado en mayo de 2026, eliminó pct junto con rf y ri, así que un registro nuevo no debería incluirla. Escalona el despliegue con sp, que permite endurecer el dominio raíz mientras los subdominios siguen en monitoreo, y toma la nueva bandera de prueba t como un extra y no como red de seguridad, porque el soporte de los receptores es reciente.

¿p=reject evita que suplanten el nombre de mi empresa?

Detiene el correo que pone tu dominio exacto en el encabezado From y no logra autenticarse como tú. No hace nada contra dominios parecidos ni contra un nombre para mostrar que imita a tu gerente desde un buzón gratuito, porque esos mensajes nunca dicen ser de tu dominio. Para eso se necesitan reglas de filtrado de entrada y capacitación, no una política DMARC.

DMARC: de p=none a p=reject sin romper tu correo

Un registro DMARC en p=none no protege nada. Le pide a los proveedores de correo que revisen si los mensajes que dicen venir de tu dominio pasan SPF o DKIM de forma alineada con la dirección que ve quien lee, y que después te manden un reporte diario de lo que vieron. La entrega no cambia. Nadie deja de suplantarte. Lo que obtienes es evidencia, y ese es todo el trabajo de la fase de monitoreo.

La parte que sí protege es la aplicación de la política. p=quarantine le pide al receptor que trate como sospechoso el correo que falla, y p=reject le pide que lo rechace en la puerta. También es la parte que rompe cosas, porque casi toda empresa envía correo desde lugares que ya olvidó: la plataforma de facturación, el CRM, el formulario de contacto del sitio, la impresora multifuncional del pasillo que manda PDFs escaneados desde una dirección de tu dominio.

Los dos grandes proveedores de correo de consumo ya volvieron obligatorio el registro de monitoreo. Google exige un registro DMARC a los dominios que envían más de 5,000 mensajes diarios a cuentas de Gmail, y aclara que la política puede quedar en none. Microsoft usa el mismo umbral de 5,000 mensajes para los buzones de consumo de Outlook y Hotmail, y el correo masivo que no cumple se rechaza con 550 5.7.515 Access denied. Ninguno de los dos exige aplicar la política. Lo que la exige es tu propia exposición a que suplanten tu dominio.

Este es el orden en que lo hacemos, y más o menos el mes que toma.

Paso 1: publica el registro de monitoreo y espera dos semanas

Primero deja funcionando SPF y DKIM, y dales al menos 48 horas antes de publicar DMARC, que es lo que pide la guía de configuración de Google. Después publica un solo registro TXT en la etiqueta _dmarc:

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com; fo=1"

La guía de despliegue de Google dice que una semana de reportes diarios suele bastar para ver todos tus flujos de correo. Para una pyme, dos semanas es mejor número, porque alcanza a cubrir la corrida mensual de facturación y el boletín que sale solo el primer martes. No acortes esa ventana. Cada día que te saltes aquí es un día de adivinar después, y esa adivinanza se paga el día que endureces la política.

Los reportes llegan como XML comprimido, uno por proveedor receptor por día, y ese formato ya tiene especificación propia en el RFC 9990. Leerlos a mano se puede, pero es tedioso. Mejor pega uno aquí y mira las fuentes separadas:

Paso 2: clasifica cada fuente en tres canastas

Anota todas las fuentes de envío que aparezcan en los reportes. Cada una va en exactamente una canasta:

Tuya y pasando. Un sistema que reconoces y que ya pasa SPF o DKIM con alineación. No hay nada que hacer.
Tuya y fallando. La reconoces, y falla, o pasa SPF pero con el dominio del proveedor en vez del tuyo. Esta es tu lista de trabajo, y aquí vive el riesgo de dejar a alguien sin correo.
Ajena. Fuentes que no puedes explicar, casi siempre fallando todo, muchas veces desde direcciones residenciales. Son la razón por la que empezaste. También son las más fáciles, porque la política se encarga de ellas y no rompe nada legítimo.

El reenvío enturbia la segunda canasta. Una lista de correo o un reenvío configurado por el usuario rompe SPF, porque el servidor que reenvía no está en tu registro, mientras que la firma DKIM suele sobrevivir si el mensaje no se modifica. Una fuente que falla SPF, pasa DKIM y pertenece a una universidad o a un servicio de listas casi siempre es un reenvío, no un ataque.

Paso 3: arregla la alineación, remitente por remitente

La alineación es la regla que a casi todos se les escapa. A DMARC no le importa que SPF haya pasado. Le importa que el dominio que pasó coincida con el dominio del encabezado From. Una campaña que pasa SPF para mailer.proveedor.com mientras quien lee ve tu@ejemplo.com falla DMARC con un SPF perfectamente verde. Esa combinación es la que sorprende a las empresas el día que ponen reject.

Google Workspace y Microsoft 365

Los dos firman con DKIM usando un selector que publicas en tu DNS, y en ambos hay que activar la firma a propósito. Workspace genera la llave en la consola de administración y tú la publicas en google._domainkey. Microsoft 365 usa dos registros CNAME más un interruptor en Defender, y escribimos aparte la guía completa de Microsoft 365. Cuando el correo sale firmado con una llave de tu propio dominio, la alineación aguanta incluso si el mensaje se reenvía.

Plataformas de marketing y correo transaccional

Mailchimp, HubSpot, Klaviyo, SendGrid, Mailgun y Amazon SES firman con su propio dominio por defecto, que es exactamente la desalineación de arriba. Todas tienen un proceso de autenticación de dominio que te entrega un juego de registros CNAME para publicar y así la firma lleve tu dominio. Hazlo con cada plataforma de la segunda canasta antes de tocar la etiqueta de política.

Facturación, ERP y proveedores de cobro

Cuenta todo lo que envía documentos a tu nombre, incluidos los proveedores de facturación electrónica. Pídele a cada uno su include de SPF y su registro DKIM, y vigila el límite de 10 consultas DNS de tu SPF conforme los vayas sumando. Si un proveedor no puede firmar como tu dominio, la solución honesta es que envíe desde un subdominio que tú controles, algo como facturacion.ejemplo.com, y manejar la política de ese subdominio aparte en lugar de debilitar el dominio raíz para todos.

Impresoras, escáneres y sistemas internos

El escáner del pasillo y el ERP de hace diez años que habla SMTP son las víctimas clásicas, porque nadie recuerda que existen hasta que dejan de llegar los PDFs. Apúntalos al relay autenticado de tu proveedor, con una cuenta real de tu dominio, en vez de dejarlos hablando solos con internet.

Paso 4: la rampa por porcentaje ya no existe

Si aprendiste DMARC antes de 2026, aprendiste a subir con pct=: publicar p=quarantine; pct=10, luego 25, luego 50, luego 100. Esa etiqueta ya no existe. DMARC pasó a ser protocolo de estándares en mayo de 2026 con el RFC 9989, que deja obsoleto al RFC 7489 informativo de 2015 y elimina pct junto con rf y ri. Mucha documentación de proveedores todavía describe la escalera de porcentajes. No armes un despliegue nuevo sobre ella.

Dos etiquetas cubren para lo que en realidad servía pct.

t= es una bandera de modo de prueba. El RFC 9989 la define como una señal al receptor sobre si quieres que la política declarada en p, sp o np se aplique de verdad. No cambia la generación de reportes y no tiene ningún efecto cuando la política es none. El soporte es reciente, así que tómala como una cortesía de los receptores que ya la implementaron y no como una red de seguridad.

sp= es la que carga con el peso en un despliegue real, porque deja que el dominio raíz y los subdominios avancen a distinta velocidad:

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@ejemplo.com"

Ese registro endurece el correo que sale de ejemplo.com mientras cada subdominio, incluido el de facturación, se queda en monitoreo hasta que estés listo. Invierte los dos valores cuando los subdominios ya estén limpios y al dominio raíz todavía le falte un rezagado.

Paso 5: la semana de quarantine

Pasa a quarantine cuando la segunda canasta lleve siete días seguidos vacía en los reportes. Luego vigila tres cosas durante una semana: los reportes agregados por si aparecen fuentes nuevas, la mesa de ayuda por si alguien pregunta si te llegó su mensaje, y un buzón de prueba fuera de la empresa al que envíes desde cada sistema interno que puedas alcanzar.

Quarantine es un fallo suave a propósito. Si algo se te pasó y empieza a caer en correo no deseado, te vas a enterar rápido, y volver atrás es una edición de DNS. Deja el TTL del registro _dmarc en 300 segundos durante todo el despliegue para que revertir tome minutos y no un día, y súbelo cuando ya estés tranquilo.

Paso 6: pon reject y cierra los huecos

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@ejemplo.com"

np= es la etiqueta que casi todos olvidan. Fija la política para los subdominios que no existen en el DNS, que es justo por donde se cuela buena parte de la suplantación: nadie publicó nunca facturas.ejemplo.com, así que alguien lo usa y ese correo se juzga con lo que diga sp, o con p si no hay sp, que casi siempre es más permisivo de lo que elegirías para un nombre que jamás debería enviar nada. Ponerla en reject no cuesta nada, porque por definición ningún sistema real envía desde un nombre que nunca publicaste.

Aquí caben dos tareas de limpieza. Los dominios que tienes pero desde los que nunca envías merecen su propio registro DMARC en reject, porque a los nombres estacionados los suplantan más seguido que al que usas todos los días. Y si quieres que tu logo aparezca junto a tus correos, BIMI exige que el dominio organizacional esté en quarantine o reject, sin un sp=none deshaciéndolo por debajo, así que endurecer la política es el requisito y no el premio.

Reject no es la meta final

Mantén viva la dirección de rua y sigue leyendo. Se contratan proveedores nuevos, alguien de marketing se registra en una plataforma sin avisar, un proveedor cambia su dominio de firma. Los reportes son el único lugar donde vas a ver eso antes que un cliente. Después del primer trimestre, una revisión al mes alcanza.

Cómo ayuda Guanacos Tech

La mayoría de los dominios que llevamos a p=reject llegan con un registro que alguien publicó hace años en p=none y una dirección de reportes que nadie leyó nunca. Inventariamos los remitentes con datos reales de los reportes, arreglamos la alineación uno por uno, escalonamos la política como describe este artículo y nos quedamos en el dominio durante la semana de quarantine para que revertir sea una decisión y no una carrera. Si llevas tiempo en p=none porque el siguiente paso se ve riesgoso, agenda una llamada y leemos tus reportes contigo.

Cómo pasar DMARC de p=none a p=reject sin romper facturas, CRM ni la impresora