¿Necesito DMARC si ya tengo SPF y DKIM?

SPF y DKIM prueban que un servidor estaba autorizado a enviar o que un mensaje venía firmado, pero ninguno está amarrado a la dirección que tu lector ve en el campo De. DMARC es la regla que exige que uno de los dos pase para tu propio dominio, y es el único de los tres que te manda un reporte con todo lo que envía con tu dominio. Gmail además pide a quienes envían más de 5,000 mensajes al día a cuentas de Gmail tener los tres configurados.

¿No sirve de nada p=none si no bloquea nada?

Sí sirve. Un registro en p=none no cambia cómo los receptores tratan tu correo, y eso es justo la idea: te consigue los reportes agregados diarios sin ningún riesgo de entrega. También alcanza para cumplir el requisito de Gmail, que dice que la política de aplicación de DMARC puede estar en none. A quarantine y reject subes después, cuando los reportes muestren alineado a cada remitente legítimo.

¿Cuánto tiempo pasa antes de poder poner p=reject?

Google sugiere observar los reportes al menos una semana y confirmar que tu correo saliente autentica antes de pasar a quarantine, y después ampliar la cobertura con el tiempo antes de reject. En la práctica el plazo lo definen tus remitentes, no el calendario: un dominio con Workspace y un solo sistema de facturación puede quedar en dos o tres semanas, mientras uno con CRM, tienda, boletines y un escáner toma más, porque cada uno se alinea por separado.

Qué es DMARC y cómo configurarlo: tu primer registro

Una firma contable de doce personas nos escribe en la última semana del mes porque sus facturas dejaron de llegar. No todo su correo: los mensajes que la gente escribe a mano desde Gmail siguen entrando bien. Los que desaparecen son los que manda el sistema de facturación. Alguien en un foro les dijo que configuraran DMARC, pegaron un registro que encontraron en internet y por la tarde el CRM también se había quedado callado. Es una forma normal de llegar a este tema, y se arregla en una tarde cuando entiendes qué revisa DMARC de verdad.

DMARC no es un filtro de spam y no es un interruptor que haga que tu correo se entregue mejor. Es una instrucción pública tuya, del dueño del dominio, para cada servidor que reciba un mensaje que dice venir de ti. Dice dos cosas: así se distingue mi correo real del correo que solo dice ser mío, y esto quiero que hagas con el que no pase la prueba. Escrito, es una línea de DNS. Entendido, es la única parte de la autenticación de correo que te dice quién está enviando con tu dominio.

El problema que resuelve DMARC

Cualquiera puede escribir tu dominio en el campo De de un mensaje. No es una falla de un servidor en particular, es como funciona el formato, y por eso una factura falsa convincente que sale de tu propio dominio es un ataque tan barato. Dos mecanismos más antiguos cierran cada uno una parte del hueco.

SPF es una lista, publicada en tu DNS, de los servidores autorizados a enviar correo por tu dominio. DKIM es una firma que se agrega al mensaje mismo y se verifica contra una llave pública que publicas en tu DNS. Los dos sirven y los dos tienen el mismo punto ciego: ninguno está amarrado a la dirección que tu lector ve en el campo De. Un mensaje puede pasar SPF para un dominio completamente distinto y aun así mostrarle tu nombre a quien lo lee.

DMARC es la regla que conecta las dos, y además hace algo que casi ninguna otra parte del correo hace: te manda un reporte.

La alineación es todo el truco

Para pasar DMARC, un mensaje tiene que pasar SPF o DKIM, y el dominio que pasó tiene que coincidir con el dominio del campo De que ve tu lector. Google lo dice claro en su propia documentación: los mensajes salientes deben pasar SPF o DKIM, y en el correo directo el dominio del encabezado De debe estar alineado con el dominio de SPF o con el de DKIM. Pasar uno de los dos alcanza. No pasar ninguno de forma que coincida con tu dominio es una falla de DMARC, por limpio que se vea el resto del mensaje.

