Entregabilidad de correo: la política DMARC que evita la suplantación sin perder correo

La política DMARC única (y por qué funciona)

Si quieres protección contra la suplantación sin perder correo legítimo, no empiezas con “p=reject” y buenas vibras. Empiezas con una política que
obliga a que la autenticación sea real, medible y aplicable—mientras te da una vía de escape para las partes feas del correo (reenvíos,
listas de distribución rotas, remitentes de terceros y sistemas legacy que creen que “DKIM” es un nuevo festival musical).

La política

El valor por defecto práctico que recomiendo para la mayoría de organizaciones que envían correo real y tienen al menos un remitente tercero:
DMARC en el dominio organizacional con p=quarantine, pct=100, alineamiento DKIM estricto (adkim=s), alineamiento SPF relajado (aspf=r) y una configuración razonable de informes.
Luego pasas a p=reject una vez que tus flujos autenticados estén limpios.

Un registro representativo (ajústalo a tu dominio y buzón de informes):

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=r; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; fo=1; sp=quarantine"

¿Por qué esta forma específica?

• p=quarantine at pct=100: estás aplicando la política, pero de una manera que normalmente reenvía los fallos a spam en lugar de descartarlos rotundamente.
  Eso mantiene el correo de negocio fluyendo mientras limpias remitentes. No estás “monitoreando”; estás cambiando resultados.
• adkim=s (alineamiento DKIM estricto): DKIM es la ruta más fiable a través de reenvíos y la moderna infraestructura de correo.
  El alineamiento estricto obliga a que tus proveedores y sistemas firmen usando tu dominio (o una estrategia de subdominios alineados correctamente).
• aspf=r (alineamiento SPF relajado): SPF falla constantemente debido a reenvíos y relays con NAT. SPF relajado te salva de
  castigar flujos legítimos mientras migras el mundo a una autenticación centrada en DKIM.
• sp=quarantine: no olvides los subdominios. Los atacantes no lo hacen.
• rua/ruf/fo: necesitas telemetría. No telemetría perfecta, pero suficiente para identificar qué sistemas fallan y por qué.

La conclusión: DMARC no es “SPF y DKIM existen.” DMARC es “SPF o DKIM pasan Y se alinean con el dominio que ve el usuario.”
Esa cláusula de alineamiento es donde la suplantación muere y donde la entregabilidad puede morir accidentalmente también.

Una cita que sigue vigente en operaciones: idea parafraseada de Werner Vogels: “Todo falla, todo el tiempo; diseña y opera asumiendo eso.”
Las implementaciones de DMARC fallan de maneras aburridas. Planea para eso, y no lo aprenderás de la forma cara.

Broma #1: La autenticación de correo es el único sistema de seguridad donde “reenvío” cuenta como “manipulación”, pero aun así todo el mundo lo hace.

Cuándo deberías ir directo a p=reject

Raro, pero existe. Si tu dominio no se usa para ningún correo legítimo (un dominio aparcado, o un dominio de marca que solo redirige a
un dominio de correo separado), entonces ve directo a:

cr0x@server:~$ dig +short TXT _dmarc.brand-only.example
"v=DMARC1; p=reject; pct=100; adkim=s; aspf=s; rua=mailto:dmarc-rua@brand-only.example; sp=reject"

Si no debería salir nada legítimo de él, sé implacable. De lo contrario, empezar por quarantine es la forma de mantener los correos de ingresos fuera de la tumba.

DMARC en términos de producción: qué le pasa realmente a un mensaje

DMARC es una política evaluada por el receptor (Gmail, Microsoft, Yahoo, el gateway de tu cliente). Lee tu registro DNS, comprueba los resultados de autenticación del mensaje y decide qué hacer.

Los tres dominios que importan (y por qué la gente se confunde)

