El despliegue completo de autenticación de correo: SPF, DKIM y DMARC de cero a p=reject

El correo electrónico sigue siendo el punto de entrada más explotado en las organizaciones. Según el Verizon Data Breach Investigations Report, el phishing y el pretexting están involucrados en la mayoría de las brechas por ingeniería social, y la mayoría de ellas comienzan con una dirección de remitente suplantada. Los tres estándares de autenticación basados en DNS (SPF, DKIM y DMARC) existen para hacer que la suplantación de su dominio sea técnicamente detectable y, en su plena aplicación, rechazable.

Esta guía está escrita para gerentes de TI que necesitan llevar a una organización real —con boletines, CRM, servicio de asistencia, software de facturación y plataforma de marketing enviando correo "desde" el dominio de la empresa— desde cero autenticación de correo hasta una política DMARC de p=reject, sin perder un solo mensaje legítimo en el proceso. Espere que el despliegue completo tome de 6 a 10 semanas de tiempo calendario, con solo unas pocas horas de trabajo práctico por semana.

Cómo encajan los tres protocolos

Antes de tocar el DNS, asegúrese de que el modelo mental sea el correcto, porque la mayoría de los despliegues fallidos provienen de malinterpretar la alineación.

• SPF (RFC 7208) publica, en el DNS, la lista de direcciones IP autorizadas para enviar correo usando su dominio en el sobre SMTP (MAIL FROM).
• DKIM (RFC 6376) firma criptográficamente cada mensaje con una clave privada; la clave pública se publica en el DNS. Los receptores verifican la firma para confirmar que el mensaje no fue alterado y fue autorizado por el dominio firmante.
• DMARC (RFC 7489) une ambos. Indica a los receptores: "si un mensaje afirma ser de mi dominio en el encabezado visible From:, debe pasar SPF o DKIM en alineación con ese dominio; esto es lo que debe hacer si no lo cumple y aquí es a dónde enviar los informes".

El flujo de verificación en el servidor de correo receptor se ve así:

            Incoming message claiming From: billing@example.com
                                 |
              +------------------+------------------+
              |                                     |
        SPF check                              DKIM check
   Is sending IP listed in               Does the d= signature
   example.com's SPF record              verify against the DNS
   for the envelope sender?              public key?
              |                                     |
              +------------------+------------------+
                                 |
                          DMARC alignment
        Does the domain that passed (envelope domain for SPF,
        d= domain for DKIM) match the visible From: domain?
                                 |
              +------------------+------------------+
              |                                     |
         PASS: deliver                    FAIL: apply policy
                                          p=none  -> deliver, report
                                          p=quarantine -> spam folder
                                          p=reject -> refuse message

El detalle crucial: un mensaje puede pasar SPF y DKIM para algún dominio y aun así fallar DMARC, porque DMARC requiere que el dominio que aprueba se alinee con el dominio del encabezado From: que sus usuarios realmente ven. Esto es exactamente lo que detiene a un atacante de phishing que firma correos con la clave DKIM de su propio dominio.

Fase 0 — Inventariar a cada remitente legítimo (semana 1)

La causa número uno de pérdida de correo durante los despliegues de DMARC es un servicio de envío olvidado. Antes de publicar algo, cree un inventario de remitentes. Entreviste a los equipos de marketing, ventas, finanzas y RR.HH., y revise el DNS en busca de mecanismos include existentes.

Inventario típico para una empresa de 50 personas:

Dos reglas generales de esta fase:

1. Cualquier cosa que no pueda hacer DKIM debe migrarse para enviar a través de un relé autenticado (p. ej., su relé SMTP de Workspace o un proveedor transaccional como Postmark o SES) en lugar de directamente desde un servidor web.
2. No adivine. La fase de monitoreo DMARC a continuación detectará lo que las entrevistas omitan; para eso sirve.

Fase 1 — Publicar un registro SPF correcto (semanas 1–2)

SPF es un registro TXT en la raíz de su dominio. Recopile los mecanismos include de la documentación de cada proveedor y combínelos en un solo registro: un dominio debe tener exactamente un registro SPF; dos registros causan un error permanente (permerror) y desactivan efectivamente el SPF.

example.com.  IN TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.hubspot.com ip4:203.0.113.25 ~all"

Decisiones clave:

• Termine con ~all (softfail), no -all, durante el despliegue. DMARC no necesita -all para funcionar, y -all combinado con un inventario incompleto rebota correos legítimos inmediatamente. Puede endurecer a -all después de que el monitoreo confirme que el inventario está completo.
• Manténgase por debajo de 10 búsquedas DNS. Cada mecanismo include, a, mx y redirect cuesta una búsqueda; exceder diez es un permerror según RFC 7208 §4.6.4. Cuente las búsquedas anidadas dentro de cada include (el include de Google cuesta tres por sí solo). Si está cerca del límite, use SPF flattening con precaución o mueva los remitentes masivos a un subdominio.
• Use ip4:/ip6: para servidores que usted controla en lugar de mecanismos a: — no cuestan búsquedas.

