Alineación DMARC: qué es y cómo configurarla correctamente

Tu correo “pasa SPF” y “pasa DKIM”… y aun así DMARC falla, los mensajes van a la carpeta de spam o peor: desaparecen en un limbo silencioso del destinatario corporativo. Esto no es mala suerte. Es alineación.

La alineación DMARC es el portero que verifica identificaciones en la puerta. SPF y DKIM son tus credenciales. Si el nombre en la identificación no coincide con el nombre del ticket (From:), no entras—al menos no de forma consistente, y definitivamente no cuando activas p=quarantine o p=reject.

Alineación DMARC en términos sencillos (y por qué importa)

DMARC no trata principalmente de si SPF o DKIM “funcionan”. Trata de si la autenticación que obtuviste es para el dominio que ve el usuario. Ese dominio visible para el usuario es el que aparece en el encabezado RFC5322 From: (lo que los clientes de correo muestran como remitente).

Alineación significa: el dominio que autenticó mediante SPF y/o DKIM debe “coincidir” (según reglas estrictas o relajadas) con el dominio en From:. DMARC pasa cuando:

• SPF pasa y el dominio autenticado por SPF se alinea con From:, o
• DKIM pasa y el dominio de firma DKIM se alinea con From:.

La mayoría de las caídas y problemas de entrega ocurren porque alguien leyó “SPF pass” en un encabezado y dejó de pensar. Eso es como decir “el certificado SSL es válido” sin comprobar que fue emitido para tu nombre de host.

Qué no es alineación

• No es “¿pasó SPF?” (SPF puede pasar para un dominio de rebote no relacionado).
• No es “¿pasó DKIM?” (DKIM puede pasar para el dominio de un proveedor).
• No es “¿existe DMARC?” (publicar un registro DMARC no garantiza que tu correo esté alineado).

Por qué importa en producción

La alineación es cómo los receptores distinguen “correo legítimo de example.com” de “un servidor aleatorio que puede pasar SPF para mailer.vendor.com mientras falsifica From: example.com.” Sin alineación, SPF/DKIM son útiles pero no están vinculados de forma fiable a la identidad de la marca. Con alineación + aplicación, reduces verificablemente la suplantación y obtienes una señal más limpia para la bandeja de entrada.

Datos interesantes y breve historia

• DMARC surgió porque SPF y DKIM resolvían problemas distintos pero dejaban un hueco: ninguno exigía que el dominio autenticado coincidiera con el dominio visible del remitente.
• SPF comprueba la identidad “envelope-from” (Return-Path), no el From: visible por humanos. Esa discrepancia es la fuente original de muchos incidentes de “¡pero SPF pasó!”.
• DKIM inicialmente priorizó la integridad del mensaje y la responsabilidad a nivel de dominio, por eso las firmas DKIM sobreviven a muchos saltos, pero no a todas las modificaciones.
• DMARC formalizó bucles de retroalimentación a gran escala mediante informes agregados (RUA) para que los propietarios de dominio descubrieran emisores desconocidos y malas configuraciones.
• La alineación relajada existe porque Internet es desordenado: las organizaciones envían rutinariamente desde subdominios, y la coincidencia estricta bloquearía patrones legítimos.
• El reenvío rompió SPF mucho antes que DMARC; la opción de DMARC de “pasar vía DKIM alineado” ofrece una ruta viable cuando el reenvío cambia la IP emisora.
• La perilla “pct” de DMARC fue diseñada para despliegues graduales para que puedas aplicar la política sin convertir tu mesa de ayuda en una línea de consuelo emocional.
• ARC (Authenticated Received Chain) llegó después para ayudar a preservar resultados de autenticación a través de intermediarios—útil, pero no es excusa para ignorar la alineación.

Cómo funciona realmente la alineación (SPF vs DKIM)

Empieza con identidades: tres “from” que la gente confunde

El correo tiene múltiples identidades que parecen similares hasta que arruinan tu día:

• RFC5322.From: el From: visible. DMARC usa esto como referencia.
• RFC5321.MailFrom (envelope-from): usado para rebotes; aparece como Return-Path: tras la entrega. SPF autenticate este dominio.
• DKIM d=: el dominio firmante en la firma DKIM. DKIM autentica este dominio.

Condición de paso DMARC (versión operacional)

DMARC se fija en el dominio de From: y pregunta:

