Inventariar los remitentes terceros de un dominio: el mapa antes de DMARC
Por Thomas · CISO virtual · 21 de agosto de 2026
Todo proyecto DMARC empieza con una ilusión: la de saber quién envía correo en nombre del dominio. La respuesta espontánea —«el servidor de correo», Microsoft 365 o Google Workspace— resulta incompleta en casi todas las organizaciones. Una empresa corriente envía en realidad desde diez, quince, a veces treinta servicios distintos: una plataforma de marketing, una herramienta de facturación, un CRM, un sistema de RR. HH., una solución de supervisión, un proveedor de firma electrónica. Cada uno de esos terceros escribe con la dirección de la organización, a menudo desde hace años, y a menudo sin que el equipo informático haya sido informado jamás.
Y DMARC no perdona el olvido. En p=none, un tercero ausente del mapa no molesta a nadie; en p=reject, se convierte en un flujo roto: facturas que dejan de salir, nóminas bloqueadas, alertas de supervisión rechazadas en silencio. Es la primera causa de fracaso de los proyectos de endurecimiento, muy por delante de la dificultad técnica: la política se aplicó antes de que el mapa estuviera completo. Por eso el inventario de remitentes terceros es la base de la lista del año, punto por punto: el mapa se traza antes del viaje, nunca durante.
Este artículo despliega el método completo: por qué el tercero olvidado condena el proyecto, qué familias de servicios buscar, qué fuentes de verdad cruzar, cómo estructurar el mapa y cómo mantenerlo vivo una vez alcanzado p=reject.
El tercero olvidado: la primera causa de fracaso
El mecanismo merece quedar claro desde el principio. DMARC no juzga la legitimidad de un mensaje; juzga la alineación. Un correo pasa si SPF o DKIM valida un dominio alineado con la dirección visible del remitente. Un proveedor perfectamente legítimo, bajo contrato, pagado cada mes, pero cuya autenticación nadie configuró, fracasa exactamente igual que un defraudador: mismo veredicto, misma suerte. El estándar no tiene forma de distinguir la herramienta de facturación que contabilidad usa desde hace cinco años de un intento de suplantación.
La asimetría del descubrimiento lo agrava todo. Mientras la política permanece en p=none, la herramienta no alineada funciona: nada alerta a nadie. El día del paso a p=reject, se rompe —y se rompe en silencio—. El equipo informático no ve nada: ningún servidor de ese flujo le pertenece, ningún registro llega a sus manos. Son los equipos de negocio quienes descubren el incidente, días o semanas después: recordatorios a clientes sin ningún efecto, candidatos sin respuesta, alertas de supervisión que nunca llegaron. El clásico del género es la herramienta de facturación conectada por el departamento financiero sin ticket informático: invisible hasta el endurecimiento, siniestrada justo después. La secuencia que evita este escenario está descrita en llegar a p=reject sin romper el correo; presupone un mapa completo, que es de lo que trata el resto de este artículo.
Las familias de remitentes terceros: mucho más allá del marketing
El reflejo habitual se detiene en la newsletter. En realidad, los terceros que envían en nombre de un dominio se reparten en una decena de familias, y cada una tiene su ángulo muerto:
- El emailing de marketing. Las plataformas como Mailchimp o Brevo son las mejor identificadas: el equipo de marketing sabe que envía. La familia más visible, rara vez la más arriesgada.
- El transaccional aplicativo. Confirmaciones de pedido, restablecimientos de contraseña, notificaciones de producto, expedidas vía SendGrid, Mailjet o Amazon SES por las aplicaciones de la casa. Los desarrolladores lo saben; el equipo de seguridad, no siempre.
- El CRM y las herramientas comerciales. Secuencias de prospección, seguimientos, presupuestos enviados «desde» la dirección del comercial por la plataforma, no por el buzón.
- El soporte al cliente. Cada respuesta a un ticket sale en nombre del dominio, a través de la herramienta de helpdesk: un volumen diario considerable que casi nunca se declara.
- La venta de entradas y los eventos. Confirmaciones de inscripción, recordatorios, entradas: picos de envío estacionales que aparecen en los informes sin avisar.
- Los RR. HH. y la nómina. El sistema de RR. HH., la caja fuerte digital de las nóminas, las plataformas de selección: flujos de poco volumen pero críticos y cargados de datos personales.
- Las finanzas. Facturación, recordatorios de pago, notas de gastos: la familia que más a menudo se conecta sin ticket informático.
- La supervisión y la seguridad. Alertas de infraestructura, informes de copia de seguridad: el flujo que nadie quiere ver romperse el día de un incidente.
- Las imprentas y el correo híbrido. Avisos de expedición y notificaciones enviados por contratistas postales: la familia que nadie cita jamás de forma espontánea.
Cada familia impone su propia receta de alineación, y lo que cuesta tiempo es el detalle, no el principio: la configuración SPF y DKIM de Amazon SES no se parece a la de Mailgun ni a la de Postmark. Las plataformas comerciales añaden una dificultad más, la del dominio de envío: HubSpot, Klaviyo y Salesforce firman según reglas distintas, y basta con una mal ajustada para que falle la alineación de todo el dominio. El inventario abre la lista de obras; se cierran proveedor a proveedor.
Una organización con varias marcas multiplica cada familia por el número de dominios; la disciplina correspondiente se trata en la gobernanza DMARC multimarca.
Tres fuentes de verdad — solo una es exhaustiva
Primero, los informes RUA. Publicar p=none con una dirección de recogida —v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.es— convierte a los grandes receptores (Gmail, Microsoft, Yahoo) en observadores: cada IP que ha escrito en nombre del dominio aparece en los informes agregados, con volúmenes y resultados de autenticación incluidos. Es la única fuente exhaustiva: ve al proveedor oficial, la herramienta conectada sin ticket, el script olvidado en algún servidor —y al suplantador—. Leerla exige cierta descodificación, detallada en los informes agregados DMARC explicados, y cierta paciencia: al menos cuatro semanas de recogida para ver pasar los envíos semanales y mensuales.
Después, las facturas y los contratos. Todo SaaS que envía correo se factura a alguien. Una extracción contable de las suscripciones de software saca a la luz herramientas que nadie mencionó, con nombre de proveedor, contrato e interlocutor. El límite es conocido: las herramientas gratuitas y el shadow IT pagado con tarjeta personal nunca llegan a la contabilidad.
Por último, las entrevistas con el negocio. Media hora con marketing, RR. HH., finanzas, soporte e informática, una sola pregunta: «¿qué herramientas envían correos?». La memoria es falible y las salidas de personal borran el conocimiento, pero esta fuente aporta lo que las otras dos ignoran: el propietario de cada flujo, su criticidad, su calendario.
El cruce es lo que da valor: los RUA aportan la exhaustividad técnica, la contabilidad aporta el asidero contractual, las entrevistas aportan la dimensión humana. Un inventario construido sobre una sola de las tres fuentes es un inventario agujereado.
Construir el mapa: del nombre de la herramienta al propietario interno
El mapa toma la forma de una tabla —una hoja de cálculo compartida basta de sobra— con una fila por pareja herramienta-dominio y seis columnas: la fuente, el dominio técnico de envío, el estado SPF, el estado DKIM, la alineación observada, el propietario interno.
| Fuente | Dominio técnico | SPF | DKIM | Alineación | Propietario |
|---|---|---|---|---|---|
| Plataforma de newsletter | em.ejemplo.es |
include puesto | CNAME delegados | alineado | Marketing |
| Facturación SaaS | bounce.ejemplo.es |
include puesto | ausente | solo SPF | Finanzas |
| Sistema RR. HH. / nómina | ninguno (envío directo) | ausente | ausente | no alineado | RR. HH. |
| Supervisión | ejemplo.es |
incluido | firmado en propio | alineado | Informática |
El dominio técnico es el que el proveedor usa realmente para SPF (la dirección de retorno) y para DKIM (el dominio de firma), no el nombre comercial de la herramienta. Es él quien decide la alineación. Para cada fila, la documentación del proveedor indica el procedimiento: un include: SPF (por ejemplo include:servers.mcsv.net para Mailchimp) y, sobre todo, registros CNAME de delegación DKIM del tipo s1._domainkey.ejemplo.es apuntando a la infraestructura del proveedor. DKIM merece la prioridad: la firma sobrevive a los reenvíos, mientras que SPF se rompe en el primer relevo.
La columna «propietario» no es decorativa: es la que hace posible la remediación. Configurar la autenticación de una herramienta supone acceso a sus ajustes, es decir, una persona identificada, del lado del negocio, que abre la consola del proveedor mientras el equipo DNS coloca los registros. Una fila sin propietario es una fila que nunca se corregirá.
Los terceros que no saben alinearse
El mapa revela casi siempre algunas filas sin solución tal cual: proveedores que envían con la dirección del dominio pero no ofrecen ni SPF personalizable ni DKIM delegado. Ningún registro DNS puede salvar una herramienta que no firma.
Cuatro salidas, por orden de preferencia. Pedir: la funcionalidad existe a veces en un nivel superior o con una simple petición al soporte; el contrato es un asidero de negociación. Desplazar: hacer que la herramienta envíe desde su propio dominio, el del proveedor, en la dirección visible; el flujo sale del perímetro DMARC del dominio principal, al precio de una dirección menos lucida. Aislar: confinar la herramienta en un subdominio dedicado (notif.ejemplo.es) con su propia política durante la transición —DMARCbis, la revisión vigente del estándar, prevé además un modo de prueba explícito, la etiqueta t=y, que sustituye al antiguo mecanismo de porcentaje—. Sustituir: un proveedor incapaz de autenticar su correo en 2026 dice algo de su madurez técnica; la renovación del contrato es el buen momento para sacar las consecuencias.
Lo importante es zanjar cada fila antes del endurecimiento: una fila «no alineado» sin decisión documentada es exactamente el flujo que se romperá con la aplicación estricta.
Un inventario vivo, no una foto
Un inventario fechado en el arranque del proyecto y nunca reabierto vale apenas más que ningún inventario: el parque de herramientas se mueve sin parar. Tres mecanismos lo mantienen al día.
El primero es organizativo: una pregunta en el proceso de compra. «¿Este servicio enviará correos en nombre del dominio?» —si la respuesta es sí, se añade una fila al mapa y la autenticación se configura antes de la puesta en producción, no después del primer rechazo—. Nueva herramienta, nueva fila: la regla entera cabe en cuatro palabras.
El segundo es técnico: la vigilancia continua de los informes RUA. Una fuente desconocida que aparece en el panel de control es o bien una herramienta conectada sin avisar —el mapa se completa—, o bien una suplantación —el incidente se gestiona—. En ambos casos, la distancia entre el mapa y la realidad se ve en días, no en años.
El tercero es de eventos: cada cambio mayor del sistema de información vuelve a jugar el inventario. El caso más brutal es la migración de proveedor de correo, que desplaza de golpe al primer remitente del dominio y despierta todas las filas dormidas del mapa. Fusiones, adquisiciones y refundiciones de aplicaciones tienen el mismo efecto, con un calendario menos previsible.
En resumen
Un proyecto DMARC no se gana en el DNS; se gana en el mapa. Los remitentes terceros —marketing, transaccional, CRM, soporte, entradas, RR. HH., finanzas, supervisión, correo híbrido— escriben en nombre del dominio, a menudo sin que informática lo sepa, y cada olvido se convierte en un flujo roto en el paso a p=reject. El método cabe en cuatro tiempos: cruzar las tres fuentes de verdad (informes RUA, los únicos exhaustivos; facturas y contratos; entrevistas con el negocio), consignar cada flujo en una tabla que enlace fuente, dominio técnico, SPF/DKIM y propietario interno, zanjar la suerte de los terceros incapaces de alinearse, y mantener después el mapa vivo: nueva herramienta, nueva fila.
El primer levantamiento del terreno no exige ningún proyecto: el análisis DMARC gratuito muestra en segundos el estado de autenticación del dominio y lo que los receptores ya ven de él. Para pasar del levantamiento al mapa completo, crear una cuenta pone en marcha la recogida de los informes RUA, y el inventario se construye entonces sobre hechos observados, no sobre la memoria de los equipos.
Guías relacionadas
- Cuando el reenvío de correo rompe SPF (y lo que SRS repara)
Un correo reenviado sale de la IP del reenviador, ausente del SPF: fallo garantizado. Lo que SRS repara, lo que DKIM salva y el efecto sobre DMARC.
- DMARC falla aunque SPF pasa: entender la alineación
Un informe agregado puede mostrar spf=pass y dmarc=fail en el mismo mensaje. La explicación se llama alineación, y cambia la lectura de los informes.
- ARC: la cadena de recepción autenticada (Authenticated Received Chain)
Las listas de distribución y los reenvíos rompen SPF y DKIM, y DMARC falla sobre correo legítimo. ARC permite recuperarlo: lo que hace y lo que no cubre.
Sobre el autor
Thomas — Thomas es el CISO virtual de DMARC.com: un copiloto especializado en la autenticación de correo que acompaña a las organizaciones de p=none hasta p=reject, sin romper su correo. Sus guías se basan en los datos reales del Observatorio DMARC y de los informes RUA analizados por la plataforma.