SPF, DKIM y DMARC para correo transaccional: por qué debes separar tus envíos del marketing

1. El principio del daño colateral: cómo una campaña de ventas destruye tus correos operativos

En la gestión diaria de una organización en crecimiento, el área de marketing y ventas y el área de producto, tecnología y operaciones persiguen objetivos técnicos que entran en conflicto directo:

• Volumen y alcance comercial: el equipo comercial envía newsletters, avisos de promociones, secuencias de prospección y campañas de reactivación de contactos antiguos. En este tipo de tráfico, la fricción es parte de la actividad: usuarios que marcan el correo como no deseado por error, casillas que rebotan porque el contacto cambió de empresa y buzones corporativos que filtran preventivamente los envíos masivos.
• Inmediatez operativa y certeza de entrega: los sistemas automáticos de tu sitio, tu tienda online o tu software envían enlaces para restablecer contraseñas, recibos de pago, códigos OTP de autenticación en dos pasos y alertas de inicio de sesión. Aquí la tolerancia a demoras es cero: si un cliente quiere entrar a su panel y el código tarda más de sesenta segundos, la sesión expira, la compra se cancela o el usuario termina en los canales de soporte.

Cuando ambos flujos salen con el mismo remitente técnico y las mismas credenciales de dominio (@tuempresa.com), los servidores de destino (como Google Workspace y Microsoft 365) no distinguen si el correo lo escribió un redactor publicitario o lo generó el servidor de autenticación de tu plataforma. Para los filtros antispam existe un solo responsable: tu dominio raíz.

Si una campaña supera el 0,1% de quejas por spam (una queja cada mil envíos), el umbral que Google pide no superar en sus requisitos para remitentes, los filtros bajan la reputación de todo el dominio. En poco tiempo, los correos de recuperación de contraseña que piden tus clientes quedan bajo sospecha, retenidos en colas de espera (greylisting) o enviados en silencio a la carpeta de correo no deseado. Esta contaminación cruzada frena la operación del negocio sin que el equipo de desarrollo entienda qué línea de código falló.

2. Glosario de aislamiento técnico: subdominios, selectores y alineación DMARC

Para separar la infraestructura sin dejar huecos de seguridad, hay que entender cómo interactúan los componentes de la autenticación:

Dominio organizativo (dominio raíz)

La raíz institucional de tu presencia en internet (por ejemplo, tuempresa.com). Es el activo más valioso de la organización: lo usan el sitio web y las casillas de correo de directivos y colaboradores.

Subdominio técnico dedicado

Una rama del dominio creada solo para un tipo de tráfico (por ejemplo, auth.tuempresa.com para accesos y seguridad, o notificaciones.tuempresa.com para facturación). Permite que los proveedores de correo califiquen la reputación de esos envíos por separado.

Selector DKIM

Una etiqueta única (como row2026) que se antepone al dominio en el registro DNS para indicar qué llave pública debe usar el servidor receptor para validar la firma de un mensaje. Permite que varias herramientas firmen correos legítimamente sin pisarse los registros.

Alineación de identificadores DMARC

La comprobación de DMARC de que el dominio visible en el campo "De:" (Header From) coincide con el dominio autenticado por SPF (Return-Path o Envelope From) o con el dominio declarado en la firma DKIM (d=).

Alineación relajada (r) y estricta (s)

En modo relajado, un correo se considera alineado si el campo "De:" muestra un subdominio (seguridad.tuempresa.com) y la validación SPF o DKIM se hace en el dominio raíz (tuempresa.com). En modo estricto, ambos dominios tienen que coincidir carácter por carácter.

Remitente técnico (Envelope From o Return-Path)

La dirección real, oculta en las cabeceras, que usan los servidores para procesar la entrega y recibir los avisos de rebote. Suele ser distinta de la dirección que ve el destinatario.

3. La limitación invisible de SPF: el riesgo de superar los 10 DNS lookups

Uno de los problemas más frecuentes y difíciles de diagnosticar es la caída intermitente de la entregabilidad por una restricción del protocolo SPF documentada en el estándar RFC 7208.

La regla de los 10 saltos (RFC 7208) y el temido PermError

Para evitar que los servidores de correo queden atrapados en bucles o se usen en ataques de denegación de servicio (DDoS) por amplificación de DNS, el protocolo SPF fija una regla inflexible: evaluar un registro SPF no puede requerir más de diez consultas DNS (DNS lookups).

Mecanismos como include:, a, mx, ptr y redirect consumen consultas. Si al evaluar el registro de tu empresa el servidor receptor llega a la consulta número once, el protocolo corta la validación y devuelve un error permanente: SPF PermError. Con ese error, el receptor considera que el correo no tiene una autenticación SPF válida y lo trata como sospechoso de suplantación de identidad (phishing).

Ejemplo: el colapso del registro SPF corporativo unificado

En una empresa que centraliza todos sus servicios en su dominio principal (tuempresa.com), es habitual encontrar registros SPF saturados con herramientas que se fueron sumando con los años:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mailgun.org include:hubspotemail.net include:zendesk.com ~all

A simple vista parecen cinco elementos. Pero los servicios de correo no usan registros planos:

• Google Workspace (include:_spf.google.com): contiene subconsultas internas que consumen 4 consultas.
• Mailchimp u otras plataformas de marketing: consumen entre 1 y 2 consultas.
• Zendesk u otras herramientas de soporte: consumen 2 consultas.
• HubSpot u otras plataformas de CRM: consumen 2 o 3 consultas más.