Hay dos niveles de exigencia para esa coincidencia. Relajado, que es el predeterminado, acepta la coincidencia a nivel del dominio organizacional, así que un mensaje firmado para correo.ejemplo.com se alinea con una dirección De en ejemplo.com. Estricto exige que los dominios sean idénticos. Vale repetir lo que dice la guía de solución de problemas de Google: la alineación estricta puede mandar a spam correo legítimo de subdominios asociados, y la relajada normalmente da protección suficiente contra la suplantación. Si no tienes una razón concreta, déjala relajada.

La alineación es también de dónde sale el problema de las facturas del primer párrafo. Digamos que el sistema de facturación envía como facturacion@ejemplo.com, pero sus servidores usan una ruta de retorno en el dominio del proveedor y firman con la llave DKIM del proveedor. SPF pasa. DKIM pasa. DMARC falla, porque ninguno de los dominios que pasaron es el tuyo. Un registro puesto en reject el primer día convierte ese detalle de autenticación en facturas que no llegan.

Tu primer registro: p=none y un lugar donde recibir los reportes

El orden importa más que la velocidad. La guía de Google es tener SPF y DKIM configurados, y funcionando desde al menos 48 horas antes, cuando activas DMARC. Si te lo saltas, el correo de tu dominio probablemente va a tener problemas de entrega, que es justo lo que querías evitar.

El registro es un solo registro DNS de tipo TXT en el host _dmarc de tu dominio. Las etiquetas v y p van primero; las demás pueden ir en cualquier orden.

Host:  _dmarc
Tipo:  TXT
Valor: v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com

Léelo en voz alta y es corto. p=none quiere decir: no cambies cómo tratas mi correo, solo cuéntame qué estás viendo. rua es la dirección donde llegan los reportes agregados diarios. Google recomienda que sea un grupo o un buzón dedicado y no la bandeja personal de alguien, y después de la primera semana de archivos XML vas a entender la recomendación. Los reportes se envían normalmente una vez al día, por cada receptor que vio tu correo.

Hay dos etiquetas más que vale conocer antes de que un consultor te las ofrezca. sp define una política aparte para los subdominios que existen, y np define una para los subdominios que no existen, que es como evitas que alguien invente facturas.ejemplo.com y envíe desde ahí. Cuando np no está, aplica la política de sp, y cuando tampoco está sp, aplica la de p. Las dos están definidas en el RFC 9989, la especificación vigente de DMARC.

Lee los reportes antes de endurecer nada

Este es el paso que la gente se salta, y es el único que hace seguro todo lo demás. Cada reporte agregado es un archivo XML de un receptor que cubre un día de tu correo: qué direcciones IP lo enviaron, cuántos mensajes, si SPF y DKIM pasaron, y si se alinearon con tu dominio. No lo lees por los números. Lo lees para armar la lista de todo lo que en este mundo envía correo con tu dominio.

En una pyme esa lista es más larga de lo que el dueño espera, y casi siempre es alguna versión de esto: Google Workspace o Microsoft 365 para las personas, el sistema de facturación o contabilidad, el CRM, la tienda en línea, la herramienta de boletines, el formulario de contacto del sitio, un escáner en una esquina de la oficina que manda PDF, y un servicio que nadie recuerda haber contratado. Revísala y pon cada remitente en uno de tres grupos.

Ya alineado. Nada que hacer. Casi todo tu correo de Workspace o Microsoft 365 cae aquí.
Tuyo, y fallando. Los que hay que arreglar, uno por uno, casi siempre activando la firma DKIM del proveedor para tu dominio o configurando una ruta de retorno propia. Este es el trabajo real de un proyecto de DMARC.
No es tuyo. Alguien enviando con tu dominio sin que debiera. Este grupo es el que justifica todo el ejercicio, y la razón por la que en algún momento vas a querer una política distinta de none.

Subir a quarantine y después a reject