1. ¿SPF pasó para algún dominio MailFrom?
2. Si sí, ¿ese dominio MailFrom se alinea con el dominio de From:?
3. ¿DKIM pasó para alguna firma con d=?
4. Si sí, ¿ese d= se alinea con el dominio de From:?

Si pasa SPF alineado o pasa DKIM alineado, DMARC pasa. Si ninguno se alinea, DMARC falla, independientemente de otros sellos de “pass”.

Qué significa “alinear” en la práctica

La alineación compara dominios, no direcciones completas. DMARC normalmente evalúa el Dominio Organizacional (aproximadamente: dominio registrable) según la Public Suffix List.

Ejemplos:

• From: billing.example.com se alinea (relajado) con mail.example.com porque ambos comparten example.com como dominio organizacional.
• From: example.com no se alinea con mail.vendor.com. Ese es el objetivo.

Alineación SPF: por qué falla más a menudo

La alineación SPF usa el dominio en el envelope-from (MailFrom). Muchos emisores SaaS usan su propio dominio de rebotes como bounces.vendor.com. SPF puede pasar para eso, pero no se alineará con From: example.com. A menos que el proveedor soporte MailFrom personalizado / return-path personalizado / dominios de rebote con marca.

Además, SPF se evalúa contra la IP que se conecta. Los reenviadores cambian la IP que se conecta. SPF pierde la merienda detrás del gimnasio.

Alineación DKIM: generalmente la vía de trabajo

La alineación DKIM usa el dominio d= de DKIM. Si puedes firmar con d=example.com (o un subdominio alineado), puedes sobrevivir al reenvío y a muchos relés porque DKIM se basa en la firma sobre encabezados y cuerpo del mensaje, no en la IP emisora.

Pero DKIM es frágil de otra manera: si intermediarios reescriben el mensaje (pies de página, tags en el asunto, ajuste de líneas, cambios MIME), la firma puede romperse. No es teórico; es martes.

Una frase (idea para la canalización de correo)

Idea parafraseada: la esperanza no es una estrategia; usa telemetría y automatización para hacer las fallas visibles y recuperables. — atribuido a varios ingenieros de confiabilidad, popularizado en la cultura SRE

Alineación estricta vs relajada (aspf/adkim)

La alineación DMARC tiene dos perillas:

• aspf: modo de alineación SPF
• adkim: modo de alineación DKIM

Alineación relajada (r): qué permite realmente

Relajada significa que los subdominios están bien siempre que el dominio organizacional coincida. Entonces From: example.com se alinea con MailFrom: bounce.example.com y con DKIM d=mail.example.com (suponiendo que el dominio organizacional sea example.com).

Consejo opinado: empieza con alineación relajada a menos que tengas una razón sólida para ir a estricta. Estricto no es “más seguro” si empuja a los equipos a hacer trampas o hace que los proveedores sean imposibles de configurar correctamente.

Alineación estricta (s): cuando puedes permitir ser exigente

Estricta significa que los dominios deben coincidir exactamente. Si tu From: visible es example.com, entonces MailFrom de SPF debe ser example.com (no bounce.example.com) y DKIM d= debe ser example.com (no mail.example.com).

Estricto es viable si:

• tienes control estricto sobre todos los emisores salientes, y
• no dependes de un zoológico de plataformas SaaS, y
• estás dispuesto a construir procesos para mantenerlo así.

Broma #1: La alineación estricta es como un código de vestimenta en una startup: suena decisiva hasta que te das cuenta de que tu CEO lleva una sudadera con capucha con manchas de 2017.

Subdominios: alineación e herencia DMARC

La política DMARC publicada en _dmarc.example.com se aplica a example.com. Los subdominios pueden heredar a menos que publiques registros por subdominio, y puedes usar la etiqueta sp= para especificar la política para subdominios.

Operativamente, los subdominios son donde la “confusión de alineación” se convierte en “incidente de alineación.” Marketing quiere news.example.com, producto quiere notify.example.com, soporte usa support.example.com, y alguien en RR.HH. conecta un nuevo proveedor de encuestas que insiste en From: example.com porque “marca”. Así es como obtienes fallos DMARC a escala.

Cómo diseñar la alineación para emisores reales (personas, apps, SaaS)

Decide cuál será la estrategia de dominio en From:

Necesitas una política coherente sobre lo que aparece en From:. Elige uno de estos patrones y comprométete:

• Patrón A: un dominio para todo (From: example.com). Más simple para usuarios; más difícil para la alineación porque todos los emisores deben alinearse perfectamente.
• Patrón B: subdominios funcionales (billing.example.com, news.example.com). Separación más limpia y más fácil incorporación de proveedores. Los usuarios notan, pero también notan cuando tu correo falla.
• Patrón C: dominio de envío dedicado (mail.example.com) mientras mantienes el dominio corporativo example.com para personas. Muy recomendado en muchas organizaciones porque reduce el radio de impacto.

Mi inclinación: Patrón B o C. Si tu dominio es una cocina compartida, no guardes pollo crudo junto al pastel de cumpleaños.

Elige cómo DMARC debe pasar: “DKIM-primero” suele ser sensato

Para ecosistemas de envío modernos, trata la alineación DKIM como la vía principal para que DMARC pase. Configura SPF también, pero no asumas que sobrevivirá al reenvío, listas de correo y pasarelas “útiles”.

Lista de verificación para incorporación de proveedores (centrada en alineación)

Cuando una plataforma SaaS envía en tu nombre, necesitas estas capacidades:

• DKIM personalizado con d= en tu dominio (o subdominio alineado).
• MailFrom / return-path personalizado (opcional pero valioso) para obtener también alineación SPF.
• Soporte para múltiples selectores DKIM para rotación sin tiempo de inactividad.
• Documentación clara sobre reescritura de encabezados para que DKIM sobreviva.

Si no pueden hacer DKIM personalizado, no les permitas usar tu dominio principal en From:. Dales un subdominio o otra superficie de marca. DMARC es política. La política puede decir “no”.

Cómo interactúa la alineación con listas de correo y reenviadores

Las listas de correo a menudo modifican mensajes (añadiendo pies de página, prefijos en el asunto). Eso puede romper DKIM. Los reenviadores rompen SPF. DMARC queda en medio y dice: “tráeme autenticación alineada”.

Los receptores pueden usar ARC para preservar señales de autenticación upstream, pero no puedes confiar en ello. Tu palanca controlable es: hacer DKIM robusto (opciones de canonicalization, evitar manipulación de contenido cuando sea posible) y minimizar la dependencia de SPF para el pase DMARC.

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

Estas son las tareas que realmente ejecuto cuando depuro alineación en producción. Cada una incluye un comando, salida de ejemplo, qué significa y la decisión que tomas.

Tarea 1: Extraer el registro DMARC y comprobar etiquetas

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

Qué significa: DMARC existe, la aplicación es quarantine, ambas alineaciones relajadas, despliegue completo.

Decisión: Si sigues viendo fallos DMARC, el problema es alineación/autenticación, no “falta de registro”. Si p=none, estás en modo observación y deberías planear la aplicación.

Tarea 2: Comprobar DMARC para un subdominio que crees “cubierto”

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

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

Decisión: Confirma si dependes de la herencia y si sp= está establecido en el dominio organizacional. Si marketing envía desde news.example.com, probablemente quieras un registro explícito (o al menos una política sp= deliberada).

Tarea 3: Ver si SPF está presente para el dominio From (necesario pero no suficiente)

cr0x@server:~$ dig +short TXT example.com | sed -n 's/.*"\(v=spf1[^"]*\)".*/\1/p'
v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Qué significa: SPF autoriza una IP específica y el conjunto SPF de Google. La política SPF termina con -all (fail estricto).

Decisión: Si usas emisores SaaS, asegúrate de incluir sus rangos de envío (directamente o mediante include). Pero además: planifica la alineación SPF controlando MailFrom, no solo “SPF existe”.

Tarea 4: Contar búsquedas DNS SPF (modo de fallo oculto)

cr0x@server:~$ spfquery -debug -ip 203.0.113.10 -sender bounce@example.com -helo mx.example.com 2>&1 | tail -n 12
...
spfquery: using default zone: example.com
spfquery: found TXT record: v=spf1 ip4:203.0.113.10 include:_spf.google.com -all
spfquery: include:_spf.google.com
spfquery: result: pass

Qué significa: La evaluación SPF para ese remitente/IP pasa.

Decisión: Si ves errores por límite de búsquedas en encabezados reales (permerror), necesitas aplanar o simplificar SPF. Un “pass” en tu laboratorio no prueba nada si en producción hay más includes de los que probaste.

Tarea 5: Obtener registros TXT del selector DKIM (proveedor o interno)

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

Qué significa: La clave pública DKIM está publicada para el selector s1.

