Quién puede enviar con tu dominio y cómo demostrarlo

Antes de enviar una campaña, necesitas saber qué plataformas usan tu dominio, con qué identidad firman y quién puede demostrar que cada flujo es legítimo. Publicar registros SPF, DKIM y DMARC sin ese inventario puede dejar fuera al CRM, la tienda, el sistema de facturación o los correos transaccionales que nadie recordó mencionar.

La autenticación no empieza copiando un TXT. Empieza con un mapa de remitentes y termina con mensajes de prueba cuyos encabezados confirman tres cosas: la infraestructura estaba autorizada, el contenido conservó una firma válida y el dominio visible quedó alineado. Sólo después conviene endurecer una política.

Empieza por un mapa de remitentes, no por DNS

Una empresa rara vez envía desde un solo sistema. El correo corporativo puede salir de Google Workspace o Microsoft 365; marketing usa otra plataforma; ecommerce confirma pedidos; el CRM automatiza seguimientos; soporte abre tickets y el sitio entrega formularios. Todos pueden mostrar el mismo dominio en el campo “De”, aunque la ruta técnica sea diferente.

Reúne a marketing, TI, operaciones y a quien administra cada proveedor. Por cada flujo, registra:

1. Propósito: campaña, transacción, notificación, soporte o comunicación personal.
2. Plataforma y cuenta: proveedor exacto y espacio de trabajo que origina el envío.
3. Dominio visible: el que recibe la persona en el encabezado From.
4. Dominio de retorno: el usado en MAIL FROM o Return-Path.
5. Firma DKIM: dominio d= y selector configurado.
6. Autorización SPF: mecanismo o include que representa al proveedor.
7. Volumen y destinatarios: suficiente para distinguir un flujo ocasional de uno masivo, sin asumir que un volumen bajo exime de buenas prácticas.
8. Responsable: persona que aprueba cambios y puede abrir un caso con el proveedor.
9. Evidencia: un mensaje reciente, sus encabezados completos y el resultado de autenticación.
10. Plan de retiro: fecha o condición para eliminar plataformas que ya no deben enviar.

El objetivo no es coleccionar nombres comerciales. Es relacionar cada mensaje real con una identidad técnica y un dueño. Si no puedes obtener una prueba de un remitente, márcalo como pendiente; no lo autorices por intuición ni lo elimines hasta confirmar qué proceso depende de él.

Este inventario también ayuda a separar adquisición de retención. Una estrategia de email marketing puede compartir dominio con una automatización de retención, pero no necesariamente proveedor, ritmo, reputación ni responsable.

SPF, DKIM y DMARC responden preguntas distintas

Los tres mecanismos se complementan. Que uno pase no implica que los otros estén bien, y ver un registro en DNS no demuestra que el mensaje recibido lo haya usado.

SPF autoriza una ruta de envío

SPF, definido en RFC 7208, permite que un dominio publique qué servidores pueden usarlo en la identidad SMTP MAIL FROM o HELO. Esa identidad suele aparecer como Return-Path; no es necesariamente el dominio visible que lee la persona.

Por eso “SPF pasó” todavía no significa “el correo visible está alineado”. Además, sumar proveedores sin retirar los anteriores vuelve frágil el registro. RFC 7208 limita a diez los términos que provocan consultas DNS durante la evaluación; encadenar include sin control puede producir un error permanente. Mantén un solo registro SPF válido por dominio y documenta qué autoriza cada mecanismo.

DKIM firma el mensaje con un dominio

DKIM, definido en RFC 6376, agrega una firma que el receptor verifica con una clave pública en DNS. La firma identifica un dominio mediante d= y una clave mediante el selector s=. Sirve para comprobar que las partes firmadas del mensaje no cambiaron de una forma incompatible con la firma y que quien envió tenía acceso a la clave privada correspondiente.

Cada plataforma legítima debe firmar con una identidad que puedas reconocer y rotar. Una firma que usa solamente el dominio genérico del proveedor puede pasar DKIM, pero no necesariamente ayuda a alinear el dominio que aparece en From.

DMARC evalúa alineación y publica una política

DMARC, actualizado por RFC 9989 en mayo de 2026, toma el dominio visible del autor y comprueba si está alineado con un identificador autenticado por SPF o DKIM. También permite publicar una política para mensajes que no cumplen y solicitar reportes sobre el uso del dominio.

La distinción crucial es entre autenticar y alinear. Un proveedor puede pasar SPF con su propio dominio de retorno y DKIM con su propio dominio de firma; si ninguno se alinea con el dominio visible de la marca, DMARC falla. La configuración correcta debe conseguir que por lo menos una ruta autenticada —y, cuando sea posible, ambas— represente el dominio que la persona reconoce.

La política se endurece después de reconocer el tráfico

Una política p=none permite observar resultados sin pedir cuarentena o rechazo por DMARC. No convierte la configuración en “terminada”; crea una etapa para descubrir remitentes, corregir alineación y establecer responsables. Pasar directamente a p=reject con un inventario incompleto puede bloquear correo legítimo.

Trabaja con puertas de decisión, no con una fecha arbitraria:

1. Descubrimiento: publica un registro válido, dirige reportes agregados a un buzón o servicio controlado e identifica todas las fuentes.
2. Corrección: habilita DKIM, ajusta el dominio de retorno cuando corresponda, elimina autorizaciones obsoletas y prueba cada flujo.
3. Cobertura: confirma que campañas, transacciones, soporte, formularios y correo humano tienen dueño y evidencia.
4. Aplicación: avanza a una política más estricta sólo cuando los remitentes legítimos estén alineados y exista una ruta para atender fallos.
5. Mantenimiento: revisa el mapa al contratar, migrar o retirar cualquier plataforma que envíe correo.

