DMARC en 2026: qué es, cómo configurarlo y qué cambia con los nuevos RFC

La autenticación del correo dejó de ser una tarea exclusiva del equipo técnico. Si una marca envía campañas, correos transaccionales o newsletters desde su propio dominio, una mala configuración puede afectar la entregabilidad, facilitar la suplantación y deteriorar la reputación construida con cada envío. En 2026, el estándar DMARC dio además su mayor actualización desde que comenzó a utilizarse hace más de una década.

Los nuevos RFC 9989, RFC 9990 y RFC 9991 convierten DMARC en un estándar de Internet formal, separan el protocolo de sus dos sistemas de reportes y aclaran cómo deben descubrirse y aplicarse las políticas. La buena noticia es que los registros actuales siguen funcionando: no hay que reconstruir la autenticación desde cero.

Qué es DMARC y para qué sirve

DMARC significa Domain-based Message Authentication, Reporting and Conformance. Es una política publicada como registro TXT en el DNS de un dominio. Su función es indicar a Gmail, Yahoo, Outlook y otros receptores qué hacer cuando un correo que usa ese dominio en el campo From: no supera correctamente SPF o DKIM.

DMARC añade dos piezas que SPF y DKIM no resuelven por sí solos:

Alineación: comprueba que el dominio autenticado por SPF o DKIM coincida —de forma relajada o estricta— con el dominio visible para la persona que recibe el mensaje.
Política: permite recomendar que los mensajes fallidos se monitoricen, se envíen a spam o se rechacen.
Reportes: entrega información agregada sobre quién está enviando en nombre del dominio y qué fuentes fallan.

Esto protege tanto la entregabilidad legítima como la identidad de marca. Es un complemento operativo para cualquier estrategia de email marketing en 2026, no un sustituto de una base de datos consentida, una buena segmentación o contenidos relevantes.

Cómo trabajan juntos SPF, DKIM y DMARC

Los tres mecanismos cumplen funciones distintas:

SPF autoriza qué servidores pueden enviar correo por un dominio.
DKIM firma criptográficamente el mensaje para verificar que procede de un emisor autorizado y que no fue alterado.
DMARC exige alineación con el dominio visible, define la política ante un fallo y habilita reportes.

Un mensaje puede superar DMARC si pasa SPF o DKIM y el identificador que pasa está alineado con el dominio del encabezado From:. En la práctica conviene configurar correctamente ambos: las redirecciones pueden romper SPF y una firma DKIM bien implementada aporta una segunda vía de autenticación.

Por qué DMARC importa para Gmail y Yahoo

Las directrices actuales de Gmail exigen autenticación a quienes envían a cuentas personales. Para volúmenes superiores a 5.000 mensajes diarios, Google pide además una política DMARC —p=none es suficiente para comenzar—, alineación del dominio, bajas sencillas en mensajes promocionales y una tasa de spam inferior al 0,30%.

Yahoo exige a los remitentes masivos SPF y DKIM, una política DMARC válida con al menos p=none, alineación, baja sencilla y una tasa de spam por debajo del 0,3%. Son requisitos de acceso a la bandeja de entrada, no trucos para garantizarla: la reputación, el consentimiento y el comportamiento de los usuarios siguen influyendo.

Cómo configurar DMARC paso a paso

1. Haz un inventario de todos los emisores

Antes de tocar el DNS, identifica cada servicio que envía con tu dominio: plataforma de email marketing, CRM, ecommerce, facturación, soporte, formularios web, herramientas de eventos y proveedores transaccionales. Un emisor olvidado puede quedar bloqueado cuando la política pase a reject.

2. Verifica SPF y DKIM

SPF debe incluir únicamente los servicios autorizados y mantenerse dentro del límite técnico de consultas DNS. DKIM debe estar activo en cada proveedor con un dominio de firma alineado. En ambos casos, evita copiar registros genéricos: usa los valores que entrega cada plataforma y comprueba el resultado en un mensaje real.

3. Publica una política de monitorización

El registro se crea como TXT en _dmarc.tudominio.com. Un punto de partida sencillo es:

v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com

p=none no solicita bloqueo; permite observar. La dirección indicada en rua recibirá reportes agregados XML, por lo que conviene usar un buzón o servicio diseñado para procesarlos. Si los reportes se envían a otro dominio, ese destino debe autorizar la recepción mediante DNS.

4. Analiza los reportes y corrige la alineación

Revisa qué IP y proveedor envían, cuántos mensajes pasan SPF o DKIM y qué fuentes fallan. Separa los envíos legítimos mal configurados de intentos de suplantación. Esta etapa puede durar varias semanas según el volumen y la complejidad del dominio.

5. Avanza a cuarentena y rechazo

Cuando todas las fuentes válidas estén alineadas, cambia progresivamente la política:

p=none: monitoriza sin pedir una acción especial.
p=quarantine: recomienda tratar los fallos como sospechosos, normalmente enviándolos a spam.
p=reject: recomienda rechazar los mensajes que no superen DMARC.

El receptor conserva la decisión final, porque DMARC es una señal dentro de un sistema antispam más amplio. Aun así, llegar a reject con una configuración sana reduce de manera importante el abuso directo del dominio.