Decisión: Si DKIM falla en los receptores, confirma que el firmante usa este selector y dominio. Si un proveedor dice “firmamos”, verifica el real d= y s= en los encabezados.

Tarea 6: Inspeccionar un encabezado real para DMARC/SPF/DKIM y pistas de alineación

cr0x@server:~$ grep -E '^(From:|Return-Path:|Authentication-Results:|DKIM-Signature:)' -n sample.eml | sed -n '1,120p'
3:From: "Example Billing" <billing@example.com>
8:Return-Path: <bounce-123@mailer.vendor.com>
41:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailer.vendor.com; s=dkim1; ...
72:Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce-123@mailer.vendor.com designates 203.0.113.55 as permitted sender) smtp.mailfrom=bounce-123@mailer.vendor.com;
       dkim=pass header.i=@mailer.vendor.com header.s=dkim1 header.b=...;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Qué significa: SPF pasó para mailer.vendor.com y DKIM pasó para mailer.vendor.com, pero From: es example.com. Ninguno autentica example.com. DMARC falla por desalineación.

Decisión: Exige al proveedor soporte para DKIM personalizado (firmar con d=example.com o subdominio alineado) y preferiblemente MailFrom personalizado. Si no pueden, cambia el dominio visible From a un subdominio alineado que controles (p. ej., billing.example.com) y publica DMARC allí.

Tarea 7: Validar que DKIM se alinee con From (comparación de dominios)

cr0x@server:~$ python3 - <<'PY'
import re,sys
data=open("sample.eml","r",errors="ignore").read().splitlines()
from_dom=None
dkim_d=None
for line in data:
    if line.lower().startswith("from:"):
        m=re.search(r'@([A-Za-z0-9.-]+)', line)
        if m: from_dom=m.group(1).lower()
    if line.lower().startswith("dkim-signature:"):
        m=re.search(r'\bd=([A-Za-z0-9.-]+)', line)
        if m: dkim_d=m.group(1).lower()
print("from=",from_dom)
print("dkim d=",dkim_d)
PY
from= example.com
dkim d= mailer.vendor.com

Qué significa: No alineado ni en modo estricto ni relajado (dominios organizacionales distintos).

Decisión: Arregla el dominio de firma DKIM o mueve el dominio From para que coincida con lo que puede autenticarse.

Tarea 8: Comprobar que tu MTA esté firmando DKIM para el dominio correcto

cr0x@server:~$ sudo opendkim-testkey -d example.com -s s1 -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: key OK

Qué significa: El selector está presente y coincide con la clave privada configurada localmente (al menos según OpenDKIM).

Decisión: Si esto falla, arregla DNS o la ruta de la clave local antes de perseguir DMARC. Sin DKIM alineado, no hay pase DMARC fiable bajo reenvío.

Tarea 9: Confirmar qué Return-Path / MailFrom usa tu sistema saliente

cr0x@server:~$ postconf -n | grep -E '^(myhostname|mydomain|myorigin|smtp_mail_name|sender_canonical_maps|smtp_generic_maps)'
myhostname = mx1.example.com
mydomain = example.com
myorigin = $mydomain

Qué significa: Identidad básica de Postfix. Esto no garantiza alineación MailFrom, pero te dice los valores por defecto y si pueden existir mapas de reescritura.

Decisión: Si un relé o aplicación está estableciendo envelope-from de forma distinta, rastrealo. Alinear SPF a menudo significa controlar esta identidad de sobre, no solo DNS.

Tarea 10: Probar envío SMTP y capturar lo que el servidor añade

cr0x@server:~$ swaks --to you@recipient.test --from billing@example.com --server smtp.example.com --data <(printf 'Subject: test\n\nhello\n') --header "Date: $(date -R)"
=== Trying smtp.example.com:25...
=== Connected to smtp.example.com.
<** 250 2.0.0 Ok: queued as 9F2A8123

Qué significa: Mensaje aceptado para entrega.

Decisión: Extrae los encabezados del mensaje entregado en el lado del destinatario (o tu buzón de pruebas) y verifica el DKIM d=, SPF smtp.mailfrom y el resultado DMARC. “Encolado” no es “alineado”.

Tarea 11: Parsear Authentication-Results para identificar identificadores alineados rápidamente

cr0x@server:~$ awk 'BEGIN{RS="";FS="\n"} {for(i=1;i<=NF;i++) if($i ~ /^Authentication-Results:/) print $i}' sample.eml
Authentication-Results: mx.google.com;
       spf=pass ... smtp.mailfrom=bounce-123@mailer.vendor.com;
       dkim=pass header.i=@mailer.vendor.com ...;
       dmarc=fail ... header.from=example.com

