Cómo un subdominio de envío de correo protege tu reputación

Un subdominio de envío de correo es un nombre de host dedicado —algo como mail.example.com, news.example.com o e.example.com— que utilizas para enviar correo masivo o de marketing en lugar de tu dominio raíz. La clave es el aislamiento: la reputación que tus campañas construyen o queman se queda en el subdominio, de modo que un solo envío fallido no arrastra hacia abajo el correo corporativo y transaccional que sale de example.com. Esta guía cubre cuándo un subdominio de envío merece la pena, cómo funciona en realidad la separación de reputación, cómo autenticarlo con SPF, DKIM y DMARC, y la única advertencia que pilla a todo el mundo: un subdominio nuevo empieza sin reputación alguna.

La respuesta rápida#

Envía distintos tipos de correo desde distintos subdominios, y mantén tu dominio raíz completamente al margen del envío masivo. Una disposición habitual es un subdominio transaccional, un subdominio de marketing y —si lo haces— un subdominio aparte para la captación en frío. Cada subdominio arrastra su propia reputación de remitente, de modo que un pico de quejas de spam en el flujo de marketing no persigue a tus restablecimientos de contraseña y recibos hasta la carpeta de spam. La autenticación es por nombre de host para SPF y DKIM, pero puede gestionarse de forma centralizada mediante la etiqueta sp= de DMARC. La contrapartida: cualquier subdominio nuevo debe calentarse antes de poder enviar a gran volumen, porque para un proveedor de buzones es un desconocido.

Por qué usar un subdominio de envío dedicado#

El argumento a favor de un subdominio de envío se reduce al radio de impacto. Los proveedores de buzones construyen un perfil de reputación para el dominio de tu dirección visible del remitente, y ese perfil es uno de los mayores factores que determinan si tu correo aterriza en la bandeja de entrada o en el spam. Si todo lo que envías —recibos transaccionales, captación comercial y un boletín de 200 000 destinatarios— sale todo desde example.com, entonces esos flujos comparten una única reputación. La tasa de quejas del boletín, los rebotes de la campaña en frío y el compromiso casi perfecto de los recibos se mezclan todos en una sola puntuación.

Esa mezcla está bien hasta que deja de estarlo. En el momento en que un flujo se porta mal —una lista que no limpiaste, un envío de reactivación a contactos inactivos, una campaña comprometida— el daño cae sobre todos los mensajes de ese dominio. Tus clientes dejan de recibir las confirmaciones de pedido porque tu equipo de marketing envió a una lista obsoleta. Aislar el correo arriesgado y de alto volumen en su propio subdominio contiene las consecuencias: si news.example.com sufre limitaciones, example.com y tu flujo transaccional siguen fluyendo.

La protección funciona en ambos sentidos. El correo corporativo de tu dominio raíz —respuestas uno a uno, facturas, contratos— es de bajo volumen y alta confianza, y no quieres que un tropiezo de marketing lo ponga en riesgo. Del mismo modo, no quieres que tu envío masivo se juzgue frente a un dominio raíz que no tiene ningún historial de envío masivo. Separar los flujos permite que cada uno construya la reputación adecuada a cómo se usa realmente.

Cómo funciona en realidad la separación de reputación#

Los proveedores evalúan la reputación en más de un nivel: la IP de envío, el dominio firmante/emisor y el dominio organizativo más amplio. Un subdominio te da una identidad de dominio de envío distinta, de modo que news.example.com acumula su propio historial de volumen, compromiso, quejas e impactos en trampas de spam, en gran medida separado de example.com.

«En gran medida» es la palabra honesta aquí. Un subdominio no es una identidad herméticamente sellada. Los proveedores siguen asociando un subdominio con su dominio padre hasta cierto punto: un dominio con una reputación raíz genuinamente tóxica no se rescatará por completo con levantar un subdominio nuevo, y eso es intencionado, para impedir que los spammers acuñen sin fin nombres de host de aspecto limpio bajo un dominio quemado. Lo que un subdominio sí te da de forma fiable es una superficie de reputación separada para flujos que se comportan bien y que de otro modo se verían arrastrados por otro más ruidoso bajo el mismo techo. Trátalo como un aislante fuerte, no como un cortafuegos.

Como la reputación está anclada al dominio del remitente que ven tus destinatarios, el subdominio solo aísla la reputación si realmente envías desde él: la dirección visible From: tiene que ser algo@news.example.com, no algo@example.com con el subdominio enterrado en la ruta de retorno. Si el dominio del remitente sigue siendo la raíz, el dominio raíz sigue siendo el que gana la reputación.