• Header From: el dominio que los humanos ven en el encabezado From:. DMARC se alinea a este. Esta es la identidad que proteges.
• Dominio SPF: el dominio usado durante la evaluación SMTP MAIL FROM / Return-Path. A menudo es un dominio de rebote.
• Dominio d= de DKIM: el dominio que firma el mensaje.

DMARC pasa si (SPF pasa y se alinea) O (DKIM pasa y se alinea).
Luego los receptores aplican tu política: none, quarantine o reject.

Alineamiento: la parte en la que todos tropiezan

El alineamiento es una regla de comparación de cadenas, no un concepto filosófico.

• Alineamiento relajado (r): los subdominios alinean. mail.example.com se alinea con example.com.
• Alineamiento estricto (s): debe coincidir exactamente. mail.example.com no se alinea con example.com.

¿Por qué ser estricto en DKIM pero relajado en SPF en la política recomendada?
Porque DKIM es la identidad duradera. SPF es una comprobación de ruta IP; la ruta cambia. DKIM sobrevive cuando el mensaje toma la ruta panorámica.

Realidad de entregabilidad: los receptores no usan solo DMARC

DMARC es requisito básico. Los receptores también puntúan reputación, contenido, engagement, tasa de quejas y patrones de envío.
DMARC te hace elegible para confianza. No garantiza la colocación en bandeja de entrada. Lo que sí hace es evitar que atacantes tomen prestada tu
reputación de dominio para enviar basura. Eso, indirectamente, ayuda a tu correo legítimo.

Si quieres detener la suplantación sin perder correo, trata DMARC como el despliegue de un sistema distribuido: observa, aplica gradualmente, valida con
telemetría y luego endurece.

Hechos interesantes y contexto histórico (lo que explica las rarezas)

• DMARC surgió porque SPF y DKIM resolvían mitades diferentes del problema. SPF autentica una ruta de envío; DKIM autentica un mensaje. Ninguno por sí solo protege de forma fiable el dominio visible en From.
• SPF precede al correo en la nube generalizado. Fue diseñado cuando “el servidor que envía tu correo” era un concepto más estable que hoy.
• DKIM se diseñó para sobrevivir al reenvío. Firma el cuerpo del mensaje y cabeceras seleccionadas, por lo que puede pasar incluso cuando cambia la ruta SMTP—a menos que un reenviador reescriba contenido.
• DMARC está impulsado por el receptor. Tú publicas la política; los destinatarios deciden la aplicación. Por eso “pusimos p=reject” no significa que todos rechacen de la misma manera.
• DMARC popularizó la generación de informes por dominio a escala. Los informes agregados (RUA) se convirtieron en la primera forma consistente para muchas organizaciones de inventariar remitentes en la sombra.
• La política de subdominios (sp=) existe porque a los atacantes les encantan los subdominios. Las organizaciones los olvidan; los phishers no.
• Las primeras implementaciones de DMARC se apoyaron en quarantine. Las organizaciones aprendieron que ir directo a reject suele romper flujos legítimos de marketing y tickets.
• ARC existe en gran parte por los efectos secundarios de DMARC. Los reenvíos y las listas de distribución pueden romper DMARC; ARC ayuda a preservar el contexto de autenticación entre saltos.
• “p=none” no es inofensivo. Es un modo de monitoreo, pero también indica a los receptores que no estás aplicando. Eso puede afectar la seriedad con que tratan los intentos de suplantación.

Mini-historia #1: la suposición equivocada que rompió el envío

Una empresa SaaS de tamaño medio decidió “terminar el proyecto DMARC” antes de su auditoría anual de cumplimiento. Tenían SPF, tenían DKIM (en algún lugar),
y tenían una hoja de cálculo con proveedores. Alguien asumió que eso era suficiente.

Cambiaron DMARC de p=none a p=reject en el dominio apex un viernes por la noche. El lunes por la mañana, el equipo de éxito del cliente no podía enviar documentos de incorporación.
Los comerciales se quejaron de que los prospectos “dejaron de responder”. Finanzas dijo que las facturas rebotaban. Los tickets de soporte se acumularon con capturas de pantalla de
“mensaje rechazado debido a la política DMARC”.

