DMARC: la política que une todo

Ya tienes SPF (quién puede enviar) y DKIM (la firma). Pero falta algo: ninguno de los dos le dice al receptor qué hacer si algo falla, y ninguno revisa el remitente que ve el usuario (From:). DMARC (Domain-based Message Authentication, Reporting and Conformance) cierra el círculo: conecta SPF y DKIM con el From:, publica tu política (no hacer nada, mandar a spam o rechazar) y te envía reportes de quién está enviando correo con tu dominio.

Desde 2024 Gmail y Yahoo lo exigen a quienes envían en volumen, y desde mayo de 2025 Microsoft también. En esta lección aprenderás cada etiqueta, la alineación (el concepto que más confunde), un plan seguro para pasar de none a reject sin perder correos y cómo leer los reportes.

Concepto

Analogía: el gerente del edificio

Seguimos con el portero (el servidor que recibe). Hasta ahora tenía dos herramientas:

• SPF: una lista de mensajeros autorizados... pero revisa el nombre escrito en el sobre, no el de la carta.
• DKIM: un sello de lacre... pero el sello puede ser de cualquier dominio, no necesariamente del que aparece en el From:.

Un estafador listo puede mandar una carta con From: ventas@mitienda.com, sobre de estafador.com (con SPF perfecto) y sello de estafador.com (con DKIM perfecto). SPF pasa, DKIM pasa... y el usuario ve mitienda.com.

DMARC es la instrucción del gerente de mitienda.com al portero: "Solo acepta cartas con mi nombre en el From: si el sobre o el sello también son míos y son válidos. Si no, haz esto (nada / spam / rechazar). Y cada día mándame un informe".

                 ¿El correo pasa DMARC?
                          │
     ┌────────────────────┴────────────────────┐
     ▼                                         ▼
 SPF = pass                                DKIM = pass
 Y dominio del sobre                       Y dominio d= de la firma
 ALINEADO con el From:                     ALINEADO con el From:
     │                                         │
     └──────────── basta con UNO ──────────────┘
                          │
               sí ────────┴──────── no
               ▼                    ▼
          ✅ DMARC pass        ❌ DMARC fail → aplica la política p=
                                              (none / quarantine / reject)

La alineación

"Alineado" significa que el dominio que pasó SPF o DKIM coincide con el dominio del From:. Hay dos modos:

Modo	Etiqueta	Regla	Ejemplo con From: ventas@mitienda.com
Relajado (por defecto)	adkim=r, aspf=r	Mismo dominio organizacional (subdominios valen)	d=mitienda.com ✅, d=news.mitienda.com ✅, d=sendgrid.net ❌
Estricto	adkim=s, aspf=s	Dominio idéntico	d=mitienda.com ✅, d=news.mitienda.com ❌

El "dominio organizacional" es el que registraste: mitienda.com para news.mitienda.com, o mitienda.com.mx para tienda.mitienda.com.mx.

Veamos casos reales:

Envío	SPF (sobre)	DKIM (d=)	¿DMARC pasa?
Google Workspace con DKIM activado	mitienda.com ✅ alineado	mitienda.com ✅ alineado	✅ Sí
Workspace sin activar DKIM propio	mitienda.com ✅ alineado	dominio de Google ❌	✅ Sí (por SPF), pero frágil: falla al reenviar
Mailchimp sin autenticar dominio	mcsv.net ❌	mcsv.net ❌	❌ No
Mailchimp con sus CNAME DKIM	mcsv.net ❌	mitienda.com ✅	✅ Sí (por DKIM)
SendGrid con Domain Authentication	em1234.mitienda.com ✅ (relajado)	mitienda.com ✅	✅ Sí
Formulario con mail() de PHP en el hosting	servidor123.hosting.com ❌	sin firma ❌	❌ No

La regla de oro

Asegura DKIM alineado en cada servicio que envía por ti. SPF se rompe con reenvíos y muchas plataformas usan su propio sobre; DKIM con tu dominio es lo que hace pasar DMARC de forma confiable.

El registro DMARC

Vive en un TXT en el nombre _dmarc:

Type:    TXT
Name:    _dmarc
Content: v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com; fo=1

Todas las etiquetas

