Pasar DMARC de p=none a p=reject sin romper el correo

Para pasar DMARC de p=none a p=reject de forma segura, primero usa los informes agregados para encontrar cada fuente legítima que envía como tu dominio y haz que cada una pase SPF o DKIM alineado. Después pasa a quarantine en modo de prueba, luego a quarantine completo y luego a reject, avanzando solo cuando los informes no muestren nada legítimo que falle.

El orden no ha cambiado en una década. Lo que cambió en mayo de 2026 es la herramienta que la mayoría de las guías usa para los pasos intermedios. El RFC 9989, el nuevo estándar de DMARC, retiró la etiqueta pct. La propia página de despliegue recomendado de Google, actualizada por última vez el 1 de octubre de 2026, todavía te dice que uses pct=5. Esta guía funciona con ambos.

Por qué p=none no es la meta

p=none pide a los receptores que no hagan nada distinto con el correo que falla DMARC. Cumple el mínimo que Google, Yahoo y Microsoft fijan para los remitentes masivos (consulta los requisitos de Gmail y Yahoo para remitentes masivos) y te da informes. No impide que alguien envíe correo que dice venir de tu dominio.

La mayoría de las grandes marcas que revisamos ya terminaron este paso. Cuando consultamos con dig la política DMARC publicada de 40 grandes marcas de consumo y B2B el 1 de octubre de 2026, 35 estaban en p=reject, 4 en p=quarantine y 1 en p=none. Esas empresas tienen grandes equipos de seguridad. Los pasos de abajo son lo que hicieron, a menor escala.

Qué cambió: sale pct, entra t

Con la especificación anterior, el RFC 7489, pct=10 pedía a los receptores aplicar tu política al 10% del correo que fallaba. El RFC 9989 explica por qué se eliminó (Apéndice A.6):

Operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.

(La experiencia operativa mostró que la etiqueta "pct" por lo general no se aplicaba con precisión, salvo que el valor fuera 0 o 100, el predeterminado, y las imprecisiones con otros valores variaban mucho de una implementación a otra.)

Su reemplazo es la etiqueta t, con dos valores. t=y pide a los receptores que no apliquen la política declarada y que apliquen "un nivel por debajo": p=reject; t=y se comporta como quarantine, y p=quarantine; t=y se comporta como none. t=n (el valor predeterminado) significa aplicar la política. El RFC 9989 dice que son "análogos" a pct=0 y pct=100.

El problema de la transición es que los receptores se actualizarán a ritmos distintos. Un receptor con el nuevo estándar ignora pct ("unknown tags MUST be ignored", las etiquetas desconocidas DEBEN ignorarse), y un receptor que sigue en el RFC 7489 ignora t por la misma razón. Por suerte, los valores de prueba antiguos y nuevos coinciden. El RFC 7489 dice que cuando un correo escapa a una política reject por pct, el receptor "SHOULD treat the email as though the 'quarantine' policy applies" (DEBERÍA tratar el correo como si se aplicara la política "quarantine"). Así que durante la transición puedes publicar ambas y obtener el mismo comportamiento de los dos tipos de receptor:

v=DMARC1; p=reject; t=y; pct=0; rua=mailto:dmarc@example.com

Un receptor RFC 9989 lee t=y y pone en cuarentena. Un receptor RFC 7489 lee pct=0 y pone en cuarentena. Esa combinación es nuestra lectura de las dos especificaciones, no algo que alguno de los documentos prescriba, así que vigila tus informes después de publicarla.

Lo que pierdes es la rampa de 1%, 5% y 25%. Dado que el propio RFC encontró que los receptores aplicaban esos valores de forma inconsistente, perdías menos de lo que parecía.

El despliegue por etapas

Etapa	Registro	Qué hacen los receptores	Avanza cuando...
0. Monitorear	p=none; rua=...	Nada; envían informes	Cada fuente legítima pasa SPF o DKIM alineado durante 2 a 4 semanas
1. Quarantine, prueba	p=quarantine; t=y; pct=0; rua=...	Lo tratan como none (nuevos) o aplican su clasificación local (antiguos)	No aparecen nuevas fuentes que fallen
2. Quarantine	p=quarantine; rua=...	El correo que falla va a spam	2 a 4 semanas sin correo legítimo que falle
3. Reject, prueba	p=reject; t=y; pct=0; rua=...	Lo tratan como quarantine	Los informes siguen limpios
4. Reject	p=reject; rua=...	Rechazan el correo que falla	Sigue leyendo los informes