En este ejemplo, la suma real llega con facilidad a 10 u 11 consultas. En cuanto la empresa agrega un plugin de formularios para su sitio o un sistema de facturación electrónica, el límite se supera. Desde ese momento, cada vez que tu aplicación envía un correo de restablecimiento de contraseña, el servidor de destino obtiene un PermError y puede desviar el correo a la carpeta de spam.

Aislamiento por subdominio: la resolución limpia de ROW

La solución más sólida ante esta restricción es aislar el envío crítico en un subdominio propio, como el dominio de envío que configura y autentica tu Relay Owner en ROW.

Al asignar un subdominio exclusivo para la operación crítica (por ejemplo, auth.tuempresa.com), se publica en las DNS de la empresa un registro SPF independiente que aplica solo a ese subdominio. En él no se incluyen herramientas de marketing, ni CRM, ni plataformas de soporte: solo el motor de envío de tus correos transaccionales. Si ese motor sale por una IP fija, el registro puede quedar así:

auth.tuempresa.com. IN TXT "v=spf1 ip4:198.51.100.45 -all"

Este registro se resuelve sin consultas DNS adicionales y termina en -all (hard fail) para que nadie pueda enviar correos desde ese subdominio sin autorización. Así, el envío crítico queda lejos del límite de diez consultas, aunque marketing siga sumando herramientas en el dominio principal.

4. Selectores DKIM y gobernanza DMARC: la arquitectura correcta

El aislamiento de canales no termina en SPF: también requiere coordinar las firmas DKIM y la política DMARC para que cada flujo tenga su propia identidad.

Independencia de firmas con selectores dedicados

DKIM (DomainKeys Identified Mail) agrega una firma digital en las cabeceras de cada mensaje con un par de llaves: una privada, en el servidor que envía, y una pública, en tus DNS. El dato que indica qué llave usar es el selector.

En una infraestructura unificada y precaria, es común que una agencia de marketing modifique o sobrescriba el selector DKIM principal del dominio al configurar una nueva herramienta de envíos masivos. Si el registro queda mal, las contraseñas y los códigos que genera el sistema de tu empresa pierden la validez de su firma en el acto.

La alternativa es un selector DKIM exclusivo para el subdominio transaccional, con llaves de 2048 bits (por ejemplo, row._domainkey.auth.tuempresa.com). Esto aporta dos ventajas:

1. Independencia: las campañas o los cambios de proveedor de marketing pueden rotar sus llaves todas las veces que haga falta sin tocar la firma de los accesos de usuario.
2. Reputación propia: los correos de tu plataforma se firman con una llave limpia y aislada, que los filtros de Google y Microsoft evalúan por separado de tus campañas.

Políticas DMARC: la convivencia entre el dominio raíz y los subdominios

DMARC supervisa la coherencia del dominio y les indica a los servidores receptores qué hacer con los mensajes que no pasan la autenticación. Incluye una etiqueta pensada para los subdominios: sp= (subdomain policy).

Un registro DMARC del dominio principal que contempla esta separación puede verse así:

v=DMARC1; p=quarantine; sp=reject; aspf=s; adkim=s; rua=mailto:dmarc-reports@tuempresa.com; pct=100;

Esta directiva establece una protección en dos niveles:

• En el dominio raíz (p=quarantine): si la empresa está revisando herramientas comerciales heredadas o adaptando sus canales de marketing, puede mantener una política de cuarentena para no perder correos comerciales legítimos mientras completa la transición.
• En los subdominios (sp=reject): como el subdominio transaccional solo envía desde el motor de envío autorizado, puede trabajar con alineación estricta (aspf=s y adkim=s) y con una política de rechazo. Si alguien intenta enviar un correo que simula venir de seguridad@auth.tuempresa.com para robar credenciales a tus clientes, los servidores de destino lo rechazan antes de que llegue a una bandeja.

Dos aclaraciones. Primero, sp= aplica a todos los subdominios que no tienen su propio registro DMARC: si el subdominio de marketing (news.tuempresa.com) necesita una política más flexible, se le publica su propio registro en _dmarc.news.tuempresa.com. Segundo, al rechazo se llega de forma gradual: se empieza en modo monitoreo (p=none) y la política se endurece a medida que los informes confirman que todo el correo legítimo está alineado. Así trabaja tu Relay Owner en ROW.

5. Diagnóstico y comparativa: infraestructura unificada vs. flujos aislados con ROW

6. Preguntas frecuentes sobre separación de flujos y autenticación transaccional

¿No es suficiente con cambiar el nombre visible del remitente, por ejemplo usando noreply@tuempresa.com o soporte@tuempresa.com?

No. Es una de las creencias más extendidas entre equipos comerciales y gerentes de producto. Los filtros antispam de Google, Microsoft o Yahoo no evalúan un mensaje por el nombre o la dirección que ve el destinatario, sino por sus cabeceras técnicas: el remitente técnico real (Envelope From o Return-Path), la IP del servidor que hizo la conexión SMTP y la alineación de las firmas. Si tu empresa envía promociones desde ventas@tuempresa.com y códigos de verificación desde noreply@tuempresa.com, para los sistemas de seguridad ambos correos vienen de la misma entidad técnica; si el dominio raíz está penalizado por envíos comerciales con muchos rebotes, noreply@ sufre el mismo bloqueo. La única forma técnica de separar reputaciones es usar subdominios distintos (por ejemplo, @auth.tuempresa.com).