DMARC p=none, quarantine y reject: cómo migrar con RFC 9989 sin romper correo legítimo

RFC 9989 convirtió DMARC en un estándar del IETF en mayo de 2026 y sustituyó RFC 7489 y RFC 9091. La política p expresa la preferencia del dueño del dominio cuando un mensaje usa su dominio visible en From y falla DMARC: none no pide un tratamiento especial; quarantine considera el mensaje sospechoso; reject considera inválido ese uso del dominio.

Es una preferencia, no un interruptor universal. El receptor conserva su política local y puede aceptar un mensaje que falla o bloquear uno que pasa. RFC 9989 recalca además que DMARC pass solo valida que el uso del dominio está autorizado; no garantiza bandeja principal, contenido legítimo ni buena reputación.

La migración busca proteger el dominio contra spoofing exacto sin bloquear fuentes autorizadas. No resuelve dominios visualmente parecidos ni suplantación por display name. Tampoco convierte una lista mala en buena. DMARC protege identidad de dominio; deliverability y relevancia siguen trabajando turno completo.

El cambio que rompe muchas guías antiguas es directo: RFC 9989 retiró el tag pct. Bajo RFC 7489, pct pretendía aplicar quarantine o reject solo a un porcentaje de fallos. La experiencia operativa mostró que los receptores no lo aplicaban de manera consistente salvo en los extremos 0 y 100, por lo que el nuevo estándar lo marca como histórico.

RFC 9989 introduce t como modo de prueba. Con t=y, el dueño pide que la política efectiva baje un nivel: p=quarantine se trate como none y p=reject como quarantine. Con t=n —el valor por defecto— se solicita aplicar la política declarada. El tag no cambia reportes y no tiene efecto cuando p=none.

Hay una cautela importante durante la transición del ecosistema. RFC 9989 ordena ignorar tags desconocidos; un receptor basado en la especificación anterior puede ignorar t=y y aplicar p=quarantine o p=reject directamente. Por eso t es una señal útil del estándar actual, pero no un sustituto de inventario, pruebas y capacidad de rollback. Y pct=25 ya no es una barandilla confiable, aunque algunas páginas de proveedores todavía lo documenten.

Enumera cada sistema que puede usar el dominio en el From visible: Google Workspace o Microsoft 365, CRM, help desk, facturación, formularios, alertas de producto, firma electrónica, plataforma de eventos, ecommerce, secuenciadores, agencias y aplicaciones internas. Incluye flujos de bajo volumen; una factura mensual puede ser más importante que cien newsletters.

Por cada fuente registra owner, propósito, proveedor, dominio From, dominio MAIL FROM o Return-Path, DKIM d= y selector, volumen, destinos principales, última evidencia y plan de salida. Señala si envía desde el dominio raíz o un subdominio y si reenvía, pasa por listas o modifica contenido después de firmar.

Contrasta el inventario con reportes agregados DMARC. Una fuente desconocida no es automáticamente un atacante y una fuente conocida no está automáticamente bien configurada. Clasifica cada combinación de IP, dominio SPF y dominio DKIM como autorizada y alineada, autorizada con falla, no reconocida o spoofing confirmado.

DMARC pasa cuando al menos uno de dos caminos funciona y está alineado con el dominio del From visible: SPF valida el MAIL FROM y ese dominio alinea, o DKIM valida una firma cuyo d= alinea. Un resultado spf=pass o dkim=pass aislado no demuestra DMARC pass; puede autenticar el dominio del proveedor en vez del dominio que ve el destinatario.

La alineación relajada, usada por defecto, acepta dominios con el mismo dominio organizacional. La estricta exige identidad exacta. No actives adkim=s o aspf=s por reflejo: puede romper integraciones legítimas que usan subdominios. La política correcta depende del control que tengas sobre el namespace y de lo que muestran mensajes recibidos y reportes.

