Subdominios para transaccional y marketing: aislamiento de reputación bien hecho
Por qué separar transaccional y marketing en subdominios distintos: aislamiento de reputación, DMARC con sp=, configuración DNS y migraciones limpias.
Una de las decisiones más importantes en una arquitectura de envío es decidir qué dominio usa cada tipo de tráfico. Mezclar transaccional y marketing bajo el mismo dominio es lo más sencillo y la opción menos resistente: cuando una campaña de marketing genera quejas, la reputación afecta también a los password reset, los recibos y los OTP. Aislar cada flujo en un subdominio dedicado es la forma estándar de proteger lo crítico de los altibajos del marketing. Esta guía explica cómo estructurar subdominios, cómo configurar autenticación independiente y cómo migrar desde un setup mezclado.
Por qué separar
Hay tres tipos de email habituales:
- Transaccional: confirmaciones, recibos, password reset, OTP, alertas. El destinatario los espera. Tasa de quejas casi cero. Inbox crítico.
- Operacional: notificaciones internas, avisos de actividad, mensajes basados en evento. El destinatario está suscrito implícitamente.
- Marketing / Broadcast: newsletters, promociones, reactivación. El destinatario consintió pero no está esperando un mensaje concreto. Tasa de quejas más alta.
Si los tres salen de tudominio.com:
- Una campaña de marketing con baja calidad de lista genera complaints.
- La reputación del dominio cae globalmente.
- Los OTP empiezan a llegar a spam.
- Usuarios no completan altas, no resetean password, soporte se llena de incidencias.
Aislar cada tipo en su subdominio rompe ese acoplamiento.
Esquema típico de subdominios
Una organización mediana suele acabar con algo así:
tudominio.com: correo humano, comerciales, soporte (correos uno-a-uno).tx.tudominio.comoapp.tudominio.com: transaccional automatizado.news.tudominio.comomail.tudominio.com: marketing y newsletters.notifications.tudominio.com: avisos operacionales.
Los nombres son convención; lo importante es que estén separados y cada uno tenga su pila de autenticación.
Para volúmenes pequeños, basta con dos subdominios (transaccional + marketing). Mezclar todo en tudominio.com está bien si no envías marketing relevante; en cuanto entres en campañas, separar es la primera mejora.
Configurar autenticación independiente por subdominio
Cada subdominio necesita su propia pila:
SPF en el subdominio
Publica un TXT en news.tudominio.com específico para los remitentes de marketing:
news.tudominio.com. IN TXT "v=spf1 include:servers.mcsv.net ~all"Y en tx.tudominio.com otro para los remitentes transaccionales:
tx.tudominio.com. IN TXT "v=spf1 include:amazonses.com ~all"Cada subdominio tiene su límite independiente de 10 lookups DNS. Eso te da margen para flujos complejos.
Más detalle en la guía de SPF.
DKIM en el subdominio
Cada proveedor publica su selector DKIM bajo el subdominio que tú elijas. Con Mailchimp en news:
k1._domainkey.news.tudominio.com CNAME ...
k2._domainkey.news.tudominio.com CNAME ...Con SES en tx:
<selector>._domainkey.tx.tudominio.com CNAME ...Las claves son independientes; un compromiso en marketing no expone la firma del transaccional.
DMARC: política heredada con sp=
DMARC se publica en _dmarc.tudominio.com y por defecto cubre el dominio raíz y todos los subdominios con la misma política. Si quieres política distinta por subdominio, hay dos formas:
Opción A: política específica en el subdominio.
_dmarc.news.tudominio.com. IN TXT "v=DMARC1; p=none; rua=mailto:..."
_dmarc.tx.tudominio.com. IN TXT "v=DMARC1; p=reject; rua=mailto:..."Con esto, cada subdominio tiene su propia política. Útil cuando uno está listo para reject y el otro todavía en monitorización.
Opción B: usar sp= en el dominio raíz.
El registro DMARC del raíz puede declarar una política distinta para subdominios:
_dmarc.tudominio.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:..."sp=quarantine aplica a subdominios; p=reject al raíz. Solución elegante cuando todos los subdominios deben tener la misma política y es más laxa que la del raíz.
Cuándo subir cada uno a quarantine o reject es la lógica de quarantine vs reject.
Migrar desde un setup mezclado
Si todo sale hoy de tudominio.com, el plan ordenado:
1. Diseña el esquema de subdominios
Decide nombres, qué proveedor envía desde cada uno, qué política DMARC empezarán teniendo.
2. Configura el subdominio nuevo en el proveedor
En tu ESP / SES / Postmark, añade tx.tudominio.com (o el que sea) como dominio de envío. Publica los registros DKIM y SPF que pida.
3. Empieza a enviar pequeños volúmenes desde el nuevo subdominio
No todo de golpe. Primero el 10 %, luego 50 %, luego 100 %. Es un mini-warming porque el subdominio empieza sin reputación.
4. Monitoriza
Postmaster Tools tarda en mostrar datos del subdominio. Mientras, mira reportes DMARC del subdominio y métricas de tu ESP. Si todo va bien, sigues subiendo volumen.
5. Retira el envío del dominio raíz
Cuando el subdominio nuevo cubre el 100 % del flujo, retira la configuración del raíz. SPF y DKIM ya no necesarios para ese flujo en el dominio principal.
6. Endurece DMARC del subdominio
Cuando los reportes RUA confirman 100 % autenticación, sube de p=none a quarantine, y luego a reject.
Ventajas operativas
Reputación independiente
Una campaña de marketing tóxica afecta solo a news., no al transaccional crítico. Los password reset siguen llegando.
Diagnóstico más fácil
Cuando todo va por un mismo dominio y empiezan a llegar quejas, la pregunta “¿qué flujo lo causa?” es pesada. Con subdominios, la respuesta es trivial: el subdominio te lo dice.
Cambio de proveedor más limpio
Si decides cambiar de Mailchimp a otro ESP, retiras los CNAME de news., configuras el nuevo proveedor, y el dominio raíz no se entera. Migración aislada.
Política DMARC granular
Puedes tener p=reject agresivo en transaccional (donde controlas todo) y p=quarantine más prudente en marketing (donde hay más vectores de error). Sin esa separación, eliges una política para todo.
Posibilidad de IPs distintas
Algunos ESP permiten asignar IPs dedicadas distintas a flujos distintos. Con subdominios separados, la combinación IP+dominio queda limpia.
Errores frecuentes
Mantener envíos legacy en el raíz tras migrar
Suelen quedar scripts internos, sistemas heredados o crons que siguen enviando con tudominio.com. Si el raíz sube a p=reject, esos envíos se rechazan. Identifica todo con DMARC RUA antes de endurecer.
Subdominios sin DKIM propio
Si en news.tudominio.com no firmas DKIM y solo SPF, te quedas a medias. Ambos son necesarios para alineamiento serio con DMARC.
sp=none en dominio con p=reject
Si publicas p=reject; sp=none, los subdominios quedan completamente desprotegidos. Atacantes los usan para suplantar. Si vas a reject en raíz, sube también sp= al menos a quarantine.
Subdominios en jerarquía profunda
mail.transactional.app.tudominio.com es excesivo. Una jerarquía de 1-2 niveles bajo el raíz basta. Más profundo complica DNS y diagnóstico.
Olvidar BIMI en cada subdominio
BIMI se publica por dominio. Si quieres logo en transaccional y en marketing, publica BIMI en cada subdominio. Se puede compartir el SVG y el VMC; lo que cambia es el TXT en default._bimi.<subdominio>.
MX en subdominios sin sentido
Para envío no necesitas MX. Solo si vas a recibir correo en ese subdominio. Configura MX solo cuando lo uses; si no, deja la zona del subdominio limpia. Más detalle en MX, A y rDNS.
Combinaciones con la guía de plataforma
Las plataformas más usadas se prestan bien al esquema:
- Postmark transaccional en
tx.tudominio.com. Postmark es estricto en separación, encaja perfecto. - Mailchimp / Brevo en
news.tudominio.com. ESP de marketing genuino. - Google Workspace en
tudominio.compara correo humano. - SES en cualquiera, según el flujo.
Recursos relacionados
Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.
¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de retención y email marketing de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.