El problema real fue aburrido: su CRM enviaba correo usando un Return-Path propiedad del proveedor (SPF pasaba, pero no se alineaba), y la firma DKIM
usaba d=vendor.example (DKIM pasaba, no se alineaba). En p=none a nadie le importaba. En p=reject, los receptores sí lo hicieron.

La solución no fue heroica. Configuraron al proveedor para que firmara con d=their-domain.example usando una clave DKIM personalizada, y establecieron un dominio de rebote dedicado
que se alineara. La lección clave: que la autenticación pase no es suficiente; debe alinearse con el dominio que pones en From.

También aprendieron a no desplegar aplicación sin una línea base reciente de informes. Los informes se habían enviado a un buzón desatendido.
La telemetría que nadie lee es arte performativo.

Mini-historia #2: una optimización que salió mal

Una gran compañía con múltiples unidades de negocio quiso reducir las consultas DNS de SPF debido al límite de 10 búsquedas. Un ingeniero propuso una
optimización: reemplazar una cadena de includes por un único include del proveedor, y endurecer SPF a un conjunto más pequeño de IPs “por seguridad”.

El cambio sí redujo las consultas. También provocó softfails y permerrors intermitentes de SPF para correo legítimo porque parte del correo se enrutaba a través de
relays regionales no incluidos en la lista “estricta”. Peor aún, las IPs de envío de la plataforma de marketing rotaban, y el include del proveedor en el que confiaban no era
el que realmente se usaba para el stream de la cuenta.

DMARC estaba en p=quarantine. Mensajes que antes pasaban por alineamiento SPF ahora fallaban SPF, y DKIM no estaba presente en ciertos flujos automáticos
debido a una app legacy que enviaba a través de un relay interno que eliminaba cabeceras y no firmaba.

La entregabilidad no colapsó de inmediato. Se degradó de esa manera lenta e insultante: algunos destinatarios recibían, otros no, y los patrones
parecían aleatorios. La respuesta a incidentes perdió tiempo porque no se reproducía consistentemente.

La resolución fue dejar de tratar a SPF como la identidad primaria. Restablecieron SPF a una base estable y correcta y priorizaron la firma DKIM en
cada stream saliente, usando dominios d= alineados. La optimización era real, pero aplicada en la capa equivocada. SPF debe ser preciso y
mínimo, no “ingenioso”.

Mini-historia #3: la práctica aburrida que salvó el día

Otra organización—poco llamativa, operativamente madura—tenía una práctica: cada sistema saliente tenía un responsable, un runbook y una revisión mensual de informes DMARC.
Nadie recibía ascensos por ello. Por eso funcionó.

Ejecutaron DMARC en p=quarantine durante meses mientras migraban proveedores. Cada vez que un nuevo remitente aparecía en informes RUA, se generaba un ticket:
identificar al responsable, validar el stream, configurar DKIM con d= alineado y confirmar el alineamiento SPF o documentar por qué no se confiaría en él.

Un día, una campaña de phishing atacó la industria, suplantando nombres de ejecutivos en varias compañías. Su dominio fue objetivo también. Los clientes vieron
los ataques en la naturaleza, pero los principales proveedores de bandejas rechazaron o marcaron como spam casi todo porque la aplicación de DMARC ya estaba en marcha.

Lo mejor: no tuvieron que improvisar. Ya tenían los controles configurados. Simplemente aumentaron la monitorización y comprobaron que ningún stream legítimo hubiera regresado.
Así es como luce lo “aburrido” cuando te paga el salario.

Broma #2: El sistema de correo más fiable es aquel que nadie nota—hasta que el CFO no puede enviar una hoja de cálculo y de repente es un “incidente prioritario”.

Guion de diagnóstico rápido

