¿Qué es DMARC? Alineación, Políticas y RFC 2026 del IETF

¿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.

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 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 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.

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:

1. Publica p=none con una dirección rua.

2. Recopila dos a cuatro semanas de reportes. Construye el inventario de remitentes.

3. Arregla cada origen legítimo no alineado con un dominio DKIM personalizado o return-path.

4. Cambia a p=quarantine. Espera por tickets de soporte sobre correo faltante.

5. 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 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.

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.