Implantar DMARC: de none a reject
Módulo 4: Entregabilidad: SPF, DKIM y DMARC en la práctica · Tiempo de lectura: 12 minutos
Objetivo de aprendizaje: Después de esta lección podrá explicar cómo funciona la alineación, planificar una implantación de DMARC por fases de p=none a p=reject, elegir las etiquetas adecuadas (rua, sp, np, t) y anticipar los problemas habituales con la redirección y las listas de correo.
Conceptos clave: DMARC (RFC 9989), Author Domain (el dominio del campo Desde), alineación (alignment), relaxed y strict (adkim, aspf), dominio organizativo, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (modo de prueba), etiquetas obsoletas pct, rf, ri, listas de correo, reescritura del From, ARC
Qué comprueba exactamente DMARC
DMARC responde a una sola pregunta para cada correo entrante: ¿ha superado SPF o DKIM la comprobación para un dominio que esté alineado con la dirección del campo Desde? El dominio del campo Desde se denomina en el estándar Author Domain. Los fundamentos del registro se explican en el curso de DNS, lección 4.5. En mayo de 2026 se publicó el estándar revisado: RFC 9989, con RFC 9990 para los informes agregados y RFC 9991 para los informes de errores. Los registros existentes con v=DMARC1 siguen siendo válidos.
La alineación en la práctica
"Pertenecer a" se denomina alineación (alignment). Existen dos modalidades:
- relaxed (predeterminada): los dominios comparten el mismo dominio organizativo.
nieuws.example.comyexample.comestán alineados;example.comyexample.netno. - strict (
adkim=soaspf=s): los dominios deben coincidir exactamente.
Para SPF, DMARC compara el dominio del Return-Path con el dominio del campo Desde. Para DKIM, el dominio d= de una firma válida. Algunos ejemplos para un correo con Desde: info@example.com:
| Resultado SPF (Return-Path) | Resultado DKIM (d=) | DMARC |
|---|---|---|
pass para example.com | sin firma | pass (SPF alineado) |
pass para bounce.mailer.example | pass para mailer.example | fail (ambos superados, pero ninguno alineado) |
pass para bounce.mailer.example | pass para example.com | pass (DKIM alineado) |
| fail (redirigido) | pass para example.com | pass (DKIM sobrevive) |
pass para bounce.example.com | ninguno | pass con relaxed, fail con aspf=s |
Por tanto, deje adkim y aspf en relaxed, salvo que tenga un buen motivo para cambiarlo.
¿Cómo sabe un destinatario cuál es el dominio organizativo? Antes se usaba la Public Suffix List, una lista con dominios como .nl, .co.uk y github.io. RFC 9989 sustituye esto por un DNS tree walk: el destinatario busca registros _dmarc del dominio y de los dominios superiores. Para un usuario normal no cambia nada; solo lo notará si trabaja con registros en subdominios.
La implantación en cuatro fases
El objetivo es p=reject: así los destinatarios rechazan el correo que se hace pasar por usted, lo cual es la mejor protección contra facturas falsas y phishing en su nombre. Pero quien pasa directamente a reject sin conocer bien a sus remitentes, acabará rechazando sus propias facturas. Por eso se recomienda este orden (la línea de recomendación de este curso):
Fase 0: preparación
- Elabore el inventario de todos sus remitentes (lección 4.2).
- Asegúrese de que cada remitente tenga SPF o DKIM alineado; preferiblemente DKIM, ya que sobrevive a la redirección.
- Cree una dirección específica para los informes, por ejemplo
dmarc@example.com, o utilice un servicio de informes. Pronto recibirá varios informes al día.
Fase 1: medir con p=none
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"p=none no hace nada con el correo en sí. Los destinatarios entregan todo como siempre, pero le envían a diario un informe agregado (aggregate report) con cada servidor que envió correo en nombre de su dominio y si SPF, DKIM y DMARC se superaron. Con esto también cumple el requisito mínimo de Gmail, Yahoo y Microsoft para remitentes masivos (lección 5.3).
Mantenga esta configuración al menos de dos a cuatro semanas, y más tiempo si tiene servicios que envían correo solo de forma ocasional (un recordatorio anual, una factura trimestral). Lea los informes (lección 4.5) y repare cada fuente propia que falle.
Fase 2: p=quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"El correo que no supera DMARC va a la carpeta de spam del destinatario. Si aun así olvida alguna fuente, ese correo no se pierde, pero sí es difícil de encontrar. Si quiere ser prudente, añada primero t=y (modo de prueba): los destinatarios aplican entonces una política un paso más suave (en el caso de quarantine, equivaldría a none), pero usted verá en los informes qué ocurriría. Esta es, en RFC 9989, la sustituta de la antigua etiqueta pct=.
Observe de nuevo los informes durante algunas semanas.
Fase 3: p=reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"El correo que no supera DMARC es rechazado. El remitente recibe un bounce, por ejemplo con el código 5.7.509 en Microsoft y con una referencia a la política DMARC en Gmail (módulo 6). Siga revisando los informes: siempre aparecen nuevos servicios.
¿Cuándo se puede acelerar el proceso?
¿Todo su correo pasa por un único proveedor que gestiona SPF y DKIM por usted, y no se envía nada más en nombre de su dominio? Entonces puede aplicar una política estricta de inmediato. Por eso algunas empresas de hosting configuran p=reject de forma predeterminada. Si más adelante empieza a usar un servicio de boletines o un programa de contabilidad, vuelva primero temporalmente a p=none con una dirección de informes, hasta que ese servicio esté bien configurado.
Las demás etiquetas
| Etiqueta | Para qué sirve | Recomendación |
|---|---|---|
rua=mailto:... | Dirección(es) para los informes agregados, separadas por comas | Rellenar siempre durante la implantación |
ruf=mailto:... | Dirección para los informes de errores por correo (RFC 9991) | Casi ningún destinatario los envía, y pueden contener datos personales. Omitir en la mayoría de los casos |
sp= | Política para subdominios existentes | Omitir (se aplica entonces p=), a menos que los subdominios envíen correo de otra forma |
np= | Política para subdominios que no existen | np=reject es una buena adición en cuanto su política principal sea estricta: así nadie puede enviar correo desde factuur.example.com si ese nombre no existe |
adkim=, aspf= | Strict o relaxed | Dejar en relaxed |
t=y | Modo de prueba: un paso más suave | Útil en la transición a quarantine o reject |
fo= | Cuándo se generan los informes de errores | Solo tiene sentido junto con ruf |
pct=, rf=, ri= | Obsoletas en RFC 9989 | Ya no deben usarse; los destinatarios que siguen el nuevo estándar las ignoran |
Una dirección de informes en otro dominio (por ejemplo, un servicio de informes) solo funciona si ese dominio da su autorización mediante un registro como example.com._report._dmarc.rapportdienst.example. El servicio suele encargarse de esto él mismo (RFC 9990, capítulo 4).
Dificultades habituales
Listas de correo
Una lista de correo clásica reenvía su mensaje a todos los miembros desde su propio servidor, y a menudo añade [lista] al asunto o un pie de página. Esto hace que SPF falle (otro servidor) y DKIM también (el correo ha sido modificado). Con p=reject, los destinatarios rechazan su mensaje enviado a la lista. El software de listas moderno soluciona esto reescribiendo la dirección del campo Desde hacia la dirección de la lista ("Juan vía Miembros"), o reenviando el correo sin modificarlo. Si utiliza una lista que no hace esto, lo verá reflejado en sus informes.
Redirección
Véase la lección 3.3: SPF se rompe, DKIM suele sobrevivir. Un destinatario puede decidir, mediante ARC, confiar en un reenviador conocido. En los informes reconocerá esto como correo procedente de un servidor desconocido con DKIM pass y SPF fail; esto no es motivo para suavizar su política.
Dos registros o un error tipográfico
Dos registros DMARC en _dmarc invalidan la política, y un error tipográfico en p= también (p=rejected no existe). Compruebe el registro después de cada modificación.
En la práctica: así se ve en un panel
En un paquete de alojamiento de WebOké se configura de forma predeterminada v=DMARC1;p=reject, sin dirección de informes. Esto es seguro si todo su correo pasa por esos servidores. Si también envía correo a través de otros servicios, configúrelo como p=none con una dirección rua y vaya completando las fases. En DirectAdmin esto se hace en Administración de DNS con el lápiz situado junto al registro _dmarc (campos Tipo de política de dominio y Correo electrónico agregado (RUA)); en Mi WebOké, con el asistente de DMARC en la pestaña DNS. En otros proveedores, cree un registro TXT con el nombre _dmarc y escriba usted mismo el texto; el resultado es el mismo.
Resumen
- DMARC se supera si SPF o DKIM se supera para un dominio alineado con el dominio del campo Desde; la alineación relaxed acepta subdominios.
- Implantación: inventario,
p=noneconruay lectura de informes,p=quarantine(eventualmente cont=y), y despuésp=reject. - Use
np=rejectpara subdominios inexistentes en cuanto la política principal sea estricta.pct,rfyriestán obsoletas. - Las listas de correo y la redirección provocan fallos esperables; DKIM y ARC absorben parte de ellos.
- Exactamente un registro en
_dmarc, sin errores tipográficos.
Cuestionario
Ejercicio
Ejercicio Z4.4: Comprobar el DMARC de su dominio y elegir el siguiente paso. Introduzca su propio dominio (o internet.nl). Indique el registro DMARC tal como lo encontró, el valor de p= y si contiene una dirección rua. A continuación, elija qué fase de la implantación considera que es el siguiente paso, y por qué. El programa consulta el registro en tiempo real, comprueba la sintaxis según RFC 9989 (un único registro, p válido, etiquetas conocidas, etiquetas obsoletas como advertencia) y muestra sus respuestas junto al resultado.
Para saber más
Los pasos de estos artículos corresponden a los paneles de WebOké; en otros proveedores el funcionamiento es similar.
- Curso gratuito de DNS 4.5: DMARC: qué deben hacer los destinatarios con el correo falso
- Manual de DirectAdmin 5.9: Configurar DMARC
- ¿Qué es DMARC? Explicación en lenguaje sencillo
- Crear registro DMARC en DirectAdmin
- RFC 9989 (DMARC), en particular el apartado 4.7 (etiquetas) y el anexo C (cambios desde RFC 7489)