Cuando la entregabilidad o el control de suplantación falla, necesitas un camino rápido hacia el cuello de botella. Aquí está el orden que ahorra más tiempo en la mayoría
de incidentes.

Primero: confirma qué identidad de dominio se está protegiendo

• ¿Cuál es el dominio del Header From que ven los usuarios?
• ¿Es el dominio apex, un subdominio o un imitador?
• ¿Tienes un registro DMARC para ese dominio exacto (incluyendo el comportamiento de la política de subdominios)?

Segundo: comprueba la evaluación DMARC en una muestra real

• Captura un mensaje afectado (o envía una prueba a un buzón controlado) y lee Authentication-Results.
• Determina cuál de SPF o DKIM está pasando, y si se alinea.
• Si ninguno se alinea, DMARC fallará sin importar cuán “correcto” parezca SPF o DKIM de forma aislada.

Tercero: inventaría los remitentes mediante datos agregados DMARC

• ¿Qué IPs están enviando como tu dominio?
• ¿Qué fuentes fallan y en qué volumen?
• ¿Los fallos están concentrados en un proveedor, una región o una aplicación específica?

Cuarto: decide si el fallo está relacionado con aplicación o con reputación

• Si ves rebotes duros que citan DMARC, es aplicación/alineamiento.
• Si ves “aceptado pero en spam”, puede ser reputación, contenido o inconsistencia de autenticación (DKIM intermitente, permerror de SPF, etc.).

Quinto: haz un cambio a la vez

El correo es un sistema distribuido que no controlas por completo. Si cambias política DMARC, SPF, DKIM e infraestructura de envío al mismo tiempo, no aprenderás nada
y aun así romperás cosas.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas prácticas que puedes ejecutar desde un shell. Asumen que tienes herramientas DNS básicas y acceso a cabeceras de mensajes desde un buzón.
Para el análisis de cabeceras, pegarás contenido en archivos localmente. El objetivo no es la herramienta; es la toma de decisiones.

Tarea 1: Recuperar el registro DMARC y validar la sintaxis

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=r; rua=mailto:dmarc-rua@example.com; sp=quarantine"

Qué significa la salida: Tienes un registro DMARC, es DMARC1, y la aplicación de política es quarantine para el dominio y subdominios.

Decisión: Si no hay registro o hay múltiples registros conflictivos, arregla eso primero. DMARC es territorio de “un registro TXT”.

Tarea 2: Confirmar que no tienes múltiples registros TXT DMARC (una clásica trampa)

cr0x@server:~$ dig TXT _dmarc.example.com +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=r; rua=mailto:dmarc-rua@example.com; sp=quarantine"

Qué significa la salida: Exactamente un registro devuelto en la sección answer.

Decisión: Si ves dos respuestas TXT, consolida en una. Algunos receptores eligen una arbitrariamente, que es el equivalente por correo de jugar a la ruleta con la nómina.

Tarea 3: Revisar el registro SPF y detectar el problema de 10 búsquedas DNS

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:mailgun.org include:spf.protection.outlook.com include:spf.vendor.example -all"

Qué significa la salida: SPF usa múltiples includes; cada include puede desencadenar consultas DNS adicionales.

Decisión: Si sospechas límites de búsqueda, simplifica SPF o mueve flujos a DKIM-primero. No “optimices” SPF quitando remitentes legítimos.

Tarea 4: Inspeccionar la presencia del selector DKIM para un remitente conocido

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtY..."

Qué significa la salida: El selector s1 existe y tiene una clave pública.

Decisión: Si el selector falta o está truncado, arregla la publicación DNS antes de tocar la política DMARC.

Tarea 5: Enviar un mensaje de prueba y verificar la cabecera Authentication-Results (desde un archivo de cabecera guardado)

cr0x@server:~$ grep -i "^Authentication-Results:" -A2 message.eml
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=Qd9...
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com

Qué significa la salida: DKIM y SPF pasan. DKIM firma como example.com.

