Envía desde los dos. Mantén en tu dominio raíz la dirección que ven tus destinatarios y traslada la identidad técnica de envío, es decir el Return-Path y el dominio que firma con DKIM, a un subdominio reservado para un solo tipo de correo.
Esto parece una disyuntiva porque “desde qué dominio envío” son en realidad cuatro decisiones distintas, y casi todas las guías mueven una sin decir cuál. Cuando separas las cuatro, la mayor parte del desacuerdo de los hilos se disuelve, y con él la ansiedad: si envías menos de unos 5.000 mensajes de marketing al mes, o tu volumen de marketing no domina el resto de tu correo, la respuesta correcta es dejar tu configuración en paz y dedicar la tarde a tu lista.
Aquí está la decisión completa, antes del razonamiento que la sostiene.
| Tu situación | Qué hacer |
|---|---|
| Aún no envías, o envías menos de unos 5.000 mensajes de marketing al mes | Quédate en el dominio raíz. Publica SPF, DKIM y DMARC como toca y mantén la lista limpia. Partir en dos una señal pequeña te deja con dos identidades poco observadas en lugar de una caliente. |
| Tu volumen de marketing es varias veces el de tu correo corporativo y transaccional juntos | Sepáralos. Sobre news.yourbrand.com el sobre y DKIM de marketing, sobre txn.yourbrand.com el transaccional, el correo corporativo se queda en la raíz, y todo From: visible se queda en la raíz. |
| Ya envías desde la raíz sin problemas y con una tasa de spam en Postmaster Tools por debajo del 0,10% | No migres. Renunciarías a una identidad de envío caliente para comprar un beneficio que hoy no puedes medir. Añade el subdominio la próxima vez que cambies de plataforma, cuando la rampa vaya a ocurrir de todos modos. |
| Ya envías desde la raíz y tus respuestas uno a uno acaban en spam | Sepáralos, y entiende que la separación por sí sola no es la solución. El comportamiento que causó el daño viaja contigo. |
| Tu plataforma no puede alinear sobre un subdominio | Quédate en la raíz, o cambia antes de plan en la plataforma. Un subdominio que no puede alinear es peor que un dominio raíz que sí puede. |
| Prospección en frío | Un dominio aparte, no un subdominio. Aquí la respuesta se invierte de verdad, y te cuesta algo. |
Un subdominio es news.yourbrand.com. Un dominio parecido es yourbrand-news.com
Un subdominio vive por debajo de un dominio que ya posees, así que nadie de fuera de tu organización puede crear uno, mientras que un dominio parecido o “primo” es un registro independiente que los destinatarios y los filtros no tienen forma de atribuirte. La mitad de los consejos contradictorios sobre este tema viene de gente que usa la palabra “dominio” para las dos cosas.
Tu dominio organizativo es el nombre registrable que pagas, yourbrand.com. Todo lo que queda a su izquierda es un subdominio que creas con un registro DNS y sin comprar nada más: news.yourbrand.com, txn.yourbrand.com, links.yourbrand.com. Un dominio primo como yourbrand-news.com o yourbrandmail.com es un segundo registro sin relación criptográfica ni administrativa con el primero.
Esa distinción es el argumento más fuerte a favor de los subdominios, y no tiene nada que ver con la puntuación de reputación. Un subdominio no lo puede falsificar alguien de fuera. M3AAWG desaconseja los dominios primos justo por eso: a los destinatarios y a los sistemas antiabuso les parecen campañas de phishing, porque es exactamente lo que registran los atacantes. Los tres registros que necesita un nombre de envío son los mismos en cualquiera de los dos casos, y la autenticación del correo funciona igual sobre un subdominio.
Un mito que conviene despejar antes de la mecánica. Cambiar el nombre del buzón delante de la @, de info@ a hello@, no es un subdominio y no separa nada. Todos los identificadores de reputación que publican los proveedores de correo son un dominio o una dirección IP.
Un mensaje lleva cuatro dominios, y solo uno es el que se discute
Cada mensaje que envías expone cuatro dominios que se cambian por separado: el dominio From: visible, el dominio Return-Path del sobre contra el que se comprueba SPF de verdad, el dominio que firma con DKIM en la etiqueta d= y el nombre de host de tus enlaces con seguimiento. “Usa un subdominio” significa al menos cuatro cosas distintas según cuál de ellos se mueva.
Este marco de cuatro superficies viene de Laura Atkins, de Word to the Wise, y por sí solo disuelve casi toda la discusión.
| Ranura de dominio | Dónde vive | Visible para el destinatario | Para qué se usa |
|---|---|---|---|
Dominio From: visible | la cabecera From: | Sí, es la dirección que se ve en la bandeja | El objetivo de alineación de DMARC, y lo que leen los destinatarios y los filtros de consumo |
| Return-Path del sobre | el MAIL FROM de SMTP, se muestra como Return-Path: | Solo si abren los detalles | SPF se evalúa contra esto y nada más, además del enrutado de rebotes |
| Dominio que firma con DKIM | d= en la cabecera DKIM-Signature | No | La identidad que asume la responsabilidad del mensaje, y a lo que está vinculado el informe de reputación de dominio de Google |
| Host de enlaces y seguimiento | nombres de host en el cuerpo HTML | En la barra de estado, al pasar el ratón | Las listas negras de dominios lo leen del cuerpo durante la inspección de contenido |
Tres de esos cuatro pueden ser un subdominio mientras el From: visible se queda en tu dominio raíz. Eso no es un apaño, es lo que los estándares pretenden. El propio ejemplo trabajado de M3AAWG combina un From: de service@mybrand.com con un Return-Path de bounce@bounce.mybrand.com, y pasa DMARC porque la alineación relajada solo exige que coincidan los dominios organizativos.
A la auditoría de abajo la llamo la comprobación Unspam de cuatro dominios: lee cuatro valores de un solo mensaje entregado y sabrás exactamente qué aísla tu configuración actual. Lleva más o menos un minuto con el analizador de cabeceras de correo gratuito.
| Lee esto | Una separación sana se ve así | Si en cambio se ve así |
|---|---|---|
From: | news@yourbrand.com | El dominio de la propia plataforma, o sea que no estás enviando como tú en absoluto |
Return-Path: | ...@news.yourbrand.com | ...@sendgrid.net, ...@mcsv.net, ...@hubspotemail.net: SPF no puede alinear, y DMARC está pasando solo con DKIM |
DKIM-Signature: d= | news.yourbrand.com o yourbrand.com | El dominio de la plataforma, o sea que la reputación que estás construyendo es de tu proveedor |
| host de enlaces con seguimiento | links.yourbrand.com | Un host de seguimiento compartido del proveedor, así que compartes superficie de listas negras con todos los demás clientes que hay en él |
Esa última fila es una decisión aparte con sus propias consecuencias, tratada en seguimiento de enlaces y entregabilidad.
Qué aísla un subdominio de envío y qué cruza igualmente
Un subdominio de envío te compra autenticación separada, informes separados y un identificador de reputación distinto que los receptores documentan que pueden juzgar de forma independiente. Lo que no te compra es un cortafuegos, y no es un borrón y cuenta nueva.
Qué se separa de verdad
SPF no se hereda. Cada registro SPF vive en el nombre exacto al que se refiere, así que news.yourbrand.com se rige por su propio registro o por ninguno.
DKIM es lo que decida quien firma. La clave se consulta en <selector>._domainkey.<the d= domain>, así que la identidad que firma es una decisión deliberada de configuración y no una propiedad del mensaje.
Los informes van por dominio autenticado. El informe de reputación de dominio de Google cubre solo el dominio exacto usado para autenticar con DKIM o SPF, y los subdominios se pueden añadir a Postmaster Tools como propiedades independientes. Yahoo dice sin rodeos que cada IP y cada dominio DKIM tiene una reputación, y sus buenas prácticas piden a los remitentes segregar los flujos por función.
Los estándares lo recomiendan por su nombre. El RFC 5863 aconseja subdominios d= distintos para flujos de tráfico distintos, y usa marketing.example.com y transaction.example.com como ejemplo, precisamente para que los receptores puedan hacer valoraciones diferenciadas. Microsoft va más allá y recomienda un subdominio para el correo masivo con el motivo dicho a las claras: no quieres que los problemas con el correo de esos servicios afecten a la reputación del correo que envían los usuarios de tu dominio principal. Es el respaldo documentado por un proveedor más fuerte que existe, y merece la pena saber que las directrices para remitentes de Google no usan la palabra “subdominio” ni una vez.
Qué cruza la frontera igualmente
Seis mecanismos se saltan la frontera del subdominio por completo, y entre ellos explican todos los casos en que un remitente hizo bien la separación y aun así se llevó el golpe.
| Mecanismo | Dirección | Qué significa |
|---|---|---|
| IP de envío compartidas | En los dos sentidos | Dos subdominios en un mismo grupo de IP no están separados en ningún receptor que filtre sobre todo por IP |
| Host de seguimiento de clics compartido | En los dos sentidos | Un dominio From: impecable puede filtrarse igualmente por el host del enlace, porque las listas negras leen dominios del cuerpo |
| Entrada de dominio en listas negras | Del padre al hijo | Una entrada del dominio registrable devuelve “listado” para todos los subdominios que hay debajo |
| Estado de cumplimiento de Google | Del hijo al padre | El cumplimiento se informa solo para dominios principales, usando datos de sus subdominios |
| El umbral de remitente masivo de Google | Del hijo al padre | Los 5.000 mensajes al día se cuentan en todo el dominio principal, y la clasificación no caduca nunca |
Un From: que se quedó en la raíz | Del hijo al padre | Si solo se movió el sobre, el dominio que los destinatarios ven y contra el que denuncian sigue siendo tu raíz |
La propia aritmética de Google hace concreto el umbral de remitente masivo: 2.500 mensajes al día desde tu raíz más 2.500 desde un subdominio te convierten en remitente masivo, para siempre. Separar flujos no separa ese recuento. El conjunto completo de obligaciones que se derivan está en los requisitos para remitentes de Gmail y Yahoo.
La protección es asimétrica, y va en el sentido útil
Una entrada en news.yourbrand.com no lista automáticamente yourbrand.com, mientras que una entrada en yourbrand.com devuelve “listado” para todos los subdominios que hay debajo, incluido el que lleva tus recibos. Spamhaus lista a nivel de dominio principal y el comodín funciona solo hacia abajo.
Para la mayoría de remitentes esa asimetría va en el sentido correcto, porque el flujo con más probabilidades de ganarse una entrada es el masivo, y el correo que menos quieres perder es todo lo demás. También explica por qué “un subdominio protege mi dominio principal” y “separar reputación con subdominios no existe” son dos posturas defendibles: la primera habla de la dirección que funciona, la segunda de la que no.
La lista negra en sí es uno de varios mecanismos, y las comprobaciones de dominio que la revelan se ejecutan a demanda, no de forma continua. Entre los dominios que analizamos, el 6% aparece en una lista negra de IP, y a una entrada de IP le da igual desde cuál de tus dominios salió el mensaje.
Lo que nadie documenta es justo la parte que los remitentes más quieren saber: cuánto pesa la reputación de un dominio padre sobre la de un hijo en la decisión de filtrado misma. El RFC 5863 admite el punto en lugar de resolverlo, y observa que un receptor podría usar solo alguna porción a la derecha del identificador y que quien firma no puede saber cuál. Trata cualquier número seguro sobre esto como una invención.
Qué le pasa al correo de tus empleados cuando una campaña se agria
El correo del día a día de tu dominio raíz puede empezar de verdad a caer en spam por culpa de un envío de marketing, y los mecanismos son enumerables, no misteriosos. Este es el fallo que hace que toda la pregunta merezca la pena, y el que las guías que compiten se saltan.
Hay cuatro vías. IP de envío compartidas, así que los dos flujos nunca estuvieron separados en la capa que importaba. Un historial de cumplimiento guardado en tu dominio principal, alimentado con datos del subdominio. Una entrada en listas negras que cayó sobre el dominio registrable y bajó con el comodín. Y un From: visible que nunca salió de la raíz, que es la más habitual de las cuatro por mucha diferencia.
La forma que describen los remitentes es siempre la misma: un flujo de notificaciones de poco volumen recoge un puñado de denuncias, que es un porcentaje grande de un denominador pequeño, y las respuestas corporativas se quedan en spam durante semanas. El alias “Send As” de Google Workspace lo empeora al poner el correo de los empleados y el de las campañas sobre la misma identidad visible, un patrón tratado en la guía de entregabilidad de Mailchimp.
Los tres flujos, y desde dónde debería enviar cada uno
Separa el correo corporativo, el de marketing y el transaccional en tres identidades de envío, mantén las tres direcciones From: visibles en tu dominio raíz y trata la prospección en frío como un cuarto caso con otra respuesta.
| Flujo | From: visible | Return-Path | DKIM d= | Por qué |
|---|---|---|---|---|
| Correo de empleados y uno a uno | you@yourbrand.com | dominio raíz | yourbrand.com | No muevas esto nunca. Es el correo que no puedes permitirte volver a calentar. |
| Marketing y boletines | news@yourbrand.com | bounce@news.yourbrand.com | news.yourbrand.com | Alinea con DMARC relajado porque los dominios organizativos coinciden |
| Transaccional | alerts@yourbrand.com | bounce@txn.yourbrand.com | txn.yourbrand.com | Para que una campaña mala no pueda tumbar con ella las recuperaciones de contraseña |
| Seguimiento de clics | no aplica | no aplica | no aplica | links.yourbrand.com, un subdominio distinto de los de envío |
| Prospección en frío | dominio aparte | dominio aparte | dominio aparte | Otra respuesta, otros motivos y un compromiso real |
Mantener los recibos y las recuperaciones de contraseña lejos del volumen de campañas es la separación que sale a cuenta con más fiabilidad, y es la que más importa a los remitentes SaaS, donde un envío promocional y un código de acceso viajan por el mismo tubo por defecto.
Hay un matiz que merece nombrarse, porque invierte el consejo habitual. La regla que usan los profesionales es una proporción, no un absoluto: el aislamiento empieza a valer lo que cuesta cuando el volumen de marketing es varias veces el transaccional. Eso implica que el aislamiento es menos útil con poco volumen, que es lo contrario de lo que se suele contar a quien empieza.
En prospección en frío la respuesta cambia a un dominio aparte
Para la prospección en frío la respuesta se invierte hacia un dominio registrado del todo aparte, y el motivo es mecánico: un registro independiente corta el vínculo de dominio organizativo del que dependen la alineación DMARC, las entradas en listas negras a nivel de dominio principal y el recuento de mensajes por dominio principal de Google. Un subdominio mantiene todos y cada uno de esos vínculos intactos, que es el sentido de un subdominio y el problema para el correo en frío.
Ese consejo viene con un coste que casi nunca se pone al lado. M3AAWG desaconseja exactamente este patrón, porque un dominio que no está conectado de forma demostrable con tu marca suena a phishing para los destinatarios y para los sistemas antiabuso. Así que el dominio aparte es un compromiso que eliges, no una buena práctica que sigues. Si envías en frío, el manual de prospección en frío cubre el resto de la configuración.
Cuántos subdominios son demasiados
Cada subdominio de envío necesita volumen constante suficiente para construir su propia reputación, así que el techo de la división lo pone tu volumen y no cuántos flujos sepas nombrar. M3AAWG expone la restricción directamente: cada segmento necesita tráfico suficiente y relativamente constante para establecer su propia reputación.
Dividir demasiado poco falla de una manera: una campaña mala se lleva tus recuperaciones de contraseña. Dividir demasiado falla de una peor. Spamhaus describe muchos dominios y direcciones IP que cambian rápido como el patrón snowshoe, señala que quienes envían correo masivo con buena reputación usan muchos menos dominios que los snowshoers, y trata en consecuencia a los dominios que se comportan como snowshoers. El RFC 5863 hace el mismo apunte desde el otro lado, y avisa de que una granularidad demasiado fina impide que flujos relacionados se beneficien de una reputación agregada.
Dos o tres subdominios de envío, nombrados según el tráfico que llevan, es donde debería parar casi todo el mundo.
Qué tienes que publicar en el subdominio, registro a registro
SPF y DKIM no se heredan del dominio padre y DMARC sí, así que un subdominio de envío nuevo necesita su propio registro SPF y normalmente su propia clave DKIM, mientras que el registro DMARC del padre ya lo cubre.
SPF va donde van los rebotes, no donde está el From
SPF se evalúa contra el dominio MAIL FROM del sobre, nunca contra la cabecera From:, así que publica el registro en el nombre al que vuelven tus rebotes. Si tu plataforma rebota en bounce.yourbrand.com, ese es el nombre que necesita v=spf1, y puede que el subdominio de tu cabecera From: no necesite ningún registro SPF.
Un subdominio sin registro SPF no falla SPF, devuelve none, que es un resultado distinto con el mismo efecto práctico: DKIM tiene que cargar solo con la alineación. En nuestros datos de benchmark, el 93% publica un registro SPF válido, y es el 7% que sigue sin uno el que se queda pillado aquí, porque un subdominio de envío recién creado entra en ese grupo en el momento en que lo creas.
Aquí se esconde una ventaja de ingeniería real. Cada dominio tiene su propio presupuesto independiente de diez consultas, así que sacar el include de una plataforma de marketing de tu registro raíz alivia la raíz, y un permerror en uno no toca al otro. Si tu registro raíz está cerca del límite, esta es la salida más limpia. Los detalles están en la guía de SPF, y el comprobador de SPF gratuito te cuenta las consultas en el nombre que le indiques.
DKIM solo importa en el subdominio si firmas como el subdominio
La clave DKIM se consulta en <selector>._domainkey.<the d= domain>, y d= es lo que la plataforma que firma tenga configurado, así que un subdominio no necesita clave propia si firmas a propósito con la raíz. Este es el paso que la gente se salta: cambiar solo el dominio From: visible no basta, porque el correo tiene que ir firmado con DKIM por el subdominio para que exista alguna separación.
De los dominios que comprobamos, el 90% firma su correo con una clave DKIM que funciona y el 10% sin ninguna. Confirma con qué nombre firma el tuyo con el comprobador de DKIM, y lee la guía de DKIM si estás eligiendo un selector por primera vez.
DMARC ya cubre el subdominio
Un registro DMARC en yourbrand.com ya gobierna todos los subdominios que no tengan registro propio, aplicando la política sp= si esa etiqueta está presente y la política p= si no lo está. La alineación es relajada por defecto, y por eso From: news@yourbrand.com firmado por d=news.yourbrand.com pasa sin ninguna configuración especial. El modo estricto (adkim=s, aspf=s) es la opción que activas tú, y convierte tu elección de subdominio en una restricción dura y en un fallo autoinfligido habitual, que la guía de fallos de DMARC recorre caso por caso.
En la etiqueta sp= viven dos trampas, y las dos son contraintuitivas. sp= se ignora en cualquier registro publicado en un subdominio, porque el descubrimiento de política encuentra ese registro primero y deja de buscar. Y publicar un registro DMARC en el subdominio sustituye el registro del padre para ese nombre, direcciones de informes incluidas, así que omitir rua= te ciega justo en el flujo que querías vigilar. La guía de DMARC cubre las etiquetas al completo, y el comprobador de DMARC gratuito muestra qué registro resuelve de verdad un nombre dado.
El movimiento útil mientras se calienta un subdominio de envío nuevo es p=reject en la raíz con sp=none al lado, que te mantiene la aplicación mientras el flujo nuevo encuentra su sitio. Un coste que hay que conocer antes de hacerlo: sp=none en cualquier punto de la cadena detiene el procesamiento de BIMI, así que el logo de marca no se mostrará mientras ese registro esté vivo. Entre los dominios que analizamos, el 50% ya publica una política DMARC y el 50% sigue sin ninguna, así que para la mitad de los remitentes esta pregunta ni ha empezado.
Una nota sobre estándares que importa para cualquier cosa que leas sobre este tema. El RFC 9989 sustituyó al RFC 7489 en mayo de 2026, cambió la Public Suffix List por un recorrido del árbol DNS, eliminó la etiqueta pct= e hizo opcional p=. La adopción por parte de los receptores es otra cosa: la documentación de DMARC de Microsoft se actualizó en julio de 2026 y sigue citando el RFC 7489 y sigue documentando pct=. Da por supuesto el modelo antiguo de dominio organizativo en la práctica, y no recurras a la nueva etiqueta psd=n como herramienta de aislamiento, porque rompe la alineación relajada contra el d= de tu padre y nadie ha confirmado que los receptores la respeten.
Respuestas, MX y el rebote que nadie ve
Ningún estándar exige un registro MX en un subdominio de envío, y ahí está justo el problema. Sin registro MX, una respuesta a news.yourbrand.com no se rechaza con estruendo; el servidor de correo de quien responde intenta la entrega en lo que apunte el registro A de ese nombre, normalmente un servidor web que no está escuchando correo, así que la respuesta se queda en una cola de reintentos y rebota de vuelta a quien la escribió días después, o se la traga algo de allí que sí acepta. En cualquiera de los dos casos no te llega nunca.
La guía de M3AAWG no deja lugar a dudas aquí: todo dominio usado en Return-Path, From:, Sender o Reply-To debería tener un registro MX que funcione, y abuse@ y postmaster@ tienen que existir, leerse y no rebotar nunca. Esta es la razón práctica por la que Klaviyo dice a sus clientes que mantengan la dirección From: en el dominio raíz. Apunta la consulta de registros MX a cualquier subdominio de envío que crees y confirma que el correo resuelve en algún sitio real.
¿Un subdominio nuevo necesita su propio calentamiento?
Sí, y el motivo no es que los receptores no hayan visto nunca el subdominio. Es que cambiaste la combinación de señales que ya estaban puntuando, y un dominio de envío nuevo emparejado con tus direcciones IP existentes es una combinación nueva. Iterable lo plantea como una combinación, que es exactamente lo correcto.
Cuenta con dos a cuatro semanas para un subdominio añadido a un programa que ya está caliente, en línea con la rampa de la lista de comprobación de entregabilidad, y más cerca de las seis semanas que M3AAWG cita como media cuando el volumen o la audiencia también son nuevos. M3AAWG trata un cambio de dominio en cualquier sentido como motivo para una rampa nueva.
La trampa operativa más afilada no tiene nada que ver con la duración. Algunas plataformas limitan el calentamiento por IP y no por dominio, así que un subdominio nuevo asignado a una IP ya caliente no recibe ninguna rampa a menos que la construyas a propósito. Comprueba qué hace la tuya antes de fiarte de sus valores por defecto.
Desconfía de cualquier escalera concreta que te den, la nuestra incluida. Ningún conjunto de datos publicado ni declaración de proveedor respalda un calendario de volumen diario concreto para un dominio de envío nuevo, y las cifras incompatibles que circulan, de diez al día a mil al día en la primera semana, son la prueba de que nadie está midiendo. Las variables que de verdad deciden son tu volumen objetivo en régimen y lo interesada que esté tu lista. La guía de calentamiento de dominio cubre la mecánica.
Migrar desde la raíz: el coste que nadie pone en la factura
Mover un programa establecido de dominio raíz a un subdominio te cuesta una rampa nueva sobre una combinación nueva, y no te compra nada si el comportamiento de envío que causó tu problema se viene contigo.
Tres cosas que comprobar antes de empezar. Una reputación desconocida empieza más cerca de mala que de neutra, según Spamhaus, así que el nombre nuevo no es un empezar de cero. Un subdominio nuevo de un dominio que ahora mismo está en listas negras ya aparece listado antes de su primer envío, así que comprueba primero la raíz con el comprobador de listas negras de dominios. Y confirma que el subdominio que elegiste no arrastra registros A, CNAME o MX de algún proyecto anterior.
Tu plataforma también puede decidir esto por ti, y hay dos casos que salen una y otra vez. En las IP compartidas de HubSpot el return-path se queda en hubspotemail.net, así que SPF no puede alinear sobre tu subdominio; solo los clientes con IP dedicada pueden configurar una dirección de retorno de sobre propia, algo que cubre la guía de entregabilidad de HubSpot. Amazon SES necesita un subdominio MAIL FROM personalizado con exactamente un registro MX más su propio registro SPF antes de que el Return-Path sea tuyo, detallado en la guía de Amazon SES. Un MAIL FROM personalizado mal configurado es peor que uno por defecto que funciona.
Si puedes, haz la migración durante un cambio de plataforma, cuando la rampa va a ocurrir de todos modos y solo la pagas una vez. Y por repetir el caso en el que está de verdad la mayoría de quienes leen esta sección: si hoy envías desde tu dominio raíz, tu tasa de spam está por debajo del 0,10% y nada acaba en spam, no migres.
Qué hace tu ESP en realidad con el subdominio
La mayoría de los requisitos de subdominio de las plataformas existen porque su proceso de alta usa delegación por CNAME o un return-path que controla el proveedor, no porque alguien haya medido una mejora de entregabilidad, y dos de las mayores dan instrucciones directamente opuestas sobre dónde va el From: visible.
| Plataforma | Dónde va el From: visible | Qué lleva el subdominio en realidad |
|---|---|---|
| Klaviyo | Dominio raíz, y te lo dice, porque si no las respuestas dejan de llegarte | Return-Path y DKIM en un subdominio send., más un host de clics aparte |
| HubSpot | Tiene que coincidir con el subdominio conectado | DKIM y el dominio de envío conectado, con el return-path quedándose en hubspotemail.net en las IP compartidas |
| Mailchimp | Sin postura en ningún sentido | El Return-Path es siempre un dominio de Mailchimp, así que DMARC pasa solo con DKIM |
| SendGrid | El dominio raíz es lo que escribes durante la Domain Authentication | Un CNAME em####. autogenerado que nunca elegiste |
| Amazon SES | Tu propio dominio | Un subdominio MAIL FROM personalizado que necesita un registro MX y su propio SPF |
| Customer.io | Dominio raíz, sin tocar | Un subdominio de tu propio dominio específico de la cuenta para return-path, SPF y firma, nombrado por ellos y no por ti |
| MailerSend | Cualquier subdominio de un dominio verificado | Nada por defecto: el correo del subdominio se firma con el dominio padre |
La fila de MailerSend merece una pausa, porque es el caso en el que seguir el consejo no compra literalmente nada: el correo sigue firmado con el dominio padre, así que nunca existe una identidad separada. Los proveedores también se contradicen a sí mismos. La propia comunidad de Klaviyo ha publicado las dos posturas con catorce meses de diferencia, una respuesta de soporte diciendo que la reputación se adhiere al dominio raíz y no al subdominio y otra diciendo que un subdominio de envío aísla la actividad de marketing, y Mailgun se contradice entre dos de sus propias páginas de documentación. Cuando los proveedores se contradicen a sí mismos, la regla del subdominio es una restricción de su arquitectura y no una ley de la entregabilidad, y la lectura honesta es que las dos respuestas tienen parte de razón: el aislamiento es real para el identificador de reputación de DKIM y para la dirección de las listas negras, y no existe para las IP de envío compartidas ni para el historial de cumplimiento que Google guarda en tu dominio principal.
Enviar correo masivo desde tu dominio raíz no perjudica a tu SEO
Ningún motor de búsqueda ni proveedor de correo documenta vínculo alguno entre el envío de correo y las posiciones de búsqueda, en ningún sentido, y la métrica que la gente suele nombrar no es una que Google guarde. Las políticas de spam de búsqueda de Google no mencionan el correo, ni los servidores de correo, ni los registros de autenticación en ninguna parte, y la autoridad de dominio es una puntuación de un proveedor externo, no una señal de Google.
La versión exacta de la preocupación es de alcance, no de posiciones. Una entrada de dominio en listas negras puede aplicarse a nivel de resolutor para cualquiera que esté detrás de un cortafuegos DNS construido sobre esos feeds, lo que deja tu web inaccesible para esos usuarios mientras tus posiciones se quedan exactamente donde estaban. Los términos de servicio de tu hosting o de tu plataforma son un tercer riesgo, aparte. Ninguno de estos es SEO.
Comprueba desde dónde estás enviando en realidad
Pasa la comprobación Unspam de cuatro dominios por el último mensaje que entregó tu programa: el dominio From: visible, el dominio Return-Path, el valor d= de DKIM y el host de un enlace con seguimiento. La mayoría de quienes creen haber separado sus flujos resulta que solo movieron el primero.
Después comprueba los nombres en sí. Pasa el dominio raíz y cada subdominio de envío por separado por el chequeo de salud del correo, porque una raíz limpia no te dice nada de un subdominio que no tiene registro SPF ni MX. La media global está ahora en 89/100, y un subdominio de envío recién creado no va a empezar ahí.
Cuando los registros estén bien, envía el mensaje y no la teoría. Pasa la campaña que estás a punto de enviar por el test de spam de Unspam gratuito y lee el panel de autenticación: si el Return-Path y los valores d= son el subdominio que elegiste y el From: sigue siendo tu raíz, la separación es real, y verás dónde aterriza de verdad el mensaje antes de que lo haga un suscriptor.
