SPF y DKIM se ven completos en una auditoría superficial. Resuelven cosas distintas — SPF dice qué servidores pueden mandar email a nombre de tu dominio, DKIM firma el mensaje con clave criptográfica — y juntos parecen suficientes.
No lo son. Sin DMARC, un atacante puede mandar email desde cualquier servidor declarando que viene de tu dominio, y los mailbox providers no tienen instrucción clara de qué hacer con ese mensaje. Algunos lo dejan pasar a inbox, otros lo marcan como spam, otros lo bouncean — depende del provider, no de tu política.
DMARC cierra esa ambigüedad. Le dice a Google, Microsoft, Yahoo y al resto qué hacer cuando un mensaje falla SPF o DKIM, y te manda un reporte diario de qué pasó. Pero sólo si llegas a p=reject. Cualquier estado intermedio te da visibilidad sin protección efectiva.
El hueco que SPF y DKIM dejan abierto
Para que un mensaje pase SPF, el servidor que lo entregó debe estar listado en el TXT record v=spf1 ... de tu dominio. Para que pase DKIM, el header DKIM-Signature debe verificar contra la clave pública publicada en <selector>._domainkey.<dominio>.
Lo que ni SPF ni DKIM verifican por sí solos: que el From: que el destinatario ve coincida con el dominio cubierto por SPF/DKIM. Un atacante puede:
- Mandar email desde su propio servidor, con su propio SPF válido para su dominio.
- Firmar el mensaje con DKIM de su dominio.
- Poner como
From:[email protected].
SPF pasa — su servidor está autorizado para SU dominio. DKIM pasa — la firma valida contra SU clave pública. Y el destinatario ve un correo aparentemente de organizacion-ejemplo.cl que pasó todos los checks de autenticación.
DMARC resuelve esto con un concepto que se llama alineación: exige que el dominio del From: (lo que el usuario ve) sea el mismo, o un subdominio, del dominio cubierto por SPF/DKIM (lo que se verificó técnicamente).
Si la alineación falla, DMARC dispara la política que tú definiste.
Las tres políticas y cuál te protege de verdad
v=DMARC1; p=none; rua=mailto:[email protected]
v=DMARC1; p=quarantine; rua=mailto:[email protected]
v=DMARC1; p=reject; rua=mailto:[email protected]
Tres niveles, cada uno con un propósito distinto:
-
p=none— recibes los reportes, pero no le dices al provider que haga nada. Si llega un email fraudulento que falla DMARC, el provider lo procesa como siempre. Esta política no te protege. Sirve sólo como modo observación para mapear tu propio tráfico legítimo antes de subir. -
p=quarantine— el provider debería poner el mensaje en spam. “Debería” porque Gmail/Outlook todavía aplican su propio criterio: un quarantine para un dominio con buena reputación puede igual aterrizar en inbox. Mejor quenone, peor quereject. -
p=reject— el provider rechaza el mensaje en el SMTP, sin entregarlo. Es la única política que realmente cierra el spoofing.
La trampa común: organizaciones que llegan a p=none, ven los reportes, los archivan, y se quedan ahí por años pensando que están “implementando DMARC”. No. Hasta que no estés en p=reject, el spoofing sigue funcionando.
El camino seguro a p=reject
Saltar directo a p=reject es peligroso si tu organización manda email desde lugares que no controlas. SaaS de CRM, plataformas de newsletters, sistemas de facturación, ERPs en la nube — cada uno manda email diciendo ser tu dominio. Si no están alineados con tu SPF/DKIM, un p=reject los hace bounce silencioso.
El camino recomendado tiene cuatro etapas:
Etapa 1 — p=none con reportes activos
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100
Lo dejas 30 días. Durante esos 30 días recibes reportes XML diarios (uno por proveedor receptor: Google, Microsoft, Yahoo, etc.) listando todos los servidores que mandaron email a nombre de tu dominio.
Tu trabajo en esta etapa: identificar cada IP/host que aparezca y clasificarlo en “es legítimo” (tu sistema de email transaccional, tu CRM, tu plataforma de marketing) o “no lo reconozco” (spam, spoofing, ex-proveedor que no migraste).
Para cada sender legítimo no autorizado todavía: agrégalo a tu SPF o configura DKIM en ese servicio.
Etapa 2 — p=quarantine con pct gradual
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
pct=10 significa “aplica la política sólo al 10% de los mensajes que fallan; al resto sigue tratándolos como antes”. Es un canary deploy.
Lo subes gradualmente: 10 → 25 → 50 → 100 a lo largo de 2-4 semanas, verificando en cada paso que no aparezcan reportes de bounce de email legítimo.
Etapa 3 — p=quarantine; pct=100 estable
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Una o dos semanas en este estado. Sirve para detectar cualquier servicio que mande email muy esporádicamente — boletines mensuales, recordatorios trimestrales, encuestas anuales — que no apareció en las primeras 4-6 semanas de observación.
Etapa 4 — p=reject
v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s
Ahora el spoofing está cerrado. adkim=s y aspf=s activan modo strict de alineación: el dominio debe matchear exacto, no un subdominio. Para la mayoría de organizaciones strict alignment está bien, pero verifica los reportes 1-2 semanas más después del flip por si algún sender depende de relaxed.
Cómo se ven los reportes RUA
Los reportes llegan diariamente a la dirección que pusiste en rua=. Cada provider receptor agrega los mensajes que recibió de tu dominio en un XML comprimido. Estructura típica:
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<date_range>
<begin>1715558400</begin>
<end>1715644800</end>
</date_range>
</report_metadata>
<policy_published>
<domain>organizacion-ejemplo.cl</domain>
<p>reject</p>
</policy_published>
<record>
<row>
<source_ip>185.211.x.x</source_ip>
<count>3</count>
<policy_evaluated>
<disposition>reject</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>organizacion-ejemplo.cl</header_from>
</identifiers>
</record>
</feedback>
Procesar esto a mano es inviable cuando el volumen sube. Hay servicios SaaS que parsean los XML y te dan un dashboard (Postmark, dmarcian, Valimail). Para PYMEs el flujo “buzón dedicado + revisión semanal” alcanza durante los primeros meses.
Configuración del TXT
DMARC vive en un subdomain reservado: _dmarc.<tu-dominio>. En la zona DNS:
_dmarc.organizacion-ejemplo.cl. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s"
Parámetros que vale la pena considerar:
pct=(porcentaje) — útil sólo durante el ramp dequarantine. Enrejectfinal, omítelo (default es 100).adkim=s/aspf=s— modo strict. La alternativar(relaxed) permite quemail.organizacion-ejemplo.claparezca como dominio firmante para emails conFrom: @organizacion-ejemplo.cl. Strict es más seguro; relaxed es más tolerante a subdomains organizacionales.sp=— política específica para subdomains. Si lo omites, heredap=. Útil cuando tienes subdomains que no mandan email (la mayoría) — explicitarsp=rejectcierra el spoofing decualquier-cosa.organizacion-ejemplo.cl.fo=1— forensic options.fo=1dispara reporte cuando cualquier mecanismo falla (no sólo cuando ambos fallan). Más verbose, útil en troubleshooting.
El caso del subdomain olvidado
Un escenario que rompe muchas implementaciones: tu DMARC en organizacion-ejemplo.cl con p=reject está perfecto, pero alguien manda phishing desde noresponder.organizacion-ejemplo.cl o notificaciones.organizacion-ejemplo.cl — un subdomain que la organización nunca usa para email.
Sin sp= explícito, el provider hereda p= del apex y rechaza. Pero si en algún momento alguien puso sp=none “para no romper nada”, o si los subdomains tienen su propio _dmarc.<sub> con política más laxa, el atacante encuentra el hueco.
Revisa siempre que la zona no tenga un _dmarc.<algo>.organizacion-ejemplo.cl rezagado con p=none.
Cómo verificas
# Política del apex
dig +short TXT _dmarc.organizacion-ejemplo.cl
# Política de un subdomain específico (raro pero posible)
dig +short TXT _dmarc.notificaciones.organizacion-ejemplo.cl
# Validador externo (sintaxis + preview de comportamiento)
# https://dmarcian.com/dmarc-inspector/?domain=organizacion-ejemplo.cl
Lo importante en la respuesta: el primer token debe ser v=DMARC1; exacto. Errores comunes:
"v=DMARC1, p=reject..."con coma en vez de punto y coma → registro inválido, equivale a no tenerlo.- Múltiples TXT records con
v=DMARC1en el mismo nombre → los providers tratan como inválido y caen al default (p=none). rua=apuntando a un dominio externo sin autorización en su zona (_report._dmarc) → los providers ignoran el reporte por anti-abuso. Si quieres recibir reportes en otro dominio, ese dominio debe publicar<tu-dominio>._report._dmarc.<otro-dominio>autorizándote.
Cómo lo detecta el FreeScan
El Asentic FreeScan distingue cuatro estados:
- DMARC ausente — Media. El dominio no tiene
_dmarcpublicado; el spoofing está abierto. - DMARC en
p=none— Media. Hay política, pero no protege. Lo más común en sitios que “implementaron DMARC hace años y lo dejaron así”. - DMARC en
p=quarantine— Baja. Protección parcial; mejor que none, peor que reject. - DMARC en
p=rejectsinsp=— Info. La protección del apex está, pero los subdomains pueden estar expuestos según herencia.
La distinción importa porque “tiene DMARC” en una auditoría no técnica oculta que el 70% del tiempo está en p=none y no protege nada.
Cierre
Llegar a p=reject toma 6-8 semanas si tu inventario de senders está claro, 3-6 meses si la organización tiene marketing automation, CRM, ERP y notificaciones transaccionales repartidas en múltiples SaaS.
Pero el día que estás en p=reject, el costo marginal para un atacante de mandar phishing con tu nombre sube de “trivial” a “imposible sin comprometer un servidor autorizado”. Para la mayoría de empresas chilenas mid-market, esa diferencia vale el esfuerzo del ramp.
Si tu dominio todavía está en p=none, ya tienes la mitad del trabajo hecho — el TXT publicado y los reportes llegando. Falta la parte que importa: subirlo.