El tiempo en cada etapa es un criterio propio, no un estándar. La página de Google sugiere una semana en p=none porque "One week is usually enough time for the daily reports to contain data representative of all your mail streams" (una semana suele bastar para que los informes diarios contengan datos representativos de todos tus flujos de correo). Nosotros nos quedaríamos más tiempo si tu dominio tiene algo que envía cada mes o cada trimestre, como facturas, avisos de nómina o renovaciones anuales. Un remitente que solo envía el primer día del mes es invisible en una ventana de una semana.

Tres etiquetas que conviene resolver antes de salir de la etapa 0:

• sp fija la política para los subdominios. Si la omites, los subdominios heredan p. Si algún subdominio todavía tiene correo sin alinear, pon sp=none temporalmente en lugar de frenar todo el dominio.
• np, estandarizada en el RFC 9989, es una política para subdominios que no existen. np=reject detiene la suplantación de subdominios inventados como billing-secure.example.com, y normalmente puedes ponerla pronto porque nada legítimo puede enviar desde un nombre que no existe.
• rua debe estar en todas las etapas. Sin informes, cambias la política a ciegas.

Puedes crear cualquiera de estos registros con nuestro generador de DMARC y revisar lo que está publicado con el verificador de DMARC.

Cómo leer los informes agregados

Los informes agregados (rua) son archivos XML que envían los receptores, normalmente una vez al día. El RFC 9990 define el formato. Un solo registro del ejemplo del Apéndice B del RFC 9990 se ve así:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>pass</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>example.com</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim>
    <spf><domain>example.com</domain><result>fail</result></spf>
  </auth_results>
</record>

Léelo así: 123 mensajes desde la IP 192.0.2.123 decían venir de example.com. DKIM pasó y estaba alineado, SPF falló, y como DMARC solo necesita un resultado alineado que pase, el resultado es pass.

Para cada IP de origen, hazte tres preguntas:

1. ¿Este remitente es nuestro? Busca el dueño de la IP y su DNS inverso. Si es tu ESP, tu CRM o tu herramienta de soporte, es legítimo. Si es una IP residencial en un país donde no operas, es suplantación, que es justo para lo que sirve reject.
2. Si es nuestro, ¿pasa alineado? Mira policy_evaluated. Un pass en dkim o en spf es suficiente.
3. Si falla, ¿por qué? Compara auth_results con header_from. El patrón más común es que dkim pase, pero con el dominio del proveedor (por ejemplo <domain>sendgrid.net</domain>) en lugar del tuyo. Eso es un pass de DKIM, pero no uno alineado. La solución es configurar DKIM para tu propio dominio dentro de ese proveedor.

El XML en bruto se puede leer en un dominio pequeño. Con más de unos pocos remitentes, usa un procesador de informes, pero aprende primero a leer un registro a mano para poder comprobar lo que te dice el procesador.

Los bloqueos habituales

Síntoma en los informes	Causa probable	Solución
Un proveedor conocido falla la alineación de SPF y de DKIM	El proveedor firma con su propio dominio y usa su propio dominio de rebote	Configura DKIM personalizado (y return-path personalizado, si lo ofrece) para tu dominio
SPF muestra permerror	El registro supera las 10 consultas DNS	Consulta cómo corregir demasiadas consultas SPF
DKIM falla solo en algunos mensajes de una fuente conocida	Una lista de correo o un gateway que modifica el mensaje, o un pie agregado después de firmar	Firma después de la última modificación; revisa el gateway
Volúmenes pequeños que fallan desde muchas IP sin relación, con tu header_from	Reenvío (SPF se rompe) o suplantación	Si DKIM pasa, es reenvío y sobrevivirá. Si ambos fallan desde IP aleatorias, es suplantación
Falla un subdominio que olvidaste que existía	Un sistema antiguo que sigue enviando	Corrígelo o pon sp=none mientras lo haces

Cuándo quedarse en quarantine

reject es lo correcto para la mayoría de los dominios, pero no de forma automática. Quédate en quarantine si una parte importante de tu correo legítimo se reenvía a través de sistemas que lo modifican y no logras que DKIM sobreviva. El correo en cuarentena todavía se puede encontrar en una carpeta de spam, mientras que el correo rechazado desaparece. BIMI acepta tanto quarantine como reject, así que no necesitas reject para el logo.

La conclusión práctica

Publica hoy p=none con una dirección rua si todavía no lo has hecho, y lee los informes hasta que puedas nombrar cada fuente de envío. Después avanza por quarantine hasta reject, usando t=y con pct=0 como paso de prueba para que los receptores antiguos y nuevos se comporten igual. Deja rua activado de forma permanente. Los informes son la forma en que te enterarás cuando alguien de marketing se registre en una nueva herramienta que envía como tu dominio.