Decisión: Este stream debería pasar DMARC asumiendo que Header From es example.com y los ajustes de alineamiento lo permiten.

Tarea 6: Comprobar el resultado DMARC en las cabeceras (el receptor te lo dice)

cr0x@server:~$ grep -i "^Authentication-Results:" -A5 message.eml | grep -i dmarc
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Qué significa la salida: DMARC pasó y la política sería quarantine para fallos; la disposición NONE significa que no se aplicó acción de aplicación.

Decisión: Si DMARC falla aquí, deja de discutir si SPF “es correcto” y arregla el alineamiento o la firma DKIM.

Tarea 7: Detectar un fallo común: DKIM pasa pero no se alinea

cr0x@server:~$ grep -i "^Authentication-Results:" -A3 message.eml
Authentication-Results: mail.receiver.example;
       dkim=pass header.i=@vendor.example header.s=selector1 header.b=abc...
       spf=pass smtp.mailfrom=vendor-bounces.example

Qué significa la salida: DKIM pasa para vendor.example, SPF pasa para vendor-bounces.example. Si Header From es example.com, ninguno se alinea.

Decisión: Configura al proveedor para DKIM personalizado d=example.com (o una estrategia de subdominio alineado) y utiliza un dominio de rebote alineado cuando sea posible.

Tarea 8: Verificar las implicaciones de alineamiento relajado vs estricto

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; adkim=s; aspf=r"

Qué significa la salida: DKIM debe coincidir exactamente; SPF puede alinearse vía subdominio.

Decisión: Si tu correo legítimo está firmado como d=mail.example.com pero el From es example.com, DKIM estricto fallará el alineamiento. Firma con d=example.com o relaja adkim (no es mi favorito, pero a veces es pragmático).

Tarea 9: Confirmar MX y quién recibe realmente inbound (los objetivos de suplantación también son inbound)

cr0x@server:~$ dig +short MX example.com
10 mx1.mailhost.example.
20 mx2.mailhost.example.

Qué significa la salida: Estos son tus receptores inbound; ellos aplicarán políticas entrantes y proporcionarán cabeceras/logs.

Decisión: Si tu inbound está dividido entre proveedores, alinea expectativas de aplicación e investiga dónde se observan fallos.

Tarea 10: Comprobar si los subdominios están accidentalmente desprotegidos

cr0x@server:~$ dig +short TXT _dmarc.mail.example.com

Qué significa la salida: No hay un registro DMARC explícito en el subdominio.

Decisión: Si tu apex DMARC tiene sp=quarantine o sp=reject, los subdominios heredan. Si no, publica DMARC en subdominios de alto riesgo o establece sp= apropiadamente.

Tarea 11: Validar reverse DNS (no es DMARC, pero te arruinará el día)

cr0x@server:~$ dig +short -x 203.0.113.10
mailout.example.com.

Qué significa la salida: Existe PTR para la IP de envío, lo que ayuda reputación y aceptación.

Decisión: Si no hay PTR o apunta a algo sospechoso, arregla rDNS con tu ISP/proveedor cloud. DMARC no compensará una higiene de remitente deficiente.

Tarea 12: Comprobar que el nombre HELO/EHLO resuelve (otra vez, no DMARC, pero importante)

cr0x@server:~$ dig +short A mailout.example.com
203.0.113.10

Qué significa la salida: DNS directo coincide con el nombre usado por el servidor saliente.

Decisión: Si el nombre no resuelve o apunta a otro lado, arréglalo. Algunos receptores penalizan identidad SMTP descuidada.

Tarea 13: Detectar riesgo de permerror SPF listando includes (comprobación manual)

cr0x@server:~$ dig +short TXT _spf.google.com
"v=spf1 ip4:64.233.160.0/19 ip4:66.102.0.0/20 include:_netblocks.google.com ~all"

Qué significa la salida: Los includes pueden anidarse; tu registro SPF original puede exceder el límite de búsquedas según en qué se expandan esos includes.