El despliegue que recomienda Google es observar los reportes por lo menos una semana, confirmar que tu propio correo saliente está autenticando, luego pasar a quarantine para que el correo que falla caiga en la carpeta de spam donde el destinatario todavía puede encontrarlo, empezando con una parte pequeña de los mensajes y subiéndola con el tiempo hasta todos, y solo después pasar a reject.

Una corrección a las guías viejas, incluidas muchas que siguen en línea. Te dicen que hagas esa subida con una etiqueta pct en el registro. El RFC 9989, publicado en mayo de 2026, reemplazó al RFC 7489 como especificación de DMARC y quitó pct de la sintaxis del registro; el apéndice que cubre el cambio se titula "Removal of the 'pct' Tag". Lo que la especificación sí conserva para un despliegue prudente es la etiqueta t, una señal de que todavía no quieres que se aplique la política que declaraste, que no cambia nada de los reportes y no tiene efecto mientras la política sea none. La lectura práctica para un dominio pequeño: no armes tu plan alrededor de un porcentaje. Alinea todos los remitentes de tu lista, quédate en quarantine una semana cuando haya alguien atento a los reclamos, y después pasa a reject. La seguridad viene del inventario, no de la fracción.

También ayuda saber qué piden los receptores grandes, porque es menos de lo que se supone. Gmail exige a quienes envían más de 5,000 mensajes al día a cuentas de Gmail tener SPF, DKIM y DMARC configurados, y dice con claridad que la política de aplicación de DMARC puede estar en none. Las mismas guías piden que el encabezado De esté alineado con el dominio de SPF o de DKIM, una tasa de spam por debajo de 0.30% en Postmaster Tools, DNS directo e inverso válidos, y TLS en la conexión. Es decir, p=none cumple el requisito. Subes a reject para proteger tu propio dominio de que lo usen contra tus clientes, no para cumplirle a Gmail.

Los errores que más arreglamos

Casi toda configuración de DMARC rota que nos entregan es uno de estos seis.

Dos registros en _dmarc. Uno viejo de un intento anterior al lado del nuevo. DMARC espera exactamente un registro de política, y con dos publicados en la práctica no tienes ninguno.
Un rua que nadie puede leer. Un error de dedo en el mailto, o reportes que caen en un buzón que ningún humano abre. Entonces el dominio se queda en p=none dos años, lo que no protege nada y no le dice nada a nadie.
Alineación estricta copiada de un blog. Suena más segura y es el ajuste con más probabilidad de mandar a spam el correo de tus propios subdominios.
Saltar directo a p=reject. El registro es fácil de publicar y el daño es invisible para ti, porque los rebotes llegan a los sistemas que envían en tu nombre, no a tu bandeja.
Olvidar el subdominio desde el que envía la herramienta de marketing. Una política en el dominio raíz no arregla un remitente sin alinear en un subdominio, y sp existe justo para esto.
Esperar que DMARC sobreviva al reenvío. Cuando un mensaje se reenvía, SPF se rompe con frecuencia, porque el servidor que reenvía no está en tu lista. DKIM sobrevive mucho mejor al reenvío, que es una buena razón para asegurarte de que DKIM esté firmando antes de aplicar cualquier política.

Cómo ayuda Guanacos Tech

En un proyecto de entregabilidad, esto es casi todo el trabajo real: nombrar cada sistema que envía con el dominio, leer suficientes reportes para estar seguros de que la lista está completa, arreglar la alineación remitente por remitente, y quedarnos en los reportes lo suficiente para saber que el arreglo aguantó antes de subir la política. Nada de eso es ingenioso. Solo es ordenado, y el orden es lo que mantiene las facturas llegando. Si quieres hacerlo tú con el registro de arriba y una semana de reportes, es un resultado perfectamente bueno. Si los reportes te devolvieron nueve remitentes y dos que no puedes identificar, para eso está nuestra consultoría de entregabilidad de correo. Trae tu dominio y un mensaje que esté fallando a una llamada de 30 minutos y sales sabiendo qué remitentes son el problema y qué toma resolverlos.

Qué es DMARC y cómo configurarlo paso a paso, sin romper tu propio correo