# ¿Qué es DMARC? Alineación, Políticas y RFC 2026 del IETF URL: https://notificationharbor.com/es/journal/que-es-dmarc Type: blog Locale: es Published: 2026-09-29 Updated: 2026-09-29 --- > DMARC le dice a receptores qué hacer cuando el correo reclama ser de tu dominio pero falla la autenticación. Aquí es cómo el registro, políticas y reportes funcionan, y qué cambió en 2026. ¿Qué es DMARC? Es un registro DNS que le dice a los servidores de correo receptores qué hacer cuando un mensaje reclama ser de tu dominio en el header From pero falla la autenticación, y dónde enviar reportes al respecto. DMARC no autentica nada por sí solo. Verifica que SPF o DKIM pasó y que el dominio que validaron coincide con el dominio que el lector ve. Esa coincidencia se llama alineación, y es la parte que la mayoría de los equipos no hacen bien. Un mensaje puede pasar SPF, pasar DKIM y fallar DMARC. ## DMARC es una capa de política sobre SPF y DKIM SPF lista qué IPs pueden enviar para un dominio. DKIM firma el mensaje para que un receptor pueda verificar que no fue alterado y que el dominio firmante lo autorizó. Ninguno de los dos mira la dirección From que un humano lee. DMARC cierra esa brecha. Hace una sola pregunta: ¿el dominio en el header From visible coincide con el dominio que pasó SPF o DKIM? Si sí, el mensaje pasa. Si no, el receptor aplica tu política. ![Engineer reviewing DNS records in a terminal on a laptop at a desk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp) El registro vive en `_dmarc.tudominio.com` como un registro TXT. Uno mínimo y válido se ve así: `_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"`Tres tags hacen el trabajo real. `p` es la política, `rua` es dónde van los reportes agregados, y `adkim` / `aspf` establecen cuán estricta es la alineación. Todo lo demás es opcional. ## La alineación es dónde fallan las configuraciones bien intencionadas SPF autentica el remitente de sobre (Return-Path domain). DKIM autentica el dominio en el tag `d=` de la firma. DMARC necesita que al menos uno de esos coincida con el dominio From, ya sea exactamente (strict) u a nivel de dominio organizacional (relaxed, el predeterminado). Aquí está el fallo que vemos más a menudo en las trazas. Un equipo envía por un proveedor tercerista, el proveedor firma con su propio dominio (`d=provider-mail.net`) y usa su propio bounce domain. SPF pasa, DKIM pasa, y DMARC falla porque ningún dominio coincide con `example.com`. La solución es un dominio de envío personalizado: una clave DKIM publicada bajo tu dominio, e idealmente un return-path personalizado en un subdominio. Cada proveedor serio lo soporta. Pocos lo habilitan por defecto. ## Las tres políticas: none, quarantine, reject El tag `p` tiene tres valores, y no son una escalera que subes según un cronograma. - **`p=none`**: el receptor entrega normalmente y te envía reportes. Úsalo las primeras 2 a 4 semanas, mientras inventarías remitentes. - **`p=quarantine`**: el receptor envía fallos a spam o junk. Úsalo una vez los reportes muestren todos los orígenes legítimos alineados. - **`p=reject`**: el receptor rechaza fallos en la etapa SMTP. Úsalo una vez quarantine ha corrido limpio por un ciclo de envío completo. `p=none` es monitoreo, no protección. Un dominio en `none` durante dos años tiene una casilla de cumplimiento y ninguna defensa contra suplantación. Evita la tentación de dejarlo ahí porque "nada se rompió". `p=reject` es el destino para cualquier dominio que solo envía correo que controlas. Los dominios con tráfico pesado de listas de correo o redirecciones heredadas necesitan más cuidado, porque el reenvío a menudo rompe SPF y puede romper DKIM si el intermediario edita el cuerpo. ## Por qué las reglas de Gmail y Yahoo lo hicieron urgente Desde febrero de 2024, [las directrices de remitente de Google](https://support.google.com/mail/answer/81126?hl=en) requieren que cualquiera que envíe más de 5.000 mensajes por día a cuentas de Gmail publique un registro DMARC, con SPF y DKIM en su lugar. La política puede ser `none`. Google también pide a los remitentes en volumen mantener la tasa de spam reportada por usuarios en Postmaster Tools por debajo de 0,30%, y recomienda estar por debajo de 0,10%. [El Sender Hub de Yahoo](https://senders.yahooinc.com/best-practices/) establece el mismo requisito central: una política DMARC válida de al menos `p=none`, con el dominio From alineado a SPF o DKIM. La alineación relajada es aceptable. Nota qué está y qué no está en esas reglas. El requisito es un registro publicado y una alineación que pase, no cumplimiento obligatorio. Eso es un piso. No es una línea de meta. ![Lowered customs barrier at a harbor container yard at dusk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp) ## Los reportes agregados son el producto, la política es el interruptor La dirección `rua` recibe reportes XML diarios de cada receptor que respeta DMARC. Cada reporte lista IPs de origen, conteos de mensajes, los resultados de SPF y DKIM, y si la alineación se mantuvo. Así es como encuentras el remitente olvidado: la vieja exportación de CRM, la herramienta de facturación que un contratista conectó en 2022, el formulario de marketing en un subdominio que nadie posee. XML bruto es ilegible a volumen. Envía `rua` a un buzón que un parser pueda ingerir, o a un servicio de reporte DMARC alojado, y mira los datos agrupados por origen. Lo que quieres ver es cada origen legítimo mostrando 100% alineado, y todo lo demás claramente desconocido. Un despliegue práctico corre en este orden: - Publica `p=none` con una dirección `rua`. - Recopila dos a cuatro semanas de reportes. Construye el inventario de remitentes. - Arregla cada origen legítimo no alineado con un dominio DKIM personalizado o return-path. - Cambia a `p=quarantine`. Espera por tickets de soporte sobre correo faltante. - Cambia a `p=reject` cuando quarantine muestra sin fallos legítimos. Despliega cada paso por separado. Cambiar la política y agregar un nuevo proveedor de envío en la misma semana hace que cualquier regresión sea imposible de atribuir. ## DMARCbis cambia los tags, no tu registro En 2026 el IETF publicó RFC 9989, RFC 9990 y RFC 9991, que obsoletan RFC 7489. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) es la especificación central de DMARC. Los reportes agregados y de fallo se movieron a sus propios documentos. Los cambios prácticos para un propietario de registro son pequeños: - `pct`, `rf` e `ri` se eliminan. - `t` (modo testing) reemplaza `pct` como interruptor todo-o-nada: `t=y` reporta sin cumplir. - `np` establece una política para subdominios no existentes, lo que bloquea la suplantación de direcciones como `abc123.example.com`. - `psd` marca dominios de sufijo público, y un recorrido por árbol DNS reemplaza la vieja búsqueda de Public Suffix List. Los registros `v=DMARC1` existentes siguen siendo válidos. Nada se rompe si no cambias nada hoy. El soporte de proveedores para los nuevos tags se desplegará de manera desigual, así que un nuevo tag que parece no hacer nada usualmente significa que el receptor aún no lo ha implementado. El tag `np` es el que vale la pena adoptar temprano. Establecer `np=reject` mientras `p` sigue en `none` cierra la ruta de abuso de subdominio falso sin comprometer el resto de tu correo a cumplimiento obligatorio. ## Subdominios, y por qué el predeterminado hereda Un registro DMARC en el dominio organizacional se aplica a subdominios también, a menos que lo sobrescribas con `sp`. Esa herencia es útil y también una trampa. Si marketing envía desde `news.example.com` a través de un proveedor separado, hereda la política padre. Mueve el padre a `p=reject` antes de que ese proveedor haya alineado DKIM y el boletín va al suelo. Publica un registro separado `_dmarc.news.example.com` cuando un subdominio tiene su propia flota de remitentes y su propio ritmo de despliegue. Una arquitectura más limpia separa streams por subdominio desde el principio. Correo transaccional en uno, lifecycle en otro, correo humano en la raíz. Cada uno obtiene sus propias claves DKIM, su propia reputación, y su propio registro DMARC. ## Lee el header Authentication-Results antes de adivinar Cuando un mensaje falla, el servidor receptor registra por qué. En Gmail, "Mostrar original" expone el header `Authentication-Results`, y te dice más que cualquier panel. `Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.provider-mail.net; dkim=pass header.d=provider-mail.net; dmarc=fail (p=NONE) header.from=example.com`Léelo de izquierda a derecha. SPF pasó para `bounce.provider-mail.net`. DKIM pasó para `provider-mail.net`. DMARC falló porque el header From dice `example.com` y ningún dominio que pasó coincide con él. La nota `(p=NONE)` muestra la política que el receptor vio. En `none` este mensaje se entregó de todas maneras. En `reject` habría rebotado con un error 5.7.x, y el remitente lo habría descubierto de un cliente. Dos comprobaciones atrapan la mayoría de estos casos. Confirma que el valor `header.d` en el resultado DKIM es tu dominio. Luego confirma que el dominio `smtp.mailfrom` es tu dominio o un subdominio del mismo. ## SPF tiene un límite de búsquedas que DMARC expone SPF permite diez búsquedas DNS por evaluación. Cada `include:` para un proveedor gasta algo, e includes anidados gastan más. Cruza diez y SPF devuelve un error permanente, que cuenta como fallo. Los equipos con cinco o seis herramientas de envío golpean esto sin notarlo, porque los fallos de SPF eran invisibles antes de DMARC reporting. Una vez que los reportes `rua` llegan, el patrón es obvio: un origen de repente fallando SPF en todos los receptores el día que alguien agregó otro `include:`. Esta es otra razón más para confiar en la alineación DKIM como el camino primario. DKIM sobrevive la mayoría del reenvío, no tiene presupuesto de búsqueda, y está vinculado al mensaje en lugar de a la IP conectante. Mantén SPF válido, pero no construyas tu paso DMARC sobre él solo. ## Lo que DMARC no hará DMARC previene suplantación de dominio exacto. No detiene dominios parecidos (`examp1e.com`), no juzga contenido, y no arregla una reputación de remitente pobre. Un dominio perfectamente alineado que envía a listas compradas aún termina en spam. Tampoco reemplaza el monitoreo. La alineación puede romperse en silencio: un cambio DNS elimina un selector DKIM, un proveedor rota claves, una nueva herramienta comienza a enviar sin tu conocimiento. Los reportes son cómo te enteras antes de que lo hagan tus usuarios. Trata el registro DMARC como cualquier otro código de producción. Pertenece al control de versiones, los cambios pasan por revisión, y el buzón `rua` necesita un propietario. ![Cream envelope being sealed with a red wax stamp](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp) ## Antes de publicar el registro Corre esto una vez. Toma menos de una hora para un dominio único. - Lista cada sistema que envía correo como tu dominio: producto, facturación, soporte, CRM, marketing, invitaciones de calendario. - Confirma que cada uno firma DKIM con tu dominio, no el del proveedor. - Establece un return-path personalizado donde el proveedor lo permita. - Elige un destino `rua` que alguien leerá. - Comienza en `p=none`, y pon la fecha en que planeas revisarlo en el calendario. - Comprueba la tasa de spam en Google Postmaster Tools semanalmente durante el despliegue. ## A dónde ir desde aquí Si nunca has mirado tus reportes, publica `p=none` con una dirección `rua` hoy y lee qué llega en dos semanas. El primer reporte casi siempre nombra al menos un remitente que nadie recordaba. El siguiente paso concreto es decidir cuál de esos mantienes. ## FAQ ### ¿Es DMARC obligatorio? Para remitentes en volumen, efectivamente sí. Google requiere un registro DMARC para remitentes de más de 5.000 mensajes por día a Gmail, y Yahoo requiere una política válida de al menos p=none. La cumplimiento obligatorio no es requerida, pero el registro y la alineación sí. ### ¿Qué significa p=none en DMARC? Significa solo monitoreo. Los receptores entregan el correo que falla normalmente y te envían reportes. Satisface el mínimo de Gmail y Yahoo pero no da protección contra suplantación. ### ¿Puede un correo pasar SPF y DKIM pero fallar DMARC? Sí. DMARC requiere que el dominio validado por SPF o DKIM se alinee con el dominio From. El correo enviado por un proveedor que firma con su propio dominio pasa ambas comprobaciones pero aún falla alineación. ### ¿Cuánto tiempo debo quedarme en p=none? Típicamente dos a cuatro semanas de reportes agregados, tiempo suficiente para ver cada remitente legítimo incluyendo los de bajo volumen. Continúa una vez que cada origen legítimo se muestra alineado. ### ¿Afecta DMARC la entregabilidad? Indirectamente. Un registro publicado y alineado es un requisito de línea base en Gmail y Yahoo, y fallar alineación puede empujar el correo a spam o disparar rechazo bajo una política de cumplimiento obligatorio. No arregla reputación pobre del remitente o tasas altas de reclamos. ### ¿Qué cambió con DMARCbis y RFC 9989? RFC 9989 obsoleta RFC 7489. Elimina pct, rf e ri, agrega t, np y psd, y reemplaza búsquedas de Public Suffix List con un recorrido por árbol DNS. Los registros v=DMARC1 existentes siguen siendo válidos.