Qué significa: Muestra las identidades que el receptor usó: smtp.mailfrom y header.i frente a header.from.

Decisión: Si smtp.mailfrom o header.i no pertenecen a tu familia de dominios, la alineación no puede pasar. Arregla el emisor, no el registro DMARC.

Tarea 12: Verificar la lógica de dominio organizacional (trampas de sufijo público)

cr0x@server:~$ python3 - <<'PY'
from publicsuffix2 import get_sld
tests=["example.com","billing.example.com","example.co.uk","a.b.example.co.uk"]
for t in tests:
    print(t,"->",get_sld(t))
PY
example.com -> example.com
billing.example.com -> example.com
example.co.uk -> example.co.uk
a.b.example.co.uk -> example.co.uk

Qué significa: La alineación relajada de DMARC compara dominios organizacionales, que difieren para sufijos como .co.uk.

Decisión: Si tu organización usa dominios con código de país, ten cuidado al asumir qué coincidirá en modo relajado. Tu DNS y configuraciones de proveedores deben ajustarse al límite real del dominio organizacional.

Tarea 13: Comprobar el comportamiento de sp= para subdominios

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

Qué significa: Dominio raíz es reject; los subdominios por defecto heredan quarantine a menos que se indique lo contrario.

Decisión: Si estás migrando emisores a subdominios para reducir riesgo, sp puede sorprenderte. Un DMARC explícito en el subdominio evita reuniones de “¿por qué marketing fue puesto en cuarentena?”.

Tarea 14: Confirmar que el dominio tiene MX válido y no está mal escrito (sí, pasa)

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

Qué significa: Existe enrutamiento de correo; no está directamente relacionado con alineación, pero es un indicador común de que el dominio está gestionado intencionalmente.

Decisión: Si no hay MX y estás enviando desde ese dominio, algunos receptores lo tratan con sospecha. Para un dominio solo de envío, quizá publiques MX o al menos mantengas higiene general.

Tarea 15: Buscar múltiples registros TXT DMARC (caos dependiente del receptor)

cr0x@server:~$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
"v=DMARC1; p=reject; rua=mailto:security@example.com"

Qué significa: Existen dos registros DMARC. Eso es inválido; los receptores pueden escoger uno, ignorar ambos o comportarse de manera inconsistente.

Decisión: Arregla DNS de inmediato: publica exactamente un registro DMARC por dominio. Esto es un problema de “detener la hemorragia” antes de un diagnóstico más profundo.

Guía rápida de diagnóstico

Si tienes 15 minutos antes de que alguien eleve “incidencia de correo”, no divagues. Comprueba esto en orden.

Primero: confirma que la falla es de alineación, no de autenticación básica

1. Captura un encabezado de un mensaje que falla desde un buzón receptor (preferiblemente Gmail o Microsoft, porque son verbosos).
2. Encuentra Authentication-Results y lee tres campos: header.from, smtp.mailfrom y header.i (identidad DKIM).
3. Si SPF/DKIM están “pass” pero las identidades no coinciden con header.from, es alineación.

Segundo: identifica qué vía debería ser tu camino de pase DMARC

• Si el correo es reenviado o pasa por intermediarios: prioriza la alineación DKIM.
• Si el correo va directo al destinatario con IPs estables y MailFrom controlado: la alineación SPF puede ser fiable.
• Si ambos fallan: o no estás firmando correctamente, o permites que proveedores envíen “como tú” sin controles de dominio.

Tercero: localiza quién envía el correo desalineado

• Revisa el dominio en Return-Path: a menudo revela al proveedor.
• Revisa el d= de DKIM: revela el dominio firmante.
• Compáralos con tu lista de emisores autorizados. Si no tienes lista, felicitaciones: descubriste por qué existen los informes DMARC.

Cuarto: elige la corrección de menor riesgo

• Mejor arreglo: configura DKIM personalizado para tu dominio en ese emisor.
• Siguiente mejor: mueve el From visible a un subdominio dedicado que el emisor pueda alinear y publica DMARC en ese subdominio.
• Evitar: relajar la política DMARC como solución permanente. Reducciones temporales de pct pueden ser razonables en respuesta a incidentes; degradaciones permanentes son cómo vuelve la suplantación.