Etiqueta	Valores	Para qué	Por defecto
v	DMARC1	Versión. Debe ir primero	Obligatoria
p	none, quarantine, reject	Política para el dominio	Obligatoria
sp	none, quarantine, reject	Política para subdominios	Igual que p
pct	0–100	Porcentaje de correos que fallan a los que se aplica la política	100
rua	mailto:... (uno o varios separados por coma)	A dónde mandar reportes agregados (diarios)	Sin reportes
ruf	mailto:...	Reportes forenses (copia de cada fallo)	Sin reportes
adkim	r, s	Alineación DKIM relajada o estricta	r
aspf	r, s	Alineación SPF relajada o estricta	r
fo	0, 1, d, s	Cuándo generar reportes forenses (1 = si falla cualquiera)	0
ri	segundos	Intervalo de reportes (casi todos envían cada 24 h)	86400

Las tres políticas

Política	Qué pasa con el correo que falla DMARC	Para qué
p=none	Nada: se entrega normal (según los filtros habituales)	Monitorear: recibir reportes sin riesgo
p=quarantine	Va a la carpeta de spam	Proteger con margen de error
p=reject	Se rechaza: ni siquiera llega	Protección máxima contra suplantación

pct y el futuro estándar

pct permite aplicar la política solo a una parte, por ejemplo p=quarantine; pct=25 (25 % de los fallos a spam, el resto se trata como none). La revisión del estándar (conocida como DMARCbis) propone reemplazar pct por una etiqueta de prueba t=. Hoy los grandes receptores siguen respetando pct; si algún día cambias, el panel o la herramienta que uses te lo indicará.

Reportes: rua y ruf

• rua (agregados): archivos XML (comprimidos en .zip o .gz) que Google, Microsoft, Yahoo y otros envían una vez al día: "Recibimos 1 240 correos con From de mitienda.com, desde estas IP, con estos resultados de SPF/DKIM". Son los importantes.
• ruf (forenses): copias de correos individuales que fallaron. Por privacidad, la mayoría de los grandes (Gmail incluido) no los envían. Puedes omitirlos.

Reportes a un dominio externo

Si pones rua=mailto:reportes@otro-servicio.com (un dominio distinto al tuyo), ese otro dominio debe publicar un registro que lo autorice (mitienda.com._report._dmarc.otro-servicio.com con v=DMARC1). Los servicios de reportes DMARC ya lo tienen configurado; solo importa si usas un buzón de otro dominio tuyo. Ejemplo: si mitienda.com manda reportes a dmarc@agencia.com, en la zona de agencia.com debe existir el TXT mitienda.com._report._dmarc con valor v=DMARC1.

Requisitos de Gmail, Yahoo y Microsoft

Requisito	Todos los remitentes (Gmail/Yahoo)	Remitentes masivos (más de 5 000 correos/día a esa plataforma)
SPF o DKIM	✅	—
SPF y DKIM	—	✅
DMARC publicado (mínimo p=none)	Recomendado	✅ Obligatorio
From: alineado con SPF o DKIM	—	✅
DNS inverso (PTR) válido en la IP que envía	✅	✅
Conexión con TLS	✅	✅
Tasa de spam reportada	Menos de 0.3 % (ideal menos de 0.1 %)	Igual
Baja con un clic (List-Unsubscribe + List-Unsubscribe-Post)	—	✅ en correo comercial, y procesar la baja en máximo 2 días

• Google y Yahoo anunciaron estos requisitos para febrero de 2024 y los fueron endureciendo a lo largo de 2024 y 2025 (de mandar a spam a rechazar correos que no cumplen).
• Microsoft (Outlook.com, Hotmail, Live) aplica desde el 5 de mayo de 2025 reglas equivalentes para quienes envían más de 5 000 correos al día: SPF, DKIM y DMARC (mínimo p=none) alineado.

Aunque tu cliente envíe 50 correos al día, cumple lo mismo: los filtros tratan mejor a quien está bien configurado.

Plan de implementación gradual

Nunca empieces con p=reject. Si hay un servicio que envía por el cliente y no conocías (el sistema de facturación, el CRM, la impresora de la oficina que manda escaneos), lo bloquearías. El plan seguro:

Semana 0      SPF correcto + DKIM activado en TODOS los servicios conocidos
                    │
Semanas 1–4   p=none; rua=mailto:...        ← solo observar
              Leer reportes: ¿quién envía con mi dominio? ¿todo pasa?
              Corregir cada fuente legítima que falle
                    │
Semanas 5–6   p=quarantine; pct=25          ← 25 % de los fallos a spam
                    │