Decisión: Si estás cerca del límite, reduce includes, mueve algunos flujos a subdominios dedicados con SPF separado, o confía más en el alineamiento DKIM.

Tarea 14: Verificar que la firma DKIM está presente en el mensaje

cr0x@server:~$ grep -i "^DKIM-Signature:" -m1 -n message.eml
42:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date:mime-version; bh=...; b=...

Qué significa la salida: El mensaje está firmado con d=example.com. Esta es la identidad a la que DMARC puede alinearse.

Decisión: Si la firma DKIM falta de forma intermitente, encuentra qué ruta del sistema la elimina (relays, gateways o apps).

Tarea 15: Confirmar que el buzón de informes DMARC existe y recibe correo

cr0x@server:~$ host -t MX example.com
example.com mail is handled by 10 mx1.mailhost.example.
example.com mail is handled by 20 mx2.mailhost.example.

Qué significa la salida: Tu dominio tiene MX operativos. Esto no prueba que el buzón exista, pero confirma el enrutamiento entrante.

Decisión: Si publicas rua hacia un buzón que no existe o que rechaza adjuntos grandes, quedarás ciego. Asegura que el buzón se monitorea y puede aceptar el volumen de informes.

Listas de verificación / plan paso a paso

Despliegue paso a paso que detiene la suplantación sin perder correo

1. Inventaria los remitentes legítimos.
   Usa el conocimiento existente (TI, marketing, facturación, soporte) y confirma con datos agregados DMARC una vez disponibles.
   Objetivo: una lista de sistemas que envían “From: @tudominio”.
2. Elige tu estrategia de dominio.
   Decide si:
   • Enviarás todo desde el dominio apex (más difícil), o
   • Usarás subdominios funcionales para terceros (recomendado): billing.example.com, news.example.com, support.example.com.

   Esto reduce el radio de impacto y hace el alineamiento más controlable.

3. Configura DKIM para cada remitente.
   Prioriza DKIM sobre SPF para fiabilidad a largo plazo. Requiere d= alineados.
4. Publica SPF correcto, no ingenioso.
   Mantenlo mínimo. Evita encadenar 9 includes y rezar. Usa subdominios para separar responsabilidades si hace falta.
5. Publica DMARC con p=none solo el tiempo suficiente para recopilar la línea base.
   Normalmente 1–2 semanas son suficientes si tu tráfico es normal.
6. Pasa a p=quarantine, pct=100.
   Aquí es donde la suplantación se vuelve significativamente más difícil y aún tienes margen de entregabilidad.
7. Arregla fallos de alineamiento.
   Usa informes y cabeceras para identificar qué remitentes fallan y por qué. Consigue que los proveedores soporten DKIM personalizado y dominios de rebote alineados.
8. Refuerza subdominios.
   Establece sp=quarantine o sp=reject. Publica registros DMARC explícitos para subdominios de alto riesgo si es necesario.
9. Avanza a p=reject.
   Solo cuando:
   • Tus streams legítimos de alto volumen pasen DMARC de forma consistente.
   • Entiendes los fallos restantes y los has aceptado conscientemente (o los moviste a subdominios con política separada).
10. Mantén vivo el ciclo aburrido.
    Revisión mensual de informes, responsabilidades y cambios de proveedor. Los ecosistemas de correo derivan. También las configuraciones de proveedores.

Lista operativa para “vamos a cambiar la política DMARC”

• ¿Tenemos un plan de reversión (TTL DNS, cadena de registro previa guardada, ventana de cambios)?
• ¿Conocemos la tasa de paso actual por flujo de remitente?
• ¿Los terceros de alto riesgo (marketing, CRM, ticketing) firman DKIM con d= alineado?
• ¿SPF está dentro de los límites de búsqueda y libre de permerrors?
• ¿Tenemos política de subdominios establecida (sp=)?
• ¿Tenemos un buzón monitorizado para RUA/RUF y una forma de procesar adjuntos XML?
• ¿Estamos preparados para casos límite de reenvíos (listas de distribución, reenvíos de exalumnos, clientes reenviando recibos)?

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “DMARC fail” pero SPF y DKIM ambos dicen “pass” en algún lugar