Broma #2: Si “arreglaste DMARC” poniendo p=none, eso no es una solución; es poner una nota adhesiva en el detector de humo.

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

1) “SPF=pass, DKIM=pass, DMARC=fail”

Síntoma: Authentication-Results muestra SPF pass y DKIM pass, pero DMARC fail.

Causa raíz: SPF y DKIM autenticaron dominios distintos al From: visible. Típico con proveedores SaaS que usan su propio Return-Path y d=.

Arreglo: Habilita DKIM personalizado para tu dominio ( d= alineado). Opcionalmente configura MailFrom personalizado para también lograr alineación SPF.

2) DMARC falla solo para correo reenviado

Síntoma: Los destinatarios directos reciben en bandeja; los reenviados ven cuarentena/rechazo.

Causa raíz: Los reenviadores rompen SPF al cambiar la IP emisora; DKIM puede faltar o estar roto, quedando sin vía alineada.

Arreglo: Asegura que DKIM esté habilitado y sobreviva al tránsito típico. No confíes solo en alineación SPF para que DMARC pase si el reenvío es común.

3) DKIM pasa en tus pruebas, falla en producción

Síntoma: Algunos receptores muestran dkim=fail (bad signature), otros pasan.

Causa raíz: Intermediarios modifican el mensaje (pies de página, disclaimers, banners de “remitente externo”, conversiones MIME). O tu firmante incluye encabezados volátiles en el conjunto firmado.

Arreglo: Ajusta la configuración DKIM: elige canonicalization sensata, limita los encabezados firmados a los estables y elimina pasarelas que reescriben contenido tras la firma (o firma después de reescribir).

4) “Pusimos aspf=s y todo se rompió”

Síntoma: Aumentaron los fallos DMARC tras cambiar a alineación estricta.

Causa raíz: Tu MailFrom es un subdominio (p. ej., bounce.example.com) o el proveedor usa return-path en subdominio. Estricto requiere coincidencia exacta.

Arreglo: Usa alineación relajada (aspf=r) a menos que puedas garantizar MailFrom exacto en todas partes. O cambia el From visible al dominio exacto que coincide con la identidad autenticada.

5) Comportamiento DMARC aleatorio e inconsistente entre receptores

Síntoma: Gmail dice DMARC pass, Microsoft dice fail, proveedores pequeños varían.

Causa raíz: Múltiples registros TXT DMARC, inconsistencias de propagación DNS, o interpretaciones distintas por parte de receptores.

Arreglo: Asegura exactamente un registro TXT DMARC, valida DNS, reduce TTL durante cambios y vuelve a probar.

6) Correo de subdominio rechazado después de aplicar DMARC en raíz

Síntoma: El correo desde news.example.com empieza a fallar tras aplicar enforcement en example.com.

Causa raíz: El subdominio hereda la política y el emisor no está alineado para ese subdominio. O sp=reject se aplica.

Arreglo: Publica DMARC explícito para el subdominio y configura DKIM/SPF para ese subdominio; o ajusta sp deliberadamente.

7) DKIM se alinea pero DMARC sigue fallando

Síntoma: Ves dkim=pass con d=example.com, aun así DMARC falla.

Causa raíz: El pase DKIM puede corresponder a una firma que no se alinea (múltiples firmas), o el receptor seleccionó otro resultado DKIM como “mejor” (matiz de implementación), o el From visible usa un dominio distinto al esperado.

Arreglo: Inspecciona Authentication-Results con detalle para ver qué firma se evaluó y qué header.from hay. Asegura que la firma DKIM que alinea esté presente y válida en el receptor.

Listas de verificación / plan paso a paso

Plan de despliegue paso a paso que evita outages autoinfligidos

1. Inventario de emisores. Lista cada sistema que pueda enviar con tu dominio en From:: M365/Google Workspace, ticketing, alertas CI/CD, CRM, marketing, facturación, monitoreo, personas con clientes SMTP.
2. Elige una arquitectura de dominio From. Prefiere un dominio de envío dedicado o subdominios funcionales para aislar proveedores.
3. Habilita DKIM donde sea posible. Si un emisor no puede firmar con tu dominio, no le permitas usar tu dominio From raíz.
4. Publica SPF con cuidado. Mantén bajo el límite de búsquedas DNS; evita cadenas de includes incontroladas.
5. Publica DMARC con p=none primero. Añade rua para recoger informes agregados. Mantén alineación relajada a menos que estés seguro.
6. Revisa informes DMARC y corrige brechas de alineación. Aquí es donde encuentras al “emisor misterioso” que producto olvidó.
7. Mueve a p=quarantine con pct menor a 100 si hace falta. Usa pct como salvavidas, no como estilo de vida.
8. Pasa a p=reject cuando estés seguro. La suplantación deja de ser un problema de marca y se convierte en un problema del receptor.
9. Automatiza comprobaciones continuas. Expiración/rotación de claves DKIM, deriva DNS, cambios de proveedores y adquisiciones son donde la alineación regresa silenciosamente.