Semanas 7–8   p=quarantine; pct=100         ← todos los fallos a spam
                    │
Semana 9+     p=reject                      ← los fallos se rechazan
              Seguir leyendo reportes cada mes

Los registros de cada etapa:

Etapa 1:  v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com; fo=1
Etapa 2:  v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@mitienda.com
Etapa 3:  v=DMARC1; p=quarantine; rua=mailto:dmarc@mitienda.com
Etapa 4:  v=DMARC1; p=reject; rua=mailto:dmarc@mitienda.com

Solo avanzas de etapa cuando los reportes muestran que todo el correo legítimo pasa DMARC (por SPF o DKIM alineado).

Subdominios que no envían

Una vez en reject, considera sp=reject (es el valor por defecto si no lo pones) para que nadie invente factura.mitienda.com. Si algún subdominio envía (por ejemplo news.mitienda.com), configúralo bien o dale su propio _dmarc.news.mitienda.com.

Paso a paso en Cloudflare

Opción A: crear el registro a mano

1. Crea un buzón o alias para los reportes, por ejemplo dmarc@mitienda.com (llegan muchos correos automáticos: no uses el buzón principal del cliente).
2. En Cloudflare: DNS → Records → Add record:

   Type:    TXT
   Name:    _dmarc
   Content: v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com; fo=1
   TTL:     Auto

3. Save y comprueba que ya es público:

Windows

nslookup -type=txt _dmarc.mitienda.com 1.1.1.1

Linux / macOS

dig +short _dmarc.mitienda.com TXT

Opción B: DMARC Management de Cloudflare (gratis)

Cloudflare tiene una función gratuita que recibe y resume los reportes por ti:

1. En el dominio, ve a Email → DMARC Management (el nombre puede variar; a veces aparece dentro de Email Security o Email).
2. Pulsa Enable DMARC Management. Cloudflare agrega a tu rua una dirección propia del tipo ...@dmarc-reports.cloudflare.net (si no tenías DMARC, crea el registro).
3. En 24–48 horas verás un panel con las fuentes que envían como mitienda.com, cuántos correos y si pasan SPF, DKIM y DMARC.

Puedes tener varios destinos en rua separados por coma:

v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com,mailto:abc123@dmarc-reports.cloudflare.net

Usa el generador

En Herramientas de dominios tienes un generador de DMARC para armar el registro sin errores de sintaxis, y el consultor DNS para revisar el DMARC actual de cualquier dominio.

Cómo leer los reportes

Un reporte agregado es un XML. Este es un fragmento simplificado de uno enviado por Google:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range><begin>1730505600</begin><end>1730591999</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>mitienda.com</domain><p>none</p><adkim>r</adkim><aspf>r</aspf>
  </policy_published>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>312</count>
      <policy_evaluated><disposition>none</disposition>
        <dkim>pass</dkim><spf>pass</spf></policy_evaluated>
    </row>
    <identifiers><header_from>mitienda.com</header_from></identifiers>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.77</source_ip>
      <count>45</count>
      <policy_evaluated><disposition>none</disposition>
        <dkim>fail</dkim><spf>fail</spf></policy_evaluated>
    </row>
    <identifiers><header_from>mitienda.com</header_from></identifiers>
  </record>
</feedback>

Cómo interpretarlo:

IP	Correos	DKIM	SPF	Diagnóstico
209.85.220.41	312	pass	pass	Servidores de Google: el correo de Workspace va perfecto
198.51.100.77	45	fail	fail	¿Quién es? Busca la IP (whois / búsqueda inversa). Si es un servicio del cliente (su CRM), configúrale DKIM. Si no la reconoces, es suplantación: reject la bloqueará

Leer XML a mano es tedioso. Usa una herramienta:

Herramienta	Qué ofrece gratis (puede cambiar)
Cloudflare DMARC Management	Panel integrado, gratis con tu zona
Postmark DMARC Digests	Resumen semanal por correo
dmarcian	Plan gratuito limitado (un dominio, volumen bajo)
EasyDMARC, URIports, Valimail Monitor	Planes gratuitos o de prueba con límites

Los planes gratuitos cambian

Las condiciones de los planes gratis cambian con frecuencia. Revisa la página de precios antes de recomendar una herramienta a un cliente.

BIMI: tu logo en la bandeja (introducción)

