Por qué deberías usar un subdominio para enviar correos electrónicos

June 1, 2026 by Mailer Para Ir

¿Preocupado de que un subdominio de envío haga que tu correo parezca que viene de un dominio diferente? No es así — los destinatarios siguen viendo tu dominio raíz, y la entregabilidad mejora. Aquí te explicamos por qué, y cómo configurar mtg.yourdomain.com.

Envía tu correo transaccional desde un subdominio como mtg.tudominio.com — no desde tu dominio raíz, y no desde ningún nombre de host que ya sea un CNAME. Es un pequeño cambio en DNS, y mejora significativamente la entregabilidad.

“¿Pero no se verá que mi correo viene de un dominio diferente?”

Es la primera preocupación de todos, así que la resolvemos de frente: no, no se verá. Usar un subdominio para enviar no cambia nada de lo que ven tus destinatarios. La dirección De: en su bandeja de entrada sigue siendo tu@tudominio.com — tu dominio raíz, tu marca, exactamente como es hoy.

El subdominio funciona entre bastidores, en la capa de autenticación que inspeccionan los proveedores de bandeja (no los humanos). Lo que realmente cambia es que tu correo empieza a pasar SPF, DKIM y DMARC limpiamente, así que más correo llega a la bandeja en lugar de la carpeta de spam. Así que el intercambio es simple: nada visible cambia para tus clientes, y más de tu correo realmente les llega.

En resumen — tus destinatarios siguen viendo tu dominio raíz, y tu entregabilidad mejora. Esa es toda la historia; el resto de este artículo es solo el porqué y el cómo.

(La versión técnica: el subdominio es tu envelope-from / Return-Path, que es el dominio que SPF verifica. El encabezado From: que ve tu destinatario lo establece tu aplicación y se mantiene en tu dominio raíz. Más sobre eso abajo.)

Entender el problema

¿Por qué no puedo usar mi dominio raíz si es un CNAME?

Muchos proveedores de hosting (Heroku, Build.io, Cloudflare, Netlify, y otros) te piden que apuntes tu dominio con un registro CNAME para que puedan terminar SSL y enrutar tráfico. Eso funciona muy bien para tu sitio web. Pero crea un conflicto difícil para el correo.

DNS tiene una regla, definida en RFC 1034 §3.6.2: si un nombre tiene un registro CNAME, no puede tener ningún otro registro de otro tipo. Un CNAME significa “este nombre es solo un alias para ese otro nombre — ve allá para buscar todo.” No hay espacio para el registro TXT que contiene tu política SPF, ni para registros MX, en ese mismo nombre.

Así que si tudominio.com es un CNAME que apunta a tu host, literalmente no puedes añadir SPF. DNS no lo permite.

¿Cuál es el conflicto CNAME, y por qué DNS funciona así?

Un CNAME es una redirección en la capa DNS. Cuando un resolver busca tudominio.com y encuentra un CNAME, abandona el nombre original y persigue el destino. Permitir otros registros junto a un CNAME sería ambiguo — ¿cuál respuesta gana? La especificación resuelve la ambigüedad prohibiendo la combinación completamente. No es una limitación del proveedor; es cómo está definido DNS.

Mi sitio funciona bien en mi dominio — ¿por qué el correo sería diferente?

El tráfico web solo necesita el CNAME: un navegador pregunta “¿dónde está tudominio.com?”, sigue el alias, y se conecta. El correo necesita registros adicionales en el dominio — SPF (un registro TXT) y a menudo DKIM y una política DMARC — así que los servidores receptores pueden verificar que el correo está autorizado. El CNAME que hace que tu sitio web funcione es exactamente lo que bloquea esos registros. Mismo nombre, diferentes requisitos.

¿Qué se rompe realmente si envío sin SPF?

SPF es una de las principales señales que usan los proveedores de bandeja para decidir que eres quien dices ser. Sin un registro SPF:

Los proveedores de bandeja (Gmail, Outlook, Yahoo) tienen mucha más probabilidad de enviar tu correo a spam — u rechazarlo.
No puedes pasar DMARC, que cada vez más controla la bandeja.
Tus mensajes se ven como correo no autenticado que envían los spammers.

El correo podría seguir enviándose, pero una porción significativa no llegará.

La solución del subdominio

¿Qué subdominio debo usar? ¿Importa el nombre?

Recomendamos mtg.tudominio.com. La etiqueta exacta no afecta la entregabilidad — email. o notificaciones. funcionarían igual — pero mtg.tudominio.com es claro, fácil de recordar, y mantiene tu envío de MailerToGo ordenadamente en su propio espacio. Lo que importa es que sea un nombre que controles directamente (no sea en sí mismo un CNAME a un tercero), para que puedas añadir los registros SPF, DKIM y de envío que necesita.

Si envío desde `mtg.ejemplo.com`, ¿verán los destinatarios eso en lugar de `ejemplo.com`?

No — y esta es la preocupación que respondimos al principio, ahora con el mecanismo. Cada correo tiene dos direcciones “de” diferentes:

Envelope-from (también llamado MAIL FROM o Return-Path): la dirección que usa la infraestructura de envío. Este es el dominio que SPF verifica, y es donde vive tu subdominio.
Header From: la dirección que el destinatario realmente ve en su bandeja. La establece tu aplicación, independientemente del dominio de envío.

Así que envías a través de mtg.ejemplo.com (envelope-from) mientras tus destinatarios ven hola@ejemplo.com o Soporte Acme <soporte@ejemplo.com> en la línea De:. El subdominio autentica; tu dirección de marca sigue visible.

¿Las respuestas irán al subdominio o a mi dirección real?

Las respuestas siguen el encabezado From: (o un Reply-To: explícito que establezca) — no el envelope-from. Establece From: o Reply-To: en tu buzón real, monitoreado (p. ej. soporte@ejemplo.com) y las respuestas llegan allá como se espera. El subdominio nunca tiene que recibir correo.

¿Usar un subdominio afecta mi reputación de dominio?

Sí — a tu favor. Enviar desde un subdominio aísla la reputación de tu correo transaccional/marketing del dominio raíz. Si una campaña alguna vez tiene un mal momento, queda contenido en mtg.ejemplo.com en lugar de arrastrar ejemplo.com (y el correo diario de tus empleados). El aislamiento de reputación es una característica, no un efecto secundario.

¿Puedo usar el mismo subdominio para correo transaccional y de marketing?

Puedes, pero generalmente es mejor separarlos — p. ej. mtg.ejemplo.com para transaccional (recibos, restablecimientos de contraseña) y noticias.ejemplo.com para marketing. El correo transaccional es de alta confianza y pocas quejas; el correo de marketing naturalmente atrae más quejas y desuscripciones. Separarlos mantiene tus recibos y restablecimientos críticos aislados de las fluctuaciones de reputación de marketing.

Configurarlo

¿Cómo configuro MailerToGo para usar un subdominio?

Añade el subdominio (no tu dominio raíz) como tu dominio de envío en el panel de MailerToGo, luego publica los registros DNS que te da. MailerToGo mostrará los registros exactos para tu subdominio.

¿Qué registros DNS necesito?

En el subdominio añadirás SPF y DKIM (y recomendamos una política DMARC en la raíz). Un conjunto típico se ve así:

; SPF — autoriza a MailerToGo a enviar por el subdominio
mtg.tudominio.com.   TXT   "v=spf1 include:_spf.mailertogo.net ~all"

; MX — enruta los bounces/return-path del subdominio a MailerToGo
mtg.tudominio.com.   MX    10 smtp.us-west-1.mailertogo.net.

; DKIM + DMARC — publica los registros exactos mostrados en tu panel de MailerToGo
; (DKIM es un CNAME con un selector por cuenta; una política DMARC de subdominio es
;  aprovisionada para ti, p. ej. p=reject)