Para p=reject, RFC 9989 advierte que no se debe depender solo de SPF porque el forwarding suele cambiar la ruta e IP. DKIM puede sobrevivir mientras el mensaje no se modifique de forma incompatible. Cada fuente importante debería firmar con DKIM alineado y conservar SPF alineado cuando el proveedor lo permita.

Un registro inicial simple puede ser v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Cambia la dirección, protégela y usa un procesador capaz de leer reportes agregados; recibir XML comprimido en una bandeja que nadie abre no cuenta como monitoreo.

Mantén p=none hasta observar todos los ciclos relevantes: campañas semanales, facturación mensual, renovaciones, eventos y flujos estacionales. RFC 9989 reconoce que organizaciones complejas pueden necesitar muchos meses para saber si autentican todo. No existe una regla universal de siete o treinta días que sustituya el calendario real de envío.

Define criterios de salida antes de empezar: todas las fuentes autorizadas con owner, DKIM alineado para flujos críticos, fallos explicados, alertas sobre fuentes nuevas y prueba de mensajes en Gmail, Microsoft y receptores relevantes. El objetivo no es llevar fallos totales a cero; los intentos de spoofing deben fallar. Mide qué proporción del volumen autorizado pasa y qué negocio se afectaría si lo restante se bloquea.

Primero identifica qué camino debería pasar. Si el proveedor ofrece DKIM personalizado, publica su selector, activa firma y confirma en un mensaje recibido que d= alinea con el From. Si ofrece MAIL FROM o bounce domain personalizado, configúralo y comprueba SPF y alineación. No agregues IPs al SPF del dominio visible si el proveedor usa otro MAIL FROM; eso puede aumentar consultas sin resolver DMARC.

Revisa transformaciones posteriores. Un gateway que modifica el cuerpo puede invalidar DKIM; un forward rompe con frecuencia SPF; una plataforma puede firmar antes de que otra agregue contenido. Descarga el original del mensaje final y compara Authentication-Results, From, Return-Path y DKIM-Signature. La consola del sender muestra intención; el mensaje recibido muestra el resultado.

Si una herramienta no soporta alineación, decide entre cambiar configuración, usar un subdominio separado, cambiar proveedor o retirar el flujo. Documenta excepciones con owner y fecha. p=none no debe convertirse en permiso indefinido para una integración que nadie se atreve a tocar.

Cuando el correo autorizado está inventariado y alineado, publica p=quarantine para el dominio que estés listo para controlar. RFC 9989 permite v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com como señal de prueba equivalente a pedir un nivel menor, pero receptores antiguos pueden ignorar t. Trátalo como observación adicional, no como garantía de que ningún mensaje irá a spam.

La forma más controlable de escalonar es separar superficies. Aplica enforcement primero a un subdominio de envío con inventario pequeño y explícito; conserva monitoreo en dominios que todavía mezclan usuarios, listas y proveedores desconocidos. Los tags sp y np permiten expresar políticas para subdominios existentes y no existentes, pero un registro explícito por subdominio suele facilitar ownership y rollback.

Durante quarantine revisa reportes, bounces, tickets, mensajes enviados a listas y muestras reales. Compara al menos un ciclo completo antes y después. Para dominios cuyos usuarios participan en mailing lists, RFC 9989 recomienda como precaución un mínimo de un mes en p=none y otro mes en p=quarantine antes de considerar reject.

Pasa a reject cuando puedas explicar las fuentes autorizadas, no cuando un dashboard muestre un círculo verde. Los flujos críticos deben tener DKIM válido y alineado, muestras de recepción, owner y ruta de corrección. Los fallos residuales necesitan una decisión explícita: corregir, aislar, retirar o aceptar el riesgo de bloqueo.

Prueba forwarding y mailing lists si tus usuarios dependen de ellos. RFC 9989 señala problemas de interoperabilidad y recomienda que dominios con usuarios que publican en listas sean muy cautelosos con reject. La firma DKIM alineada ayuda frente a forwarding, pero una lista que modifica asunto o cuerpo todavía puede romperla.