Causa raíz: Uno pasa para un dominio diferente. No hay alineamiento con Header From.

Solución: Asegura que DKIM firme con d= alineado al dominio From (preferir alineamiento exacto si tienes adkim=s). Usa un dominio de rebote personalizado para alineamiento SPF cuando sea posible.

2) Síntoma: Correos de marketing de repente van a spam después de mover a p=quarantine

Causa raíz: El proveedor firma con su propio dominio o usa un Return-Path no alineado; DMARC ahora falla y los receptores colocan en quarantine.

Solución: Configura DKIM personalizado del proveedor para tu dominio o envía desde un subdominio dedicado con su propia política DMARC y autenticación.

3) Síntoma: Algunos correos transaccionales pasan, otros fallan, desde el mismo “sistema”

Causa raíz: Múltiples rutas salientes: algunas firmadas, otras no; o algunas enrutadas por un relay que modifica contenido y rompe DKIM.

Solución: Traza la ruta y estandariza: firma en el borde después de cualquier reescritura, o asegura que los intermediarios no modifiquen las partes firmadas. Verifica con muestras de cada ruta.

4) Síntoma: Informes DMARC muestran muchas IPs desconocidas enviando como tu dominio

Causa raíz: Los intentos de suplantación son comunes, y p=none les permite “parecer” más legítimos ante algunos receptores. Además, puede haber remitentes de shadow IT.

Solución: Pasa a aplicación quarantine; investiga fuentes de alto volumen. Para remitentes desconocidos legítimos, asigna responsabilidad y configura DKIM/SPF alineados.

5) Síntoma: Los receptores dicen SPF “permerror” o “temperror”

Causa raíz: Límite de búsquedas SPF excedido, registro SPF malformado o timeouts DNS.

Solución: Reduce includes, aplana SPF responsablemente (sin romper propiedad), o segmenta por subdominio. Mejora la fiabilidad DNS.

6) Síntoma: Mensajes reenviados (clientes reenviando facturas) fallan DMARC y se ponen en quarantine

Causa raíz: SPF falla en reenvío (IP de envío diferente), y DKIM puede romperse si el reenviador reescribe contenido o modifica cabeceras.

Solución: Prioriza la robustez de DKIM (firma la forma final, evita reescritura de contenido). Considera soporte ARC si operas reenviadores; para reenvíos externos, acepta algo de pérdida y mitiga con entrega alternativa (portales, cuentas de cliente autenticadas).

7) Síntoma: La suplantación de subdominios continúa incluso después de asegurar el apex

Causa raíz: Falta la etiqueta sp= y no hay registros DMARC en subdominios.

Solución: Establece sp=quarantine o sp=reject en el registro DMARC del apex, y publica DMARC explícito para subdominios de alto valor.

8) Síntoma: Pusiste p=reject y ahora un socio dice que tus correos “desaparecen”

Causa raíz: Su gateway rechaza fallos DMARC; tu correo legítimo falla alineamiento debido a un proveedor o relay.

Solución: Mueve temporalmente a quarantine mientras remediás, o desplaza el stream que falla a un subdominio con una política menos estricta como medida interina. Luego arregla el alineamiento correctamente.

Preguntas frecuentes

1) ¿Es “p=none” inútil?

Es útil para descubrir remitentes, pero no detiene la suplantación. Trátalo como registro sin alertas: bien temporalmente, irresponsable para siempre.
Pasa a quarantine una vez que tengas una línea base y responsables asignados.

2) ¿Por qué no empezar con p=reject si la suplantación es crítica?

Porque tu correo legítimo probablemente tiene remitentes desconocidos y problemas de alineamiento. Reject convierte esos casos en fallos duros inmediatamente.
Quarantine es aplicación con una red de seguridad mientras limpias el parque.

