Tus primeros informes DMARC casi siempre traen una sorpresa: una dirección IP que no reconoces, enviando miles de mensajes con tu dominio en el campo From. A veces es una herramienta que tu equipo de ventas contrató la primavera pasada. A veces es un servicio de reenvío. Y de vez en cuando es alguien que se hace pasar por ti. Esta guía te da una forma repetible de identificar cada fuente desconocida, clasificarla en una categoría y decidir qué hacer, sin adivinar y sin romper el correo legítimo.
La respuesta corta#
Para identificar a un remitente desconocido en un informe DMARC, toma su IP de origen y haz cuatro comprobaciones en orden: el nombre DNS inverso (PTR) de la IP, si la IP está cubierta por un include de SPF que publicas tú o un proveedor, el dominio de la firma DKIM (d=) del informe en bruto y el propietario del bloque de IP mediante una consulta a un registro. Después clasifica la fuente como un servicio olvidado, tu propio servidor o script, un reenviador, el proveedor de buzones de tu equipo o un suplantador. Autentica las legítimas, ignora a la mayoría de los reenviadores y deja que p=reject se ocupe del suplantador. Nunca bloquees ni "arregles" una fuente antes de saber a qué grupo pertenece. La consulta DNS inversa gratuita resuelve el primer paso, y el analizador de informes DMARC gratuito te permite inspeccionar los campos en bruto de un informe concreto.
Empieza por lo que el informe ya te dice#
Antes de consultar nada, reúne todo lo que te da la fila. Para cada IP desconocida, anota:
- La dirección IP y cuántos mensajes envió.
- Los resultados de SPF y DKIM, y si cada uno estaba alineado con tu dominio From.
- La disposición, es decir, lo que hizo el receptor: none, quarantine o reject.
- Los dominios usados en las comprobaciones SPF y DKIM en bruto, si puedes ver el XML original.
Ese último punto es más útil de lo que parece. Una fila donde DKIM pasó con d=example.com significa que el remitente firma con una clave publicada bajo tu dominio, así que tú o un proveedor que configuraste lo montó. Una fila donde DKIM pasó con d=vendor.example.net y SPF pasó para el dominio de rebotes del proveedor significa que el proveedor envía correo autenticado para sí mismo, con tu dominio solo en el campo From. Ese es el típico remitente tercero sin alinear. Una fila donde SPF y DKIM fallaron o están ausentes apunta con mucha más fuerza a una suplantación o a un relay sin configurar.
Si tu herramienta de monitoreo ya muestra un nombre amigable para la fuente, tómalo como una pista, no como una prueba. Los nombres se derivan de patrones de DNS inverso, y aun así debes confirmarlo con los pasos siguientes.
Paso 1: Consulta el nombre DNS inverso#
La mayoría de los remitentes legítimos publican un registro PTR para sus IP de envío. Haz una consulta inversa:
dig -x 203.0.113.42 +short
mail-42.sendingplatform.example.net.
El nombre de host suele indicar el servicio directamente. Dos precauciones:
- Confírmalo hacia delante. Consulta el registro A de ese host y comprueba que devuelve la misma IP. Un registro PTR lo controla quien es dueño de la IP, así que cualquiera puede reclamar cualquier nombre. Solo un nombre que resuelve de vuelta a la misma IP merece confianza.
- Un PTR ausente o genérico ya es información. Nombres como
static-203-0-113-42.hosting.examplesuelen significar un servidor alquilado o una línea residencial, no una plataforma de correo. Eso encaja mejor con un suplantador o con un script autoalojado que con un proveedor serio.
Puedes hacer la consulta con un clic con la herramienta de consulta DNS inversa si no tienes una terminal a mano.
Paso 2: Comprueba si la IP está dentro de tu SPF#
Mira tu propio registro SPF y verifica si esta IP está cubierta, directamente o mediante un include:
example.com. TXT "v=spf1 include:_spf.google.com include:sendingplatform.example.net ~all"
Si el nombre del proveedor del paso 1 ya aparece en un include:, alguien lo autorizó en algún momento. La fuente es tuya, y la pregunta pendiente es por qué falla la alineación. Normalmente es porque el SPF del proveedor pasa para su propio dominio de rebotes, que no se alinea con tu dominio From, y nunca se configuró una firma DKIM para tu dominio. La solución está del lado de DKIM y se explica en fallos de alineación DMARC.
Si la IP no está cubierta, y el PTR apunta a un proveedor del que nunca has oído hablar, tienes un servicio olvidado o a un desconocido. Sigue adelante. También puedes pasar el dominio por el verificador de SPF, DKIM y DMARC para ver qué contiene hoy tu registro SPF.
Paso 3: Lee el dominio de la firma DKIM#
Cuando el informe en bruto lista un resultado DKIM, indica el dominio firmante y el selector. Hay tres desenlaces habituales:
d=es tu dominio. Un sistema interno o un proveedor que configuraste está firmando con tu clave. Busca el selector en tu DNS para ver de qué clave se trata. Si no reconoces el selector, consulta cómo encontrar un selector DKIM.d=es el dominio del proveedor. Autenticado para el proveedor, no para ti. Se puede arreglar una vez identificado el proveedor.- Ningún resultado DKIM. El remitente no firma. Los scripts pequeños, las impresoras, los plugins antiguos de CMS y los suplantadores se ven así.
Si solo tienes la cabecera de un mensaje recibido y no un informe, el analizador de cabeceras de correo muestra el veredicto de DKIM y si hay una firma, y el dominio d= lo lees tú mismo en la línea DKIM-Signature.
Paso 4: Averigua quién es el dueño del bloque de IP#
Si el PTR falta o no ayuda, consulta al registro regional de internet por la dirección (una consulta WHOIS o RDAP). El resultado nombra a la organización que posee el bloque, a menudo una empresa de hosting o un proveedor cloud. Esto te dice de dónde sale el tráfico, no quién es responsable, así que úsalo para acotar la búsqueda y no para acusar a nadie. Un bloque propiedad de una plataforma de correo conocida respalda la teoría del "proveedor olvidado". Un bloque propiedad de un hosting económico sin DNS inverso apunta en sentido contrario.
Clasifica la fuente y luego actúa#
Tras las cuatro comprobaciones, la mayoría de las fuentes caen en uno de cinco grupos.
| Clase | Cómo se ve en los informes | Qué hacer |
|---|---|---|
| Servicio olvidado o no aprobado | El PTR nombra una plataforma conocida; SPF o DKIM pasa para el dominio del proveedor, no para el tuyo | Pregunta al responsable. Si el correo es deseado, añade la firma DKIM para tu dominio. Si no, cierra la cuenta |
| Tu propio servidor o script | La IP coincide con tu hosting; a menudo sin DKIM; poco volumen en horas raras | Enrútalo por tu sistema de correo real, o fírmalo con tu clave |
| Reenviador o lista de correo | La fuente es un proveedor de buzones o el host de una lista; SPF falla, DKIM puede pasar o romperse si el mensaje se modifica | Normalmente ignóralo; apóyate en la alineación DKIM y no persigas a cada reenviador |
| Proveedor de buzones que retransmite el correo de tu equipo | Coincide con el proveedor que usas para el correo del equipo | Confirma que ese proveedor está en SPF y firma con tu clave DKIM |
| Suplantador | Sin relación contigo; sin PTR o uno genérico; falla SPF y DKIM; volumen repentino | Déjalo fallar; para eso existe una política reject |
El riesgo que hay que evitar es tratar todo lo desconocido como un suplantador. Endurecer tu política mientras una herramienta de facturación olvidada sigue fallando la alineación es como una empresa acaba rechazando sus propias facturas. Primero clasifica. El orden seguro para endurecer se explica en pasar de p=none a p=reject.
Que identificar sea más barato la próxima vez#
La primera pasada es lenta. Después ya no debería serlo. Algunos hábitos ayudan:
- Mantén un inventario. Una fila por cada fuente legítima con el responsable, el tipo de correo y cómo se autentica. El monitoreo DMARC explica una hoja sencilla.
- Pide que las herramientas nuevas se declaren antes del lanzamiento. Un paso breve de admisión ("¿esta herramienta envía con nuestro dominio?") evita la mayoría de las fuentes desconocidas.
- Revisa las cuentas antiguas. Las pruebas gratuitas y las herramientas de agencias que siguen activas son una fuente frecuente de remitentes sorpresa.
- Registra las decisiones. Cuando decidas que una fuente es ruido de reenvío, anótalo para que el siguiente revisor no repita la investigación.
DMARC Reports ayuda con la parte de los nombres. Resuelve el DNS inverso de cada IP de origen y reconoce unos 25 remitentes comunes, como Google, Microsoft 365, Amazon SES, SendGrid y Mailchimp. Lo que no reconoce aparece como el nombre de host en bruto o como "Unknown sender". No te permite etiquetar, rotular ni poner en lista de permitidos una fuente, así que tu hoja de inventario sigue siendo el sistema de referencia. Tampoco muestra el dominio ni el selector de la firma DKIM de una fuente, por lo que el paso 3 requiere un informe en bruto o la cabecera de un mensaje recibido; si quieres los archivos en bruto, mantén una dirección de buzón junto a ella en tu lista rua=.
¿Y si la fuente es un suplantador?#
Si la evidencia dice que la fuente no tiene nada que ver contigo, hay poco que reparar. Tu trabajo es asegurarte de que el fallo tenga consecuencias. Con una política reject y el correo legítimo autenticado, los receptores que respetan DMARC rechazarán o enviarán a spam los mensajes suplantados. No puedes impedir que un suplantador envíe. Solo puedes hacer que su correo falle allí donde los receptores aplican tu política.
Algunos pasos extra son razonables:
- Anota el volumen y las fechas para poder comparar con semanas posteriores.
- Comprueba la IP de origen en las listas negras públicas con el verificador de listas negras.
- Si la campaña es grande y apunta a tus clientes, cuéntale a tu equipo de soporte cómo son los mensajes.
Los informes de receptores pequeños que no envían datos agregados nunca te mostrarán el alcance completo, así que no interpretes una semana tranquila como el final de una campaña de abuso.
Preguntas frecuentes
01¿Cómo averiguo quién es el dueño de una dirección IP de un informe DMARC?
Empieza con una consulta DNS inversa (PTR) y confirma hacia delante que el nombre de host resuelve de vuelta a la misma IP. Después comprueba si esa IP está cubierta por un include de SPF en tu registro, y lee el dominio de la firma DKIM del informe en bruto. Si eso no ayuda, una consulta WHOIS o RDAP nombra a la organización que posee el bloque de IP, lo que acota la búsqueda sin probar responsabilidad.
02¿Una fuente desconocida en mi informe DMARC es siempre un suplantador?
No. Muchas de las fuentes desconocidas de un primer informe son legítimas: una herramienta de marketing o facturación a la que alguien se dio de alta, un servicio de reenvío o tu propio servidor ejecutando un script. Tratar cada IP desconocida como un atacante te arriesga a rechazar tu propio correo cuando endurezcas la política. Clasifica primero la fuente, y trátala como suplantador solo cuando no tenga relación contigo.
03¿Por qué un reenviador falla DMARC en los informes?
Cuando se reenvía un mensaje, la IP del servidor que reenvía no está en tu registro SPF, así que SPF falla o no se alinea. DKIM aún puede pasar si el mensaje no se modificó, y por eso la alineación DKIM es el camino más fiable. El ruido del reenvío suele ser seguro de dejar tal cual en lugar de perseguirlo fuente por fuente.
04¿Puedo bloquear a un remitente desconocido añadiéndolo a una lista de denegados?
DMARC no tiene lista de denegados. Controlas los resultados mediante tu política: los remitentes legítimos se autentican con alineación, y todo lo demás falla. Con una política reject, los receptores que respetan DMARC rechazan o envían a spam el correo que falla. No puedes impedir que alguien envíe con tu dominio, solo hacer que ese correo falle en los receptores que aplican tu política.
Identificar quién envía con tu dominio es la mitad de la higiene del correo; la otra mitad es la lista a la que envías. El plan gratuito de la página de precios te da 100 créditos para ejecutar la verificación completa en una lista, y el verificador de correo gratuito cubre direcciones sueltas. Un buen panorama de autenticación sigue necesitando una lista sana detrás.