Una disposición de subdominios que escala#

No hay un único esquema correcto, pero el patrón duradero es separar por tipo de correo, porque los distintos tipos tienen perfiles de riesgo y compromiso fundamentalmente diferentes:

• Transaccional (t.example.com o similar) — recibos, restablecimientos de contraseña, avisos de envío. Se disparan por una acción del usuario, se abren casi siempre y casi nunca generan quejas. Este flujo merece su propia reputación impecable y nunca debería compartir subdominio con el marketing.
• Marketing (news.example.com, mail.example.com) — boletines, promociones, anuncios de producto. Mayor volumen, un compromiso menor y más variable, alguna queja ocasional. Este es el flujo que más merece la pena aislar.
• Captación en frío (un subdominio aparte o, mejor, un dominio completamente aparte) — la categoría de mayor riesgo con diferencia. El correo en frío atrae quejas e impactos en trampas de spam, y muchos remitentes deliberadamente lo mantienen fuera de su dominio de marca principal para que una reputación de captación quemada no pueda afectar al correo del que depende su negocio.

La regla importante es que el transaccional y el marketing nunca compartan reputación. Si no haces nada más, separa esos dos. Mantener cada flujo en su propio subdominio también hace el diagnóstico mucho más fácil: cuando la entregabilidad cae, tu monitorización apunta a un único nombre de host en lugar de obligarte a desenredar cuál de varios flujos mezclados la provocó. Encaja de forma natural con mantener cada lista limpia —consulta cómo limpiar una lista de correo— ya que el aislamiento limita el daño, pero es la higiene la que lo previene.

Autenticar un subdominio de envío#

Todo subdominio de envío necesita el conjunto completo de autenticación —SPF, DKIM y DMARC— igual que un dominio raíz. La trampa que hace tropezar a la gente es que estos registros se comportan de forma distinta en lo que respecta a la herencia. Para los conceptos que hay detrás de cada registro, consulta la explicación de SPF, DKIM y DMARC; lo que sigue es cómo se aplican específicamente a los subdominios.

SPF no se hereda. Un subdominio no usa el registro SPF de su dominio padre. Si example.com publica un registro SPF y mail.example.com no publica ninguno, el subdominio no tiene política SPF alguna: el registro del padre no se aplica. Debes publicar un registro TXT de SPF aparte en el subdominio que indique el servicio que envíe su correo:

mail.example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

DKIM se publica bajo el subdominio. Tu plataforma de envío te da un selector, y la clave pública reside en ese selector bajo el nombre de host de envío. Para el correo de mail.example.com, el registro DKIM se sitúa, por ejemplo, en:

s1._domainkey.mail.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G..."

Firma con d=mail.example.com para que el dominio firmante coincida con el dominio del remitente y el mensaje mantenga la alineación DKIM.

DMARC sí puede heredarse, y esta es la parte útil. Cuando un receptor comprueba DMARC para el correo de mail.example.com, primero busca un registro en _dmarc.mail.example.com. Si no existe ninguno, recurre al registro del dominio organizativo en _dmarc.example.com y aplica la política de subdominio de la etiqueta sp= si está presente; de lo contrario, la política principal p=. Así, un único registro en el dominio organizativo puede gobernar todos los subdominios a la vez:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

Aquí p=reject cubre el propio example.com y sp=reject cubre cada subdominio que carezca de su propio registro. Si quieres que un subdominio ejecute una política diferente —por ejemplo, mantener un subdominio de envío recién lanzado en p=none para monitorización mientras la raíz se queda en reject— publica un registro DMARC dedicado en ese subdominio, que anula el sp= heredado:

_dmarc.mail.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Un apunte más sobre la alineación. La alineación relajada (la predeterminada de DMARC) trata un subdominio y su dominio padre como el mismo dominio organizativo, de modo que un DKIM firmado como d=mail.example.com sigue alineándose con un From: de example.com. Pero como todo el motivo del subdominio es enviar como el subdominio, mantén el dominio del remitente, el d= de DKIM y la ruta de retorno todos en el mismo nombre de host: así quedas alineado tanto bajo las reglas relajadas como estrictas y la reputación aterriza exactamente donde pretendes. Si aún no estás ejecutando DMARC en modo de aplicación, configura DMARC primero a nivel organizativo y deja que sp= extienda la política a tus nuevos subdominios de envío.