3) ¿Debo confiar más en SPF o en DKIM para que DMARC pase?

Prefiere el alineamiento DKIM por durabilidad. SPF falla con reenvíos y ruteo complejo. Usa SPF como señal útil, no como identidad primaria.

4) ¿Qué significa “alineamiento” prácticamente para los proveedores?

Significa que el proveedor debe firmar con tu dominio en DKIM (DKIM personalizado), y idealmente usar un dominio de rebote/Return-Path que esté dentro de tu dominio
(return-path personalizado). Sin eso, DMARC fallará cuando el From sea tu dominio.

5) ¿Qué ajustes adkim y aspf debería elegir?

Un valor sólido por defecto es adkim=s y aspf=r durante el despliegue. Empuja a los proveedores a hacer DKIM correctamente sin penalizar demasiado la variación de ruta SPF.
Si tu entorno firma desde subdominios intencionalmente, ajusta adkim o cambia tu estrategia de dominio From.

6) ¿Necesito RUF (informes forenses)?

A veces. Muchos receptores limitan o redactan estos por privacidad, y el volumen puede ser caótico. Los informes RUA agregados son el caballo de batalla.
Si activas RUF, redirígelo a un buzón controlado y prepárate para manejar contenido sensible responsablemente.

7) ¿Qué pasa con las listas de distribución que modifican el asunto o añaden pies de página?

Pueden romper firmas DKIM al modificar contenido firmado. Si SPF también falla (común en reenvíos), DMARC falla.
Tus opciones: animar a los operadores de listas a preservar DKIM, confiar en ARC donde esté soportado, o aceptar que algunos flujos de listas no serán fiables bajo aplicación estricta.

8) ¿Cómo ayudan los subdominios a la entregabilidad y la seguridad?

Aíslan reputación y política. Sitúa marketing en news.example.com, transaccional en billing.example.com y deja el correo humano en el apex.
Luego ajusta DMARC por subdominio si es necesario mientras sigues protegiendo la marca.

9) Si DMARC pasa, ¿por qué los mensajes siguen yendo a spam?

Porque la autenticación no es reputación. Revisa la reputación de las IPs de envío, tasas de quejas, engagement, patrones de contenido y consistencia.
El pase DMARC es necesario; no es suficiente.

10) ¿Cuánto tarda en surtir efecto un cambio DMARC?

El TTL DNS gobierna la propagación, pero los receptores cachean y evalúan a su propio ritmo. Espera horas, no minutos.
Planifica cambios con reducciones de TTL por adelantado si necesitas una reversión más rápida.

Conclusión: próximos pasos que puedes entregar esta semana

La “política DMARC única” que realmente funciona en producción no es una cadena mágica; es una postura: aplica con quarantine al 100%,
exige alineamiento DKIM, mantiene SPF lo bastante relajado para evitar autolesiones y usa informes para cazar a cada remitente que se hace pasar por ti.

Haz esto ahora

1. Publica o verifica DMARC en el apex con p=quarantine; pct=100; adkim=s; aspf=r; sp=quarantine.
2. Ejecuta las tareas prácticas arriba para tus 3 principales streams salientes y confirma que DMARC pasa y que hay alineamiento en cabeceras reales.
3. Elige una estrategia de subdominios para terceros y empieza a mover al proveedor más problemático allí si no puede hacer DKIM alineado rápidamente.
4. Fija un recordatorio en el calendario: revisión mensual de informes DMARC con propietarios asignados. Así previenes regresiones.
5. Una vez que tus streams legítimos pasen consistentemente, cambia a p=reject con confianza, no con optimismo.

La suplantación se detiene cuando los receptores pueden decir de forma fiable qué es tuyo. La entregabilidad sobrevive cuando dejas de adivinar y empiezas a operar la identidad como un sistema:
con telemetría, responsabilidad y aplicación gradual.