BIMI (Brand Indicators for Message Identification) muestra el logo de la marca junto al correo en Gmail, Yahoo, Apple Mail y otros. Es la "recompensa" por tener DMARC estricto.

Requisitos:

1. DMARC en p=quarantine (con pct=100) o p=reject.
2. El logo en formato SVG Tiny Portable/Secure (SVG Tiny PS), publicado por HTTPS.
3. Para Gmail y Apple, un certificado de marca: VMC (Verified Mark Certificate, requiere marca registrada) o CMC (Common Mark Certificate, más accesible). Cuestan dinero y los emiten autoridades como DigiCert o Entrust. Con VMC, Gmail muestra además una palomita azul.
4. Un TXT en default._bimi:

   Type:    TXT
   Name:    default._bimi
   Content: v=BIMI1; l=https://mitienda.com/bimi/logo.svg; a=https://mitienda.com/bimi/certificado.pem

Para la mayoría de los clientes pequeños, BIMI es opcional; primero asegura que DMARC esté en reject sin problemas.

Errores comunes

Error	Ejemplo	Consecuencia
Nombre equivocado	TXT en @ en vez de _dmarc	Nadie lo encuentra; como si no existiera
Dos registros DMARC	Dos TXT v=DMARC1 en _dmarc	Se ignora DMARC por completo
v=DMARC1 no va primero	p=none; v=DMARC1	Registro inválido
rua sin mailto:	rua=dmarc@mitienda.com	No llegan reportes
Saltar a reject el primer día	p=reject sin revisar reportes	Facturas y formularios rechazados
Quedarse en p=none para siempre	Años en monitoreo	Cumples el requisito mínimo, pero no proteges contra suplantación

Ejercicios

1. Escribe el DMARC inicial para mitienda.com con reportes a dmarc@mitienda.com y a Cloudflare (xyz@dmarc-reports.cloudflare.net).
2. Un correo tiene From: hola@mitienda.com, el sobre es bounce@mail.brevo.com (SPF pass) y la firma es d=mitienda.com (DKIM pass). ¿Pasa DMARC con alineación relajada? ¿Y con adkim=s?
3. Lo mismo, pero la firma es d=envios.mitienda.com. ¿Relajado? ¿Estricto?
4. Los reportes muestran 80 correos diarios desde la IP de un sistema de facturación del cliente, con SPF y DKIM en fail. ¿Qué haces antes de pasar a quarantine?
5. ¿Qué DMARC le pones a mitienda.net, que no envía correo?

Ver solución

1. Un solo TXT con dos destinos separados por coma:

   TXT _dmarc  v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com,mailto:xyz@dmarc-reports.cloudflare.net; fo=1

2. Sí en ambos casos: SPF pasa pero con brevo.com (no alineado); DKIM pasa con d=mitienda.com, idéntico al From:, alineado en modo relajado y estricto. Con uno alineado basta.
3. Relajado: sí (envios.mitienda.com y mitienda.com comparten dominio organizacional). Estricto (adkim=s): no por DKIM; solo pasaría si SPF estuviera alineado de forma estricta, y no lo está.
4. Configurar ese sistema para que envíe autenticado: lo ideal es que use un SMTP del dominio (Workspace, o un proveedor transaccional con DKIM de mitienda.com), o agregar su DKIM/SPF si el sistema lo permite. Esperar a que los reportes muestren pass antes de avanzar. Si no se puede, envía desde un subdominio propio con su propia configuración.
5. v=DMARC1; p=reject; en _dmarc.mitienda.net, junto con v=spf1 -all en la raíz.

Resumen

• DMARC conecta SPF y DKIM con el From: que ve el usuario. Pasa si SPF o DKIM pasan y están alineados.
• Alineación relajada (por defecto) acepta subdominios; estricta exige el dominio idéntico.
• Se publica en un TXT en _dmarc que empieza con v=DMARC1. Solo uno.
• Políticas: none (monitorear), quarantine (spam), reject (rechazar). Avanza gradualmente con pct y leyendo reportes rua.
• Gmail, Yahoo (2024) y Microsoft (mayo 2025) exigen SPF, DKIM y DMARC alineado a remitentes masivos.
• Usa una herramienta (Cloudflare DMARC Management es gratis) para leer los reportes.
• BIMI muestra tu logo, pero requiere DMARC quarantine/reject y, para Gmail, un certificado VMC o CMC.
• Siguiente: Otros registros: CAA, SRV, PTR, DNSSEC.