Qué cambió con DMARC en 2026

La actualización conocida durante años como DMARCbis se publicó en mayo de 2026. El protocolo base pasó del RFC 7489, de carácter informativo, al RFC 9989 en la vía de estándares. Los reportes agregados quedaron en el RFC 9990 y los reportes de fallos individuales en el RFC 9991.

Los principales cambios prácticos son:

DNS Tree Walk: sustituye la dependencia del Public Suffix List para descubrir el dominio organizacional y la política aplicable. El receptor consulta la jerarquía DNS con un número de búsquedas acotado.
Nuevo t: activa un modo de prueba. t=y indica que una política de cuarentena o rechazo se está probando y no debe aplicarse como bloqueo; t=n es el valor predeterminado.
Nuevo np: permite definir una política específica para subdominios inexistentes, con valores none, quarantine o reject.
Nuevo psd: permite declarar si un nombre actúa como dominio de sufijo público.
Se elimina pct: ya no existe la aplicación porcentual de la política.
Se eliminan rf y ri: los reportes agregados se estandarizan en XML y el intervalo deja de ser configurable por el dominio.
Se aclara sp: la política para subdominios tiene sentido en el registro del dominio organizacional y se ignora cuando aparece en un registro de subdominio.

Como resumió Resend al explicar la actualización, los registros existentes continúan siendo válidos. El cambio inmediato recae sobre todo en implementadores, receptores y organizaciones que quieran adoptar las nuevas capacidades.

Cómo migrar si todavía usas pct

El antiguo pct permitía aplicar una política solo a un porcentaje de los mensajes. Con el nuevo estándar, la recomendación práctica es monitorizar con p=none hasta corregir las fuentes y después pasar a quarantine o reject. Si se necesita probar una política de aplicación completa sin bloquear, puede usarse t=y.

No conviene interpretar t=y como una migración porcentual: es un modo de prueba, no una escala gradual. Antes de retirar pct, revisa cómo lo utilizan tus proveedores y conserva una copia del registro anterior.

Privacidad: cuidado con los reportes de fallos

Los reportes agregados enviados a rua presentan estadísticas. Los reportes individuales solicitados mediante ruf pueden incluir encabezados e incluso contenido del mensaje. El RFC 9991 advierte que eso puede exponer datos personales, información comercial sensible o comunicaciones confidenciales.

Para la mayoría de los equipos de marketing, los reportes agregados bastan para desplegar y supervisar DMARC. Si se solicitan reportes de fallos, deben evaluarse retención, acceso, redacción, base legal y ubicación del proveedor. Esta precaución forma parte del mismo enfoque de confianza que exige el tratamiento responsable de datos first-party.

Errores frecuentes que debes evitar

Publicar p=reject antes de inventariar CRM, ecommerce y herramientas transaccionales.
Confundir autenticación con alineación: SPF o DKIM pueden pasar y DMARC fallar si usan otro dominio.
Crear más de un registro DMARC en _dmarc. Debe existir una política válida y única.
Enviar reportes a un buzón personal sin capacidad para procesar XML o grandes volúmenes.
Ignorar subdominios, dominios estacionados y dominios defensivos que la marca no usa para enviar.
Pensar que DMARC sustituye la baja fácil, el consentimiento o el control de quejas.

Preguntas frecuentes sobre DMARC

¿DMARC mejora automáticamente la entregabilidad?

No la garantiza, pero elimina fallos de identidad que dañan confianza y cumplimiento. Una configuración correcta facilita que los receptores distingan el correo legítimo; la reputación, el contenido y las quejas siguen contando.

¿Puedo empezar con p=none?

Sí. Es el punto de partida recomendado para recopilar reportes sin bloquear mensajes. La meta no debería ser quedarse allí indefinidamente, sino corregir fuentes y avanzar hacia una política de aplicación.

¿Necesito SPF y DKIM para que DMARC pase?

DMARC puede pasar con uno de los dos si está autenticado y alineado. Sin embargo, configurar ambos mejora la resiliencia y ayuda a cumplir las prácticas de los grandes proveedores.

¿Los nuevos RFC obligan a cambiar mi registro?

No. Los registros DMARC existentes siguen funcionando. Conviene revisar etiquetas obsoletas como pct, entender el nuevo modo t y evaluar np si la marca necesita una política para subdominios inexistentes.

¿Dónde se publica DMARC?

Como registro TXT en el nombre _dmarc del dominio. Para ejemplo.com, la ubicación es _dmarc.ejemplo.com. El valor debe comenzar con v=DMARC1.

La recomendación para equipos de marketing

Trata DMARC como un proyecto compartido entre marketing, tecnología y seguridad. Marketing sabe qué plataformas envían; tecnología controla el DNS; seguridad interpreta el riesgo de suplantación y privacidad. Ese inventario conjunto es lo que permite pasar de monitorizar a proteger sin bloquear campañas legítimas.

La actualización de 2026 no invalida lo que ya funciona, pero sí marca un buen momento para auditar el dominio, retirar configuraciones heredadas y convertir la autenticación en una parte medible de la operación de email.