Lista operativa para cada nuevo emisor (ponla en procurement)

• ¿Cuál será el dominio visible en From:?
• ¿La plataforma firmará DKIM con d= en nuestro dominio (o subdominio alineado)?
• ¿Podemos establecer MailFrom / return-path personalizado en nuestro dominio para alineación SPF?
• ¿Qué selectores usan y podemos rotar las claves sin tiempo de inactividad?
• ¿Reescriben mensajes después de firmar (pies de página, tracking, modificación open/click)?
• ¿Soportan dominios separados por entorno (prod vs staging)?
• ¿Cómo probaremos antes del go-live (lista seed, captura de encabezados, validación DMARC)?

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición errónea

La compañía había migrado el correo transaccional a un proveedor nuevo y reluciente. El plan de migración fue ordenado: actualizar SPF para incluir al proveedor, activar DKIM “porque existe la casilla”, luego endurecer DMARC a p=reject tras una semana de calma.

En el día dos, soporte empezó a recibir tickets: restablecimientos de contraseña no llegaban para un grupo de usuarios—principalmente en proveedores de correo grandes con filtrado agresivo. Ingeniería hizo lo que hace: comprobó logs de la app, confirmó que los correos se encolaban, confirmó que la API del proveedor devolvía éxito. Así que “el correo está bien”.

Entonces alguien miró un encabezado real. SPF pasó. DKIM pasó. DMARC falló. El From: era example.com, pero el proveedor firmaba con d=vendor-mail.com y usaba Return-Path bajo vendor-bounce.com. El equipo había asumido “pass es pass”. DMARC no le importó.

La solución no fue heroica: configurar DKIM personalizado para example.com en el proveedor, y alinear el dominio de rebote bajo un subdominio controlado. La entregabilidad se recuperó. La victoria mayor fue cultural: el postmortem añadió una regla—no cambiar enforcement sin validar identidades de alineación en Authentication-Results en al menos dos grandes receptores.

Micro-historia 2: La optimización que salió mal

Otra organización quiso “limpiar DNS”. Su registro SPF se había convertido en un monstruo de includes porque cada departamento onboardeó proveedores como si recogieran chapas en una conferencia. Alguien propuso aplanar SPF expandiendo includes a una lista IP estática. Menos búsquedas DNS. Evaluación más rápida. Todos asintieron.

Desplegaron el registro aplanado y, por unos días, mejoró. Luego el correo empezó a fallar intermitentemente—especialmente de un proveedor cuyas IPs cambiaron sin avisar. SPF empezó a fallar para ese tráfico. DMARC también empezó a fallar porque habían confiado en la alineación SPF para ese emisor; DKIM no estaba alineado (el proveedor firmaba con su propio dominio y nadie peleó esa batalla).

La “optimización” reemplazó includes dinámicos (que se adaptan a cambios de IP) por una instantánea frágil. El modo de fallo no fue solo SPF fail. Cascó en comportamiento de enforcement DMARC, convirtiendo el cambio de IP de un proveedor en un incidente visible al cliente.

El diseño estable final fue más aburrido: restaurar el include del proveedor, eliminar includes obsoletos, dividir emisores en subdominios con DKIM explícito, y monitorizar cuentas de búsqueda SPF con tests en CI. La parte inteligente no fue el truco DNS. Fue diseñar la ruta de autenticación para que la deriva de IP de un solo proveedor no colapse DMARC.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo empresarial ejecutaba un trabajo semanal simple: enviar mensajes de prueba desde cada emisor autorizado a unos pocos buzones controlados, y luego almacenar los encabezados completos. Sin dashboards sofisticados al principio—solo archivos en un repo y la costumbre de mirar cuando algo cambiaba.