Usa los valores precisos de tu panel — el selector DKIM y la región SMTP (smtp.<región>.mailertogo.net) son específicos de tu cuenta.

¿Necesito cambiar algo en mi código de aplicación?

Dos cosas pequeñas. Primero, apunta tu mailer a MailerToGo usando las credenciales del subdominio. Con Rails:

# config/environments/production.rb
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  address:         ENV["MAILERTOGO_SMTP_HOST"],   # smtp.<región>.mailertogo.net
  port:            ENV.fetch("MAILERTOGO_SMTP_PORT", 587).to_i,
  user_name:       ENV["MAILERTOGO_SMTP_USER"],
  password:        ENV["MAILERTOGO_SMTP_PASSWORD"],
  authentication:  :plain,
  enable_starttls: true   # imponer TLS en puerto 587
}

Segundo — y esta es la parte que hace que el subdominio funcione — establece el envelope-from (return_path) al subdominio mientras mantienes From: y Reply-To: en tu dominio raíz que ven y a los que responden tus destinatarios:

class NotifierMailer < ApplicationMailer
  def welcome(user)
    mail(
      to:          user.email,
      from:        "Acme <hola@tudominio.com>",   # lo que ven los destinatarios
      reply_to:    "soporte@tudominio.com",        # dónde van las respuestas
      return_path: "bounces@mtg.tudominio.com"     # envelope-from: lo que SPF verifica
    )
  end
end

Rails (a través de la gema Mail) usa return_path como el envelope-from, así que SPF se valida contra mtg.tudominio.com — donde vive tu registro SPF — mientras que From:/Reply-To se mantienen en tudominio.com. Misma marca para tus destinatarios, DMARC alineado, mejor entregabilidad.

¿Cómo verifico que el subdominio está funcionando?

Confirma que los registros se resuelven: dig TXT mtg.tudominio.com (SPF), dig MX mtg.tudominio.com, y el CNAME DKIM de tu panel.
Envía un mensaje de prueba a una cuenta de Gmail, abre Mostrar original, y verifica que SPF y DKIM ambos muestren PASS y que DMARC muestre alineación.
Observa que el estado del dominio en el panel de MailerToGo cambie a verificado.

Avanzado y señales de confianza

¿Funciona la alineación DMARC con un subdominio?

Sí. DMARC soporta alineación organizacional por defecto: un mensaje enviado desde mtg.ejemplo.com se alinea con una política DMARC publicada en ejemplo.com, porque comparten el mismo dominio organizacional. Publicas DMARC una vez en la raíz y tu subdominio hereda alineación — no se necesita política separada.

¿DKIM firma con el subdominio o el dominio raíz?

DKIM firma con el dominio donde publiques la clave — aquí, el subdominio (mtg.tudominio.com). Es exactamente lo que quieres: la firma DKIM, el envelope-from, y el subdominio se alinean todos, y esa combinación se alinea con tu política DMARC raíz.

Ya tengo SPF en mi raíz para Google Workspace / Microsoft 365 — ¿aún necesito un subdominio?

Sí, y el subdominio mantiene las cosas limpias. SPF tiene un límite duro de 10 búsquedas DNS; amontonar cada remitente (Google, Microsoft, tu ESP, MailerToGo) en un registro SPF raíz pone en riesgo rebasarlo y romper SPF para todo. Enviar tu correo de app desde un subdominio con su propio registro SPF evita el límite y mantiene tu correo corporativo (Google/Microsoft) y tu correo de app independientes.

La versión corta

Usa un subdominio como mtg.tudominio.com para enviar. Tus destinatarios siguen viendo tu dirección de dominio raíz — nada visible para ellos cambia — y tu entregabilidad sube. Es cómo los grandes remitentes lo hacen (GitHub, Stripe, y AWS envían correo transaccional desde subdominos): evita el conflicto CNAME, mantiene SPF/DKIM/DMARC limpios, y protege la reputación de tu dominio raíz.