No pegues ejemplos genéricos de SPF o DMARC en producción. Los dominios, selectores, mecanismos, direcciones de reporte y políticas deben salir del inventario real y de la documentación del proveedor. Trata el cambio de DNS como una modificación con revisión, respaldo del valor anterior y hora registrada.

Prueba mensajes reales en cada recorrido

Un comprobador de DNS confirma que el registro existe; no demuestra que una campaña o confirmación de pedido salga con las identidades esperadas. Envía un mensaje controlado desde cada flujo hacia cuentas de prueba en los proveedores de destino que importan y conserva los encabezados completos.

Busca una cadena coherente:

• spf=pass para el dominio de retorno que esperabas;
• dkim=pass y un header.d reconocido;
• dmarc=pass para el dominio visible en header.from;
• un From y un Reply-To válidos para el propósito del mensaje;
• un resultado repetible en campaña, transacción y automatización, no sólo en un correo manual.

Si una prueba falla, asigna el problema al eslabón correcto. SPF puede fallar porque falta una fuente o porque la evaluación excede sus límites. DKIM puede fallar porque la plataforma no firma, usa otro selector o el mensaje se altera. DMARC puede fallar aunque SPF y DKIM pasen cuando ninguno está alineado con el dominio visible.

Guarda proveedor, fecha, mensaje, encabezados, resultado, responsable y acción tomada. Esa evidencia convierte una configuración invisible en un control auditable. Si el correo forma parte de un recorrido que también toca formularios o CRM, el mapa debe enlazarse con la definición de cómo viajan los datos entre campañas, formularios y CRM, sin confundir entrega del mensaje con entrega del prospecto.

Los requisitos del receptor son un piso, no una estrategia

Los grandes proveedores ya exigen autenticación reforzada a remitentes de alto volumen. Gmail requiere SPF y DKIM, DMARC y alineación para quienes envían más de 5,000 mensajes diarios a cuentas personales; admite p=none como política mínima mientras se corrige el programa. Yahoo exige a remitentes masivos SPF, DKIM, una política DMARC válida y alineación. Microsoft aplica requisitos equivalentes a dominios que alcanzan 5,000 mensajes hacia sus servicios de correo para consumidores.

Esos umbrales no son una invitación a esperar. Autenticar antes de crecer reduce la probabilidad de descubrir una dependencia olvidada justo cuando aumenta el volumen. También evita repartir la misma identidad entre proveedores sin saber cuál controla cada firma.

Para mensajes promocionales, la autenticación tampoco sustituye la baja. Gmail y Yahoo requieren mecanismos fáciles de cancelación para remitentes masivos; RFC 8058 define el método de un clic mediante encabezados firmados con DKIM. El enlace visible, el procesamiento de la solicitud y la supresión posterior deben funcionar de verdad.

Separa autenticación, reputación y consentimiento

SPF, DKIM y DMARC responden quién está autorizado y cómo se relacionan sus dominios. No garantizan llegada a bandeja principal, interés de la audiencia ni cumplimiento jurídico. Un mensaje autenticado todavía puede generar rebotes, quejas o bajas si la lista, la frecuencia o el contenido son deficientes.

La guía de remitentes de Gmail indica que una tasa de spam igual o superior a 0.3% deja a los remitentes masivos sin mitigación; Yahoo también pide mantenerla por debajo de 0.3%. No conviertas ese límite en objetivo: observa quejas, rebotes, bajas y entregas por tipo de mensaje, dominio y proveedor.

Mantén tres expedientes separados:

• Identidad: SPF, DKIM, DMARC, dominios, selectores y pruebas.
• Reputación: rebotes, quejas, bloqueos, frecuencia y señales de los receptores.
• Permiso: fuente del contacto, expectativas comunicadas, preferencias y baja efectiva.

Una implementación de analítica y medición puede reunir esas señales operativas, pero no debe mezclar apertura con consentimiento ni usar la autenticación como prueba de interés.

Decide qué hacer con cada remitente

Clasifica el inventario para que el equipo sepa qué puede cambiar y qué falta demostrar:

• Verde — conservar: propósito vigente, responsable identificado, SPF y DKIM pasan, DMARC alinea y existe una prueba reciente.
• Amarillo — corregir: el flujo es legítimo, pero falta dueño, firma propia, alineación, evidencia o un proceso de baja funcional.
• Rojo — retirar con control: plataforma obsoleta, origen desconocido o autorización sin uso demostrado. Confirma primero que ningún proceso activo dependa de ella; luego elimina accesos, mecanismos SPF, selectores y automatizaciones según corresponda.
• Gris — investigar: aparece en reportes o encabezados, pero nadie reconoce su función. No lo apruebes ni lo bloquees a ciegas: reúne evidencia y asigna un responsable temporal.

El entregable final no es un registro DNS “bonito”. Es un sistema de control: cada remitente tiene propósito, identidad, responsable, prueba y condición de retiro. Así, una campaña nueva no obliga a escoger entre entregar correo o proteger el dominio.

Si necesitas ordenar plataformas, dominios y pruebas antes del siguiente envío, comparte con Albi qué sistemas participan en tu programa de email y revisemos el recorrido completo sin interrumpir los mensajes que el negocio ya necesita.