Prepara el cambio como operación: valor anterior, nuevo registro, TTL observado, responsable, ventana, métricas, contactos de proveedores y criterio de rollback. El registro final puede ser v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com. Omitir t equivale a t=n. No incluyas pct esperando una aplicación parcial que el estándar vigente retiró.

Separar correo por propósito vuelve visibles los límites: por ejemplo, mensajes humanos en example.com, transaccionales en notify.example.com y prospección en un dominio o subdominio controlado según política de marca y riesgo. La separación no mejora reputación por sí sola, pero evita que una herramienta desconocida impida endurecer todo el namespace.

Publica políticas explícitas donde cambie el owner o el riesgo. sp define la política para subdominios existentes cuando no tienen una aplicable más específica; np, incorporado al estándar actual, cubre subdominios inexistentes. Antes de usar valores avanzados, verifica la jerarquía DNS y cómo descubre la política RFC 9989; una etiqueta copiada sin entender el árbol puede ampliar el alcance de forma inesperada.

Para outbound, no uses la separación como licencia para ocultar prácticas malas. Cada dominio necesita SPF, DKIM, DMARC, MX cuando deba recibir respuestas, supresión, control de proveedor y medición. La arquitectura reduce blast radius; no reduce la responsabilidad del remitente.

Sigue volumen autorizado por fuente, porcentaje con DMARC pass, DKIM alineado, SPF alineado, fallos por motivo, fuentes nuevas y disposición reportada. Añade métricas de negocio para flujos críticos: facturas entregadas, resets recibidos, replies de ventas y tickets. Un cambio DNS puede verse sano en agregado mientras rompe un mensaje poco frecuente y valioso.

Alerta cuando aparece una IP o dominio DKIM nuevo, cae el pass de una fuente autorizada, vence un selector o cambia el volumen de forma anormal. Conserva el histórico antes y después de migraciones de proveedor. Los reportes muestran el último salto observado por el receptor y no sustituyen logs del sender ni pruebas end-to-end.

DMARC pass tampoco es una métrica de inbox placement. RFC 9989 lo dice con claridad: autorización del dominio no implica que el mensaje sea seguro o deseable. Vigila reputación, quejas, rebotes, engagement útil y calidad de lista por separado.

Si un flujo legítimo crítico se bloquea, reduce temporalmente la política solo con incidente abierto, owner y plazo, mientras corriges alineación. Guarda el registro previo, cambia una variable y considera caché DNS. No borres rua: necesitas reportes para confirmar qué mejoró o empeoró.

No resuelvas cada fallo añadiendo proveedores al SPF. SPF tiene límites de consultas y, para DMARC, todavía necesita alineación. Prioriza DKIM alineado, dominios MAIL FROM controlados y retiro de servicios obsoletos. Si una agencia administra infraestructura, exige inventario, selectores, acceso y procedimiento de salida.

Después del incidente, actualiza la matriz de remitentes y automatiza una prueba. El mejor rollback no es volver a p=none para siempre; es recuperar el flujo, explicar la causa y regresar a la política elegida con evidencia nueva.

Cambiar none por reject tarda segundos. Saber si el dominio está listo puede tomar semanas o meses. RFC 9989 hace más honesta esa transición: retiró el porcentaje que prometía un rollout gradual pero se aplicaba de forma desigual, y formalizó un modo de prueba cuya compatibilidad también debe evaluarse.

picos.Ai puede auditar dominios, proveedores y mensajes recibidos; mapear alineación; procesar reportes; separar subdominios; y preparar gates, alertas y rollback. En outbound, conectamos esa capa con inventario de inboxes, agencias, supresión y respuesta, porque un dominio protegido que no puede recibir o enrutar replies todavía tiene un problema comercial.

Si tu DMARC sigue en p=none, contiene pct o depende de una plataforma que nadie ha probado de extremo a extremo, usa el enlace Hablemos al final de esta página. El siguiente paso no es copiar un TXT nuevo: es demostrar qué correo autorizado sobrevivirá al cambio.