La advertencia del calentamiento que nadie se salta#

Un subdominio de envío completamente nuevo tiene cero historial de envíos, lo que significa que no tiene reputación, y no tener reputación, desde la perspectiva de un proveedor de buzones, está más cerca de malo que de bueno. Apunta una gran campaña a un subdominio en frío el primer día e invitarás a la limitación, al envío a la carpeta de spam masivo o directamente a bloqueos, precisamente porque una inundación repentina desde un nombre de host desconocido es lo que parece una operación de spam.

Así que un subdominio nuevo debe calentarse: empieza con poco volumen diario hacia tus destinatarios más comprometidos y activos recientemente, y aumenta de forma gradual a lo largo de varias semanas a medida que el subdominio se gane un buen historial. Enviar a personas que abren y hacen clic les enseña a los proveedores que el subdominio es de fiar; enviar a una lista obsoleta les enseña lo contrario, y en un subdominio nuevo no hay buena voluntad acumulada para absorber el error. Este es también el motivo por el que planificas una migración de subdominio antes de necesitarla: pasar todo tu volumen a un nuevo subdominio de la noche a la mañana desperdicia el margen de calentamiento y puede hundir la entregabilidad durante semanas.

El coste del calentamiento es real, pero es una inversión puntual, y es exactamente por lo que el aislamiento merece la pena: una vez que cada subdominio tiene su propia reputación establecida, fallan de forma independiente. Si estás sopesando un cambio de subdominio como parte de una corrección más amplia de la entregabilidad, la guía de entregabilidad de correo cubre dónde encaja entre las demás palancas, y los requisitos de remitente de Google y Yahoo detallan los umbrales de autenticación y de tasa de quejas que todo nombre de host de envío tiene ahora que superar.

Preguntas frecuentes#

¿Debería enviar correo de marketing desde un subdominio o desde mi dominio principal?#

Desde un subdominio, en casi todos los casos. Enviar marketing masivo desde tu dominio raíz significa que una mala campaña —una lista obsoleta, un pico de quejas— daña la reputación de tu correo transaccional y corporativo también, ya que comparten el mismo dominio del remitente. Un subdominio dedicado como news.example.com aísla ese riesgo para que un tropiezo de marketing no pueda enviar tus recibos y restablecimientos de contraseña al spam. El único coste es calentar el subdominio antes de enviar a gran volumen.

¿Los subdominios heredan SPF y DKIM del dominio raíz?#

No. SPF y DKIM no se heredan: un subdominio sin registro SPF no tiene política SPF alguna, independientemente de lo que publique el dominio padre, y las claves DKIM deben publicarse bajo el nombre de host de envío (por ejemplo, selector._domainkey.mail.example.com). DMARC es la excepción: si un subdominio no tiene su propio registro _dmarc, los receptores aplican la política del dominio organizativo, usando la etiqueta sp= (política de subdominio) si está definida.

¿Qué es la etiqueta sp de DMARC y cuándo debería usarla?#

La etiqueta sp= del registro DMARC de tu dominio organizativo establece la política para los subdominios que no publican su propio registro DMARC. Por ejemplo, v=DMARC1; p=reject; sp=reject aplica reject tanto al dominio raíz como a todos sus subdominios desde un único registro. Úsala para extender una política estricta a cada subdominio de envío automáticamente, y publica un registro _dmarc dedicado en un subdominio concreto solo cuando necesites que ejecute una política diferente, como mantener un subdominio recién lanzado en p=none mientras se calienta.

¿Un subdominio de envío nuevo necesita calentamiento?#

Sí. Un subdominio nuevo no tiene historial de envíos, y para un proveedor de buzones ese punto de partida en blanco se trata con desconfianza en lugar de con confianza. Enviar un gran volumen desde él de inmediato invita a la limitación o a acabar en spam. Caliéntalo empezando con poco volumen hacia tus destinatarios más comprometidos y aumentando de forma gradual a lo largo de varias semanas, dejando que el subdominio construya una reputación positiva antes de que asuma toda tu carga de envíos.

Un subdominio de envío contiene el daño de un mal envío, pero no puede deshacer el mal envío en sí: eso sigue dependiendo de quién esté en tu lista. Pasa tu lista por el comprobador de correo gratuito para eliminar direcciones muertas, erratas y trampas de spam antes de que lleguen a cualquier subdominio, de modo que la reputación que construya cada uno sea limpia desde la primera campaña.