Una semana, las pruebas marcaron que el correo de marketing aún llegaba, pero la alineación DKIM había cambiado: el d= DKIM ahora era vendor.com en lugar de news.example.com. DMARC estaba pasando solo porque la alineación SPF seguía funcionando, y solo para destinatarios directos. Los reenviados habrían fallado la próxima vez que la pasarela corporativa empezara a enrutar por un nuevo salto.

Resultó que el proveedor había rotado infraestructura y “amablemente” revirtió una opción durante una migración interna. Todavía no había outage. Solo una pistola cargada sobre la mesa.

El equipo abrió un ticket, restauró DKIM personalizado y añadió una cláusula contractual: cambios que afecten identidades de envío deben ser anunciados. La corrección fue mundana. El salvamento fue enorme. Esto es lo que parece la “excelencia operativa” cuando nadie aplaude.

Preguntas frecuentes

1) Si SPF pasa, ¿por qué DMARC falla?

Porque SPF puede pasar para el dominio envelope-from, y DMARC exige que ese dominio se alinee con el From: visible. SPF pass sin alineación es común con emisores terceros.

2) ¿Debo confiar en la alineación SPF o DKIM?

Prefiere la alineación DKIM como vía principal de pase DMARC, especialmente si tu correo se reenvía, pasa por listas de correo o atraviesa múltiples relés. Mantén SPF correcto de todas formas; sigue siendo valioso.

3) ¿Qué cambian realmente “adkim” y “aspf”?

Establecen alineación estricta (s) o relajada (r) para DKIM y SPF. Relajada permite subdominios (mismo dominio organizacional). Estricta requiere coincidencia exacta.

4) ¿La alineación estricta siempre es más segura?

No. Estricta solo es mejor si puedes mantenerla sin excepciones. Si lo estricto obliga a los proveedores a usar tu dominio raíz en From mientras autentican con sus dominios, obtendrás fallos, no seguridad.

5) ¿Por qué DMARC se rompe cuando una lista añade un pie de página?

Porque las firmas DKIM cubren partes del cuerpo y encabezados. Si una lista modifica el cuerpo, DKIM puede fallar. Si SPF también falla por reenvío, DMARC falla.

6) ¿Puedo arreglar la alineación cambiando solo el registro DMARC?

Raramente. La política DMARC no crea alineación; la evalúa. La mayoría de las correcciones están en la configuración del emisor: dominio de firma DKIM, dominio MailFrom, o estrategia del dominio visible From.

7) ¿Cuál es la forma más segura de pasar a p=reject?

Funciona con p=none y recopilación de informes, arregla todos los emisores conocidos, luego pasa a p=quarantine con control pct si hace falta, y finalmente a p=reject. No te saltes la parte de “arreglar emisores”.

8) ¿Necesito return-path personalizado si ya tengo DKIM alineado?

No estrictamente, pero ayuda. Tener SPF y DKIM alineados hace tu correo más resistente ante matices de receptores e intermediarios.

9) ¿Cómo afectan los subdominios a la alineación?

Con alineación relajada, los subdominios se alinean si comparten el mismo dominio organizacional. Con alineación estricta, no. La política DMARC también puede aplicarse de forma distinta a subdominios vía sp o registros explícitos por subdominio.

10) ¿Cuál es la prueba más rápida de que un proveedor no puede cumplir la alineación DMARC?

Envía un correo de prueba e inspecciona encabezados: si DKIM d= y SPF smtp.mailfrom son dominios del proveedor e inmutables, no podrán alinearse con tu From: a menos que soporten identidades personalizadas.

Conclusión: próximas acciones que realmente reducen el riesgo

La alineación DMARC no es teoría abstracta de correo. Es la diferencia mecánica entre “autenticamos algo” y “los receptores pueden confiar en el dominio que ven nuestros usuarios”. Si aplicas DMARC sin disciplina de alineación, estás construyendo una máquina de rechazos y llamándola seguridad.

Haz esto a continuación, en orden:

1. Elige tu estrategia de dominio From (raíz vs subdominios vs dominio de envío dedicado). Hazlo una decisión de política, no una preferencia por equipo.
2. Haz de la alineación DKIM tu valor por defecto para cada emisor, especialmente proveedores.
3. Usa informes DMARC e inspección de encabezados como telemetría, no como papeleo.
4. Avanza hacia enforcement deliberadamente (none → quarantine → reject), usando pct como válvula de seguridad—no como muleta permanente.
5. Operationaliza esto: una prueba semanal con seed y almacenamiento de encabezados detecta la clase de regresiones “proveedor revirtió configuración” antes que los clientes.