Registro DMARC: ejemplo y respuesta corta
Un registro DMARC que sirve para casi cualquier dominio desde el primer día es v=DMARC1; p=none; rua=mailto:[email protected], publicado como registro TXT en el host _dmarc.ejemplo.com. Ese registro pide a los servidores de correo receptores que entreguen todo como siempre, pero que te envíen cada día un informe sobre quién envía correo con tu dominio en la dirección del remitente (From). Cuando esos informes muestran que todo tu correo legítimo pasa, endureces la política DMARC paso a paso: primero quarantine y después reject.
Esta guía te da registros DMARC listos para copiar en cada etapa, una tabla con todas las etiquetas definidas en la especificación DMARC (RFC 7489), un plan seguro para pasar de p=none a p=reject, una explicación de los informes agregados y los errores de registro que más a menudo rompen DMARC. Para lo básico, consulta nuestra presentación de DMARC y la FAQ qué es un registro DMARC; este artículo se centra en ejemplos de registros y en el despliegue.
Puntos clave
- Un registro DMARC es un único registro TXT en _dmarc.tudominio. Debe empezar por v=DMARC1 y contener una política p=.
- La política DMARC tiene tres valores: none (solo supervisar), quarantine (tratar el correo que falla como sospechoso) y reject (rechazar el correo que falla).
- Un mensaje pasa DMARC cuando SPF o DKIM pasan y el dominio que ha pasado está alineado con el dominio de la dirección From visible.
- Empieza siempre con p=none y una dirección rua, lee los informes, corrige cada remitente legítimo y luego pasa a quarantine y reject.
- Un solo registro DMARC por dominio. Dos registros en el mismo host significa que no se aplica ninguno.
¿Para qué sirve un registro DMARC y cómo es?
Un registro DMARC sirve para decir a los receptores qué hacer con el correo que usa tu dominio sin autenticarse correctamente, y para pedirles informes. Tiene la forma de una línea corta de pares etiqueta=valor separados por punto y coma, guardada como registro TXT en el DNS, en el subdominio _dmarc del dominio desde el que envías. Si tu dirección de remitente es [email protected], el registro vive en _dmarc.ejemplo.com. El formato es siempre el mismo: primero la etiqueta de versión, después la política y luego las etiquetas opcionales en cualquier orden.
Registro DMARC en el DNS: qué poner en cada campo
| Campo DNS | Qué introducir | Ejemplo |
|---|---|---|
| Tipo | TXT | TXT |
| Host / Nombre | _dmarc (algunos paneles DNS piden el nombre completo) | _dmarc o _dmarc.ejemplo.com |
| Valor / Contenido | El propio registro DMARC | v=DMARC1; p=none; rua=mailto:[email protected] |
| TTL | El valor por defecto de tu proveedor DNS es suficiente | 3600 |
DMARC no sustituye a SPF ni a DKIM: se apoya en ellos. Si aún no los has configurado, empieza por nuestra explicación de qué es SPF y cómo funciona, y vuelve a DMARC cuando ambos estén en marcha.
Ejemplos de registro DMARC para cada situación
Los ejemplos de registro DMARC de abajo usan ejemplo.com y direcciones de informe inventadas. Sustitúyelas por tu dominio y por un buzón que realmente leas (o la dirección de una herramienta de informes).
1. Solo supervisión (p=none): el registro de partida
v=DMARC1; p=none; rua=mailto:[email protected]
Nada cambia en la entrega. Los receptores aplican su filtrado habitual y te envían informes agregados. Usa este registro las primeras semanas, mientras descubres todos los servicios que envían correo en nombre de tu dominio.
2. Poner en cuarentena una parte del correo que falla (p=quarantine con pct)
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
Una cuarta parte de los mensajes que fallan DMARC se trata como sospechosa (en la práctica, suele ir a la carpeta de spam). Según la RFC 7489, el 75 % restante se gestiona como si la política fuera none. Es un primer paso prudente hacia la aplicación de la política.
3. Cuarentena completa
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Sin etiqueta pct, la política se aplica al 100 % del correo que falla, porque 100 es el valor por defecto.
4. Aplicación total (p=reject)
v=DMARC1; p=reject; rua=mailto:[email protected]
Se pide a los receptores que rechacen cualquier mensaje que falle DMARC. Es el registro que impide que otros envíen correo que dice venir de tu dominio exacto. Mantén la etiqueta rua: sigues queriendo ver qué se bloquea.
5. Política distinta para los subdominios (sp)
v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]
El dominio principal está en reject, mientras que el correo de subdominios como tienda.ejemplo.com que no tienen registro DMARC propio va a cuarentena. Sin etiqueta sp, los subdominios heredan el valor de p.
6. Alineación estricta (adkim=s, aspf=s)
v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]
La alineación estricta exige que el dominio coincida exactamente: una firma DKIM de mail.ejemplo.com ya no cuenta para una dirección From en ejemplo.com. Úsala solo si estás seguro de que todos tus remitentes firman y gestionan los rebotes con el dominio From exacto.
7. Dominio que nunca envía correo
v=DMARC1; p=reject; sp=reject
Para un dominio aparcado o defensivo, rechaza todo. Combínalo con un registro SPF que no autorice a nadie (v=spf1 -all). Añadir una dirección rua es opcional aquí, pero te muestra quién intenta abusar del dominio.
8. Varias direcciones de informe e informes de fallo (ruf, fo)
v=DMARC1; p=none; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Los informes agregados van a dos buzones (sepáralos con una coma). Los informes de fallo van a un tercero, y fo=1 pide un informe de fallo cuando falla SPF o DKIM, no solo cuando fallan los dos.
Etiquetas DMARC explicadas: v, p, sp, rua, ruf, pct, adkim, aspf
La RFC 7489 define un conjunto reducido de etiquetas DMARC. Solo v y p son obligatorias; todas las demás tienen un valor por defecto que se aplica cuando la etiqueta falta.
| Etiqueta | ¿Obligatoria? | Valores posibles | Por defecto | Para qué sirve |
|---|---|---|---|---|
| v | Sí, y en primer lugar | DMARC1 | Ninguno | Identifica el registro TXT como registro DMARC. Cualquier otra primera etiqueta lo invalida. |
| p | Sí | none, quarantine, reject | Ninguno | La política DMARC del dominio: qué deben hacer los receptores con el correo que falla. |
| sp | No | none, quarantine, reject | Igual que p | Política para los subdominios que no publican su propio registro DMARC. |
| rua | No, pero muy recomendable | Una o varias direcciones mailto: | Ninguno | Adónde enviar los informes agregados (resumen), normalmente una vez al día. |
| ruf | No | Una o varias direcciones mailto: | Ninguno | Adónde enviar los informes de fallo (forenses) sobre mensajes individuales. |
| pct | No | 0 a 100 | 100 | Porcentaje del correo que falla al que se aplica la política. Útil como rampa temporal. |
| adkim | No | r (relajada), s (estricta) | r | Modo de alineación DKIM: ¿debe el dominio de firma DKIM coincidir exactamente con el dominio From? |
| aspf | No | r (relajada), s (estricta) | r | Modo de alineación SPF: ¿debe el dominio de rebote (Return-Path) coincidir exactamente con el dominio From? |
| fo | No | 0, 1, d, s | 0 | Cuándo generar informes de fallo: 0 = fallan SPF y DKIM, 1 = falla uno de los dos, d = falla DKIM, s = falla SPF. |
| ri | No | Segundos | 86400 | Intervalo solicitado entre informes agregados (un día por defecto). |
| rf | No | afrf | afrf | Formato de los informes de fallo. Puedes omitirla. |
¿Qué hace cada política DMARC: none, quarantine o reject?
La política DMARC indica a los receptores cómo tratar el correo de tu dominio que falla DMARC. Solo afecta al correo que falla: los mensajes que pasan se entregan según el filtrado normal del receptor.
| Política | Qué pasa con el correo que falla | Cuándo usarla |
|---|---|---|
| p=none | Ningún cambio; el receptor solo informa | Las primeras semanas, mientras identificas tus remitentes |
| p=quarantine | Se trata como sospechoso, normalmente va a spam | Cuando los informes muestran que tu correo legítimo pasa |
| p=reject | Se rechaza durante la conversación SMTP | El objetivo final, cuando la cuarentena ha funcionado sin problemas |
Una política quarantine o reject es lo que realmente bloquea a quienes ponen tu dominio en la dirección From de su propio correo. Nuestro artículo sobre cómo prevenir el spoofing de correo electrónico explica los ataques y las demás defensas que acompañan a DMARC.
DMARC solo funciona si SPF y DKIM están configurados en cada servicio que envía en nombre de tu dominio. Descubre cómo funciona la autenticación de email con Mailpro™ y asegura primero esas bases.
¿Cómo funciona la alineación DMARC?
DMARC pasa cuando al menos una de dos comprobaciones tiene éxito y está alineada con el dominio From: SPF pasa y el dominio de rebote (Return-Path) coincide con el dominio From, o DKIM pasa y el dominio de firma (el valor d= de la firma) coincide con el dominio From. Pasar SPF o DKIM con el dominio de otro no basta.
Así funciona la alineación para un mensaje cuya dirección From visible es [email protected]:
- DKIM firmado con d=ejemplo.com: alineado en modo relajado y estricto.
- DKIM firmado con d=mail.ejemplo.com: alineado en modo relajado (mismo dominio organizativo), no alineado en modo estricto.
- DKIM firmado con d=plataforma-de-envio.net: DKIM puede pasar, pero no está alineado, así que no cuenta para DMARC.
- Return-Path en rebotes.ejemplo.com y SPF pasa: alineado en modo relajado, no en modo estricto.
Es la razón más habitual por la que un dominio falla DMARC aunque en las cabeceras «SPF y DKIM pasan»: pasan para el dominio del servicio de envío, no para el tuyo. La solución es configurar en cada servicio la firma DKIM con tu propio dominio, que es también la razón por la que las notificaciones de una tienda acaban en spam; nuestra guía sobre confirmaciones de pedido en correo no deseado muestra esa configuración para una tienda online.
Cómo añadir un registro DMARC a tu DNS
Para añadir un registro DMARC, crea un registro TXT en el host _dmarc de tu dominio desde el panel DNS de quien aloja tu DNS (registrador, empresa de hosting o proveedor DNS).
- Comprueba que todavía no existe un registro DMARC. Consulta los registros TXT de _dmarc.tudominio. Si ya hay uno, edítalo en lugar de añadir un segundo.
- Crea un buzón o alias para los informes, por ejemplo informes-dmarc@tudominio. Los informes llegan como archivos XML comprimidos adjuntos, así que una dirección dedicada evita que llenen la bandeja de nadie.
- Añade el registro TXT: host _dmarc, valor v=DMARC1; p=none; rua=mailto:informes-dmarc@tudominio.
- Guarda y espera la propagación DNS, normalmente de minutos a unas horas según el TTL.
- Vuelve a consultar el registro para confirmar que devuelve un único valor que empieza por v=DMARC1.
Si envías con Mailpro, nuestra FAQ paso a paso sobre cómo configurar DMARC con Mailpro cubre la parte de la cuenta.
Cómo pasar de p=none a p=reject, paso a paso
Pasar de p=none a p=reject con seguridad significa demostrar, con informes, que cada fuente legítima de tu correo pasa DMARC antes de pedir a los receptores que bloqueen lo que falla. Los plazos de abajo son un ejemplo de despliegue prudente para un dominio con varios servicios de envío; un dominio pequeño con un solo remitente puede ir más rápido, y una gran organización, más despacio.
- Semanas 1 a 4: publica p=none con rua. Deja que se acumulen informes durante al menos un ciclo de actividad completo, para que aparezcan las facturas mensuales, las newsletters y los correos de sistema poco frecuentes.
- Haz la lista de todos los remitentes. Agrupa las filas de los informes por origen y asocia cada una a un servicio: tu proveedor de correo, tu plataforma de newsletters, tu tienda, tu CRM, tu herramienta de soporte, tu software de facturación, impresoras y escáneres que envían correo.
- Corrige cada remitente legítimo. Añádelo a SPF si usa tu Return-Path y configura la firma DKIM con tu propio dominio. Espera nuevos informes para confirmar que ahora pasa con alineación.
- Pasa a p=quarantine; pct=25. Vigila los informes y el buzón de soporte durante una o dos semanas. Después sube pct a 50 y luego a 100 (o elimina pct, ya que 100 es el valor por defecto).
- Pasa a p=reject; pct=25 y sube de la misma forma. Con pct por debajo de 100 en una política reject, la RFC 7489 indica que el resto del correo que falla va a cuarentena.
- Quédate en p=reject y sigue leyendo los informes. Cada nueva herramienta que envíe en nombre de tu dominio necesita SPF y DKIM antes de ponerse en marcha, o su correo será rechazado.
Algunos proveedores de buzones ya esperan un registro DMARC de los remitentes masivos. Nuestro artículo sobre las nuevas reglas de Gmail y Yahoo explica qué papel tiene DMARC en esas reglas.
Cómo leer los informes agregados DMARC
Los informes agregados DMARC son archivos XML, normalmente comprimidos en zip o gzip, que un receptor envía a tu dirección rua para resumir todo el correo que ha visto de tu dominio durante un periodo, normalmente un día. Cada informe enumera las direcciones IP de envío con el número de mensajes y sus resultados SPF, DKIM y DMARC. Puedes abrirlos con un editor de texto, pero una herramienta de informes que los procese y los convierta en gráficos es mucho más rápida en cuanto crece el volumen.
| Campo del informe | Qué te dice |
|---|---|
| report_metadata (org_name, date_range) | Qué receptor envió el informe y qué periodo cubre |
| policy_published | El registro DMARC que el receptor encontró para tu dominio (una forma rápida de detectar una errata) |
| source_ip | El servidor que envió los mensajes |
| count | Cuántos mensajes llegaron desde esa IP con ese resultado |
| disposition | Qué hizo el receptor: none, quarantine o reject |
| policy_evaluated: dkim, spf | Si DKIM y SPF pasaron con alineación, que es lo que usa DMARC |
| header_from | El dominio de la dirección From visible |
| auth_results | Los resultados SPF y DKIM en bruto, incluido el dominio con el que se comprobaron |
Al revisar un informe, clasifica cada fila en uno de estos cuatro casos:
- Servicio conocido, DMARC pasa: no hay nada que hacer.
- Servicio conocido, DKIM pasa pero sin alinear: el servicio firma con su propio dominio. Configura DKIM con tu dominio en ese servicio.
- Servicio conocido, SPF falla: falta el servicio en tu registro SPF, o usa su propio Return-Path (en ese caso, apóyate en DKIM alineado).
- IP desconocida, todo falla: o bien un sistema interno olvidado (búscalo), o alguien que envía correo en nombre de tu dominio, que es justo lo que quarantine y reject van a detener.
El correo reenviado o que pasa por una lista de distribución también puede aparecer como fallido, porque el reenvío suele romper SPF y el software de listas puede modificar el mensaje y romper DKIM. Una pequeña parte estable de fallos procedente de servidores de reenvío es normal y no es motivo para quedarse en p=none.
Errores frecuentes en el registro DMARC y cómo corregirlos
La mayoría de los problemas con DMARC vienen de unos pocos errores de registro y de despliegue:
- Dos registros DMARC en el mismo host. Según la RFC 7489, los receptores ignoran entonces DMARC para el dominio. Fusiónalos en un solo registro.
- v=DMARC1 no va primero o está mal escrito (DMARC 1, dmarc1 con un espacio, unas comillas al principio). El registro no se reconoce.
- Registro en el host equivocado. Algunos paneles DNS añaden el dominio automáticamente, así que escribir _dmarc.ejemplo.com crea _dmarc.ejemplo.com.ejemplo.com. En esos paneles, escribe solo _dmarc.
- rua sin mailto:, o direcciones separadas por punto y coma en lugar de comas. Los informes no llegan nunca.
- Dirección de informes en otro dominio sin autorización. Si ejemplo.com envía los informes a una dirección de informes.ejemplo.net, el dominio receptor debe publicar un registro TXT en ejemplo.com._report._dmarc.informes.ejemplo.net con el valor v=DMARC1; si no, los receptores no enviarán los informes.
- Saltar directamente a p=reject. Cualquier remitente olvidado, como la herramienta de facturación o el formulario de contacto de la web, verá su correo rechazado.
- Alineación estricta por defecto. adkim=s y aspf=s rompen los servicios que firman o gestionan rebotes desde un subdominio. La alineación relajada es la opción por defecto por algo.
- Quedarse en p=none para siempre. La supervisión por sí sola no impide que nadie use tu dominio. Planifica el paso a la aplicación desde el principio.
- Olvidar los subdominios. Sin sp, los subdominios heredan p, que suele ser lo que quieres, pero comprueba que cualquier subdominio que envíe correo aparece en tus informes antes de llegar a reject.
Cuando tu dominio está en quarantine o reject, cumples uno de los requisitos para mostrar tu logotipo junto a tus correos; consulta nuestra guía sobre BIMI para el resto. Para una definición breve que puedas compartir con tu equipo, mira la definición de DMARC en el glosario.
Preguntas frecuentes sobre el registro DMARC
¿Cuál es un buen ejemplo de registro DMARC para empezar?
Empieza con v=DMARC1; p=none; rua=mailto:informes-dmarc@tudominio, publicado como registro TXT en _dmarc.tudominio. No cambia nada en la entrega y pone en marcha los informes que necesitas antes de aplicar una política.
¿Qué significa «la política DMARC no está habilitada»?
«Política DMARC no habilitada» significa que tu dominio no tiene registro DMARC, o tiene uno en p=none, así que no se pide a los receptores que actúen sobre el correo que falla. Publicar un registro y pasar a quarantine o reject lo resuelve; nuestra FAQ sobre el aviso la política de DMARC no está habilitada explica el mensaje en detalle.
¿Es suficiente p=none?
p=none basta para recibir informes y tener un registro DMARC publicado, pero no protege tu dominio. Solo quarantine o reject piden a los receptores que detengan el correo que falla DMARC.
¿Necesitan los subdominios su propio registro DMARC?
No. Si un subdominio no tiene registro DMARC, los receptores usan el registro del dominio organizativo y aplican su valor sp, o p si no hay sp. Publica un registro _dmarc aparte en un subdominio solo cuando necesite una política distinta.
¿Cuánto tardan en llegar los informes DMARC?
Los informes agregados suelen enviarse una vez al día, porque el intervalo de informe por defecto del estándar DMARC es de 86 400 segundos. Cuenta con recibir los primeros uno o dos días después de publicar el registro, de los receptores que hayan visto correo de tu dominio.
Mailpro y la autenticación de email
Llega a p=reject con SPF y DKIM bien alineados
Un registro DMARC solo te protege cuando todos los mensajes que envías lo pasan. Mailpro está alojado en Suiza, cumple el RGPD desde su diseño y cobra por envíos, no por contactos, y nuestra guía de autenticación muestra cómo configurar SPF, DKIM y DMARC para tu dominio de envío.