Valide con un verificador (la herramienta de MX y seguridad de correo de FortifyNet muestra SPF, DKIM y DMARC en una pasada) y con dig:

dig +short TXT example.com | grep spf1

Fase 2 — Habilitar DKIM en todas partes (semanas 2–3)

La configuración de DKIM es por proveedor, pero siempre sigue el mismo formato: el proveedor genera un par de claves, usted publica la clave pública en selector._domainkey.example.com, y el proveedor comienza a firmar.

• Google Workspace: Consola de administración → Aplicaciones → Gmail → Autenticar correo. Genere una clave de 2048 bits (las claves de 1024 bits se consideran débiles; NIST y M3AAWG recomiendan 2048). Publique el registro TXT, espere la propagación de DNS, haga clic en "Iniciar autenticación".
• Microsoft 365: Portal de Defender → Configuración de autenticación de correo → DKIM. Microsoft utiliza dos registros CNAME (selector1, selector2) que permiten la rotación automática de claves.
• Mailchimp, HubSpot, Zendesk, etc.: cada uno tiene un asistente de "autenticar su dominio" que le da 2–4 registros CNAME.

Verifique cada selector después de publicar:

dig +short TXT google._domainkey.example.com
dig +short CNAME selector1._domainkey.example.com

Luego envíe un mensaje de prueba a una dirección de Gmail, abra "Mostrar original" y confirme que ve DKIM: PASS with domain example.com; la parte "with domain" es la alineación que DMARC verificará.

Planifique la rotación de claves cada 6–12 meses. Los proveedores con configuraciones basadas en CNAME rotan por usted; para claves publicadas manualmente, ponga un elemento recurrente en el calendario de seguridad ahora, porque nadie lo recordará después.

Fase 3 — DMARC en modo de monitoreo (semanas 3–4)

Publique un registro DMARC en _dmarc.example.com con la política p=none. Esto no cambia nada sobre la entrega; solo activa los informes.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r"

Qué hace cada etiqueta:

Notas prácticas:

• Use un buzón dedicado o, mucho mejor, un procesador de informes DMARC; los informes brutos son XML comprimidos (gzipped) y llegan de cada gran receptor diariamente. Los niveles gratuitos de los analizadores comunes son suficientes para un solo dominio.
• Si la dirección del informe está en un dominio diferente al que se está monitoreando, el dominio del informe debe publicar un registro de verificación de destino externo (RFC 7489 §7.1).
• Deje que el monitoreo se ejecute al menos dos semanas completas, idealmente cuatro, para que los trabajos mensuales (ejecuciones de facturas, informes de la junta) aparezcan en los datos.

Fase 4 — Leer los informes y corregir lo que falla (semanas 4–6)

Los informes agregados responden a tres preguntas para cada IP de envío: cuánto correo, si SPF se alineó, si DKIM se alineó. Clasifique en tres grupos:

1. Pase alineado (SPF o DKIM): saludable. La mayor parte de su correo de Workspace/M365 debería estar aquí desde el primer día.
2. Su servicio, fallando la alineación: p. ej., el CRM pasa DKIM pero firma con d=crm-provider.com. Corríjalo completando el asistente de autenticación de dominio de ese proveedor para que firme con su dominio. Este grupo es su cola de trabajo de la Fase 4.
3. IPs desconocidas fallando en todo: esto es suplantación (o reenvío). No lo corrija; la aplicación de la política lo neutralizará. Su presencia es el caso de negocio para todo este proyecto.

Una fuente legítima seguirá fallando sin importar lo que haga: las listas de correo y algunos reenviadores rompen SPF (nueva IP de envío) y a veces DKIM (pie de página añadido). ARC (RFC 8617) ayuda en grandes receptores, pero la respuesta honesta es que una pequeña tasa de falla residual (muy por debajo del 1%) es normal y aceptable en la aplicación.

Fase 5 — Escalar a la aplicación (semanas 6–10)

Nunca salte de p=none directamente a p=reject. Use la etiqueta pct para escalar:

En cada paso, observe dos señales: los informes agregados (el porcentaje de pase-alineado para remitentes conocidos debería permanecer estable) y el servicio de asistencia (tickets sobre "el cliente dice que mi correo rebotó"). La reversión es un simple cambio de DNS al paso anterior y entra en vigencia dentro del TTL del registro; configure el TTL a 3600 segundos durante la escala para que los errores sean baratos.

Cuando llegue a p=reject, termine el trabajo:

• Agregue una política de subdominio explícita: sp=reject, a menos que un subdominio envíe intencionalmente con reglas más laxas.
• Proteja los dominios estacionados (parked domains) que posee pero desde los cuales nunca envía: dé a cada uno v=spf1 -all, una política DKIM vacía y v=DMARC1; p=reject. Los dominios estacionados son el objetivo favorito de los suplantadores.
• Considere BIMI (logotipo de marca en las bandejas de entrada); requiere DMARC aplicado, por lo que acaba de desbloquearlo.

Referencia rápida de resolución de problemas

El despliegue de un vistazo

Imprima esta tabla en el ticket del proyecto; cada fila es una actualización de estado semanal natural para la gerencia, y la columna de entregables mantiene la honestidad del proyecto sobre lo que significa "terminado" en cada paso.

Más allá de DMARC: MTA-STS y TLS-RPT

DMARC autentica quién envió un mensaje; no dice nada sobre si el mensaje viajó cifrado. SMTP todavía recurre al texto plano cuando la negociación TLS falla, y un atacante activo en la ruta de red puede forzar exactamente esa falla. Dos estándares complementarios cierran la brecha, y dado que ya está en la consola de DNS, esta es la semana correcta para desplegarlos.

MTA-STS (RFC 8461) permite que su dominio declare "solo entréguenme correo sobre TLS autenticado". Consiste en un registro DNS y un pequeño archivo de política servido sobre HTTPS:

_mta-sts.example.com.  IN TXT  "v=STSv1; id=20260828T000000"

https://mta-sts.example.com/.well-known/mta-sts.txt:
  version: STSv1
  mode: testing
  mx: mail.example.com
  max_age: 86400

Ejecute el modo: testing durante dos semanas, luego cambie a mode: enforce y aumente max_age a 604800. Las líneas mx deben coincidir exactamente con sus nombres de host MX reales; un error tipográfico aquí descarta silenciosamente el correo entrante en modo de aplicación, por lo que existe la etapa de prueba.

TLS-RPT (RFC 8460) es el canal de informes para MTA-STS, exactamente como los informes rua lo son para DMARC:

_smtp._tls.example.com.  IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Los remitentes que no logran entregar sobre TLS le informan por qué, diariamente, en JSON legible por máquina. En la práctica, los informes son silenciosos, que es precisamente la confirmación que desea antes de aplicar la política.

Leer un informe agregado a mano

Incluso con un analizador, lea un informe bruto una vez para que los datos dejen de ser una caja negra. Dentro del XML comprimido, cada bloque de registro contiene tres cosas que importan:

<record>
  <row>
    <source_ip>198.51.100.7</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
</record>

Léalo como una oración: "198.51.100.7 envió 412 mensajes afirmando ser example.com; SPF se alineó, DKIM no; bajo la política actual no se hizo nada". Busque la IP (DNS inverso más los rangos publicados del remitente) y sabrá si esta fila es del grupo 1, 2 o 3 de la Fase 4. Diez minutos con un informe enseñan más que cualquier recorrido por un tablero.

Gobernanza: manteniéndolo aplicado

La autenticación de correo no es un proyecto con fecha de finalización; es una capacidad permanente pequeña. Incorpore esto en las operaciones normales antes de cerrar el ticket:

• Control de cambios en DNS: cada nueva herramienta SaaS que "solo necesita enviar correo como nosotros" pasa por usted, obtiene DKIM configurado correctamente y se agrega a la tabla de inventario. La alternativa es que marketing se registre en una herramienta en noviembre y su correo caiga silenciosamente en spam bajo su p=reject.
• Revisión trimestral de informes: quince minutos por trimestre escaneando el analizador en busca de nuevas fuentes que fallen. Agréndelo.
• Monitoreo de los registros mismos: los registros SPF, DKIM y DMARC pueden romperse por una migración de DNS inocente. El monitoreo externo que alerta sobre cualquier cambio en estos registros (el monitoreo de dominios de FortifyNet lo hace continuamente) convierte una regresión silenciosa en una solución del mismo día.
• Baja de servicios: cuando se cancele un servicio de envío, elimine sus registros include y DKIM esa misma semana. Los include obsoletos son tanto una fuga del presupuesto de búsqueda como un riesgo de cadena de suministro: si el espacio IP del proveedor se reasigna, quien lo herede puede enviar correo autenticado como usted.

Lista de verificación final

• Inventario de remitentes revisado por marketing, finanzas, soporte
• Exactamente un registro SPF, menos de 10 búsquedas, termina ~all (luego -all)
• DKIM 2048-bit, verificado por selector, rotación programada
• DMARC p=none con informes rua, 2–4 semanas de datos revisados
• Todos los remitentes legítimos alineados (grupo 2 vacío)
• Escalar: cuarentena 10% → 50% → 100% → reject, una semana+ por paso
• sp=reject configurado; dominios estacionados bloqueados
• Ejecute un escaneo completo de FortifyNet para confirmar que los registros califiquen limpiamente

Fuentes

• RFC 7208 — Sender Policy Framework (SPF)
• RFC 6376 — DomainKeys Identified Mail (DKIM)
• RFC 7489 — Domain-based Message Authentication, Reporting & Conformance (DMARC)
• M3AAWG Email Authentication Best Practices
• Google Workspace — Set up DMARC
• Microsoft 365 — Use DMARC to validate email
• Verizon Data Breach Investigations Report