Un cliente compra un segundo dominio y la pregunta llega siempre igual: también tenemos el nombre nuevo, ¿puedes hacer que funcione el correo ahí? En la consola de administración hay dos formas de agregarlo. Están en la misma pantalla y llevan a meses muy distintos. Una le da a la gente que ya tienes una segunda dirección sin costo adicional. La otra crea un conjunto aparte de usuarios, y cada uno se paga.
Si eliges mal, te enteras tarde. Nos han llamado para desarmar un dominio secundario lleno de buzones vacíos que nadie necesitaba, y para explicarle a un equipo de ventas por qué su dirección nueva y reluciente no puede iniciar sesión. Ninguna de las dos reparaciones es difícil. Las dos se podían evitar. Así lo decidimos nosotros, y este es el DNS que hay que publicar en cualquiera de los dos casos.
Qué hace en realidad un dominio alias
La documentación de Google lo llama dominio de alias de usuario. La consola de administración lo llama dominio alias. Es lo mismo. Agregas el dominio, verificas que es tuyo y Google crea el alias correspondiente para cada usuario que ya tienes. Si example.com es tu dominio principal y agregas solarmora.com como alias, entonces bob@example.com también recibe correo en bob@solarmora.com, en el mismo buzón, sin una segunda cuenta y sin nada extra que pagar. Cada persona puede enviar desde cualquiera de las dos direcciones.
Hay dos consecuencias que conviene decir en voz alta. Un alias es una dirección, no una cuenta: no hay buzón aparte, ni Drive aparte, ni nada aparte. Y nadie inicia sesión con él. El inicio de sesión sigue siendo con la dirección principal. Ese solo dato es el ticket de soporte más común en la semana siguiente a activar un dominio alias.
Qué hace en realidad un dominio secundario
Un dominio secundario es un segundo conjunto de personas. Lo agregas y lo verificas igual, luego creas usuarios en ese dominio, y cada uno de esos usuarios es una cuenta real con su propio buzón, su propio Drive y su propia licencia por pagar. La administración sigue en un solo lugar: todos los dominios y todos los usuarios se gestionan desde la consola del dominio principal, así que tienes una sola consola y una sola factura.
La relación es de dependencia, no de sociedad. Un dominio secundario cuelga del principal, y algunas cosas le pertenecen solo al principal. Puedes definir un único logotipo para todos tus dominios, y no puedes configurar una dirección de facturación aparte para un dominio secundario.
Cuál de los dos agregar
Toda la decisión se reduce a una pregunta: ¿el dominio nuevo necesita su propia gente? Si no la necesita, y el mismo equipo solo quiere ser localizable con los dos nombres, el alias es todo el trabajo. Si el nombre nuevo viene con personal, o con un equipo que no debería ver los archivos del primer dominio, es un dominio secundario.
| Lo que necesitas | Dominio alias | Dominio secundario |
|---|---|---|
| Una segunda dirección para la gente que ya tienes | Sí, se crea para cada usuario existente | No, creas cada usuario a mano |
| Usuarios y buzones propios | No, un buzón atiende las dos direcciones | Sí, una cuenta por persona |
| Costo por una persona en el dominio nuevo | Sin licencia adicional | Una licencia pagada por cada cuenta |
| Iniciar sesión con el dominio nuevo | No se puede, se inicia sesión con la dirección principal | Sí, la cuenta vive en ese dominio |
| Dónde se puede enganchar | La consola solo agrega un alias al dominio principal; para dar un alias a un dominio secundario se necesita la API de Directory | Se agrega como un dominio por derecho propio |
| Cuántos puedes tener | Hasta 20 dominios alias | Hasta 599 dominios adicionales en total, alias incluidos |
Esos dos límites son los que Google publica en sus preguntas frecuentes sobre varios dominios, consultadas el 6 de noviembre de 2026. La cifra de 599 es el total disponible, así que los dominios secundarios y los alias salen de la misma bolsa. Las cuentas para organizaciones sin fines de lucro tienen un tope mucho menor, de cinco dominios en total.
Qué revisamos antes de agregar nada
Elegir es la mitad fácil. En un proyecto de cliente revisamos cuatro cosas primero, porque las cuatro ya le pasaron a alguien.
- Dónde vive hoy el correo de ese dominio. Agregar el dominio a Workspace no mueve nada. Lo que lo mueve es el cambio de MX, y si el dominio tiene un buzón activo en un proveedor viejo, eso es un corte con su propio plan. Lo contamos en cómo cambiar los registros MX sin perder correo.
- Quién ya envía como ese dominio. Si el nombre ya se usaba, algo está enviando desde ahí: un sistema de facturación, un CRM, una tienda, un boletín. Esos remitentes no se detienen cuando agregas el dominio a Workspace, y van a fallar la autenticación si no los tomas en cuenta.
- Qué DNS ya está puesto en el dominio nuevo. Un SPF heredado del proveedor anterior, un selector DKIM abandonado y, de vez en cuando, un registro DMARC en reject que empezará a rechazar tu propio correo en cuanto envíes el primer mensaje.
- Si alguien piensa convertir el nombre nuevo en el principal. Es la pregunta que la gente olvida hacer, y por sí sola decide la respuesta. Más sobre esto abajo.
Si quieres ver qué dice hoy el dominio nuevo sobre sí mismo antes de tocar nada, revísalo:
El DNS que necesita un dominio nuevo
Agregar un dominio en la consola no crea DNS. Cada dominio que agregas, alias o secundario, es su propia zona con sus propios registros, y nada se hereda del dominio principal. Ahí es donde se rompieron la mayoría de las configuraciones de varios dominios que nos toca revisar: el dominio se agregó y después nadie publicó nada.
MX, para que el dominio pueda recibir
Google Workspace necesita un registro MX. El valor es smtp.google.com con prioridad 1, con el campo de host vacío o en @ para un dominio raíz, o con el nombre del subdominio si es un subdominio. Las zonas antiguas traen un conjunto de registros cuyos valores empiezan con aspmx; Google los describe como valores heredados que siguen siendo compatibles, así que una configuración vieja no está rota por eso. Los registros MX nuevos pueden tardar hasta 72 horas en ser reconocidos.
Tipo Host Valor Prioridad
MX @ smtp.google.com 1SPF, para que el dominio pueda enviar
Cada dominio debe tener su propio registro SPF, y si envías desde subdominios, cada subdominio necesita el suyo. Para un dominio que envía solo a través de Workspace, es un único registro TXT:
example2.com. TXT "v=spf1 include:_spf.google.com ~all"Si la tienda, el proveedor de facturación o el boletín también envían como ese dominio, sus includes van en el mismo registro, porque un dominio tiene un SPF y no dos. Cuida el presupuesto mientras lo armas: un registro está limitado a diez consultas, y apilar un par de proveedores lo agota más rápido de lo que la gente espera. Hacemos la cuenta en la solución para SPF con demasiadas consultas DNS.
DKIM, para que la firma coincida con la dirección que la gente ve
Este es el paso que se salta, y se salta justamente porque nada parece romperse. DKIM se configura por dominio. En la página de autenticación de correo eliges el dominio en el menú de dominio seleccionado, generas una clave única para ese dominio, publicas el registro TXT en el DNS de ese dominio y luego inicias la autenticación. La instrucción de Google es explícita: si vas a configurar DKIM para más de un dominio, completa los pasos para cada dominio. Deja hasta 48 horas después de publicar la clave para que DKIM empiece a funcionar.
Si lo dejas pendiente, el correo igual sale, y por eso pasa desapercibido durante meses. Gmail firma los mensajes salientes con una clave predeterminada en el dominio gappssmtp.com. Esa firma es real y verifica, pero no lleva tu dominio, así que una verificación DMARC sobre la dirección que el destinatario realmente lee no tiene más que SPF sosteniéndola. Un reenvío en el camino y SPF también desaparece, que es la falla que describimos en por qué el reenvío rompe SPF.
DMARC, para enterarte de lo que pasa
Un registro DMARC es un registro TXT en _dmarc bajo el dominio, publicado por dominio como los otros dos. Empieza en p=none con una dirección de reportes, lee un par de semanas de reportes y luego aprieta. En un nombre recién comprado que nunca ha enviado nada, la rampa es corta y los reportes están tranquilos. Si la dirección de reportes está en un dominio distinto al del registro, ese otro dominio tiene que publicar un registro que lo autorice, o los reportes nunca llegan.
_dmarc.example2.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Cuatro trampas que cuestan una semana
Un alias no se puede ascender a principal. Si el negocio podría terminar operando con el nombre nuevo, agregarlo como alias es un callejón sin salida. No puedes intercambiar un dominio de alias de usuario con tu dominio principal. La salida es quitar el alias y volver a agregar el mismo dominio como dominio secundario, lo que significa esperar la eliminación y después la verificación otra vez. Cuando un cliente dice que tal vez se mude al nombre nuevo, lo agregamos como dominio secundario desde el principio, aunque todavía nadie tenga buzón ahí.
El techo de alias es bajo. Veinte alias es generoso para un negocio y nada para una agencia o un grupo que colecciona nombres de dominio. Cuenta los nombres antes de prometer la estructura.
Las políticas no se separan por dominio. No puedes aplicar configuraciones distintas a dominios distintos de forma directa. Si la segunda marca necesita sus propias reglas de uso compartido o su propia exigencia de verificación en dos pasos, la estructura que lo sostiene son las unidades organizativas: pon a los usuarios de cada dominio en su propia unidad y define la política ahí. Lo mismo aplica a quién administra qué.
El DNS heredado te miente. Un dominio comprado de segunda mano, o uno que estuvo estacionado en un proveedor que amablemente publicó un SPF por ti, falla la autenticación de formas que parecen un mal comportamiento de Workspace. Lee la zona y quita los registros que no pusiste tú antes de que salga el primer mensaje.
Cómo ayuda Guanacos Tech
Tratamos un segundo dominio como un proyecto corto con la decisión al frente: alias o secundario, elegido según lo que el negocio piensa hacer con el nombre, no según lo que es más rápido de clicar. Después el DNS del dominio nuevo en orden, MX, SPF, DKIM y DMARC, con los reportes llegando a donde alguien los lea, y los remitentes existentes identificados antes de que empiecen a fallar. Si estás evaluando un segundo nombre y prefieres tomar la decisión una sola vez, ese es el trabajo que hacemos como consultores de Google Workspace. Una llamada de 30 minutos alcanza para decirte cuál de los dos necesita tu caso y qué hay que cambiar en el DNS.
Fuentes
- Ayuda de administrador de Google Workspace: Add a user alias domain or secondary domain
- Ayuda de administrador de Google Workspace: FAQ for multiple domains
- Ayuda de administrador de Google Workspace: Limitations with multiple domains
- Ayuda de administrador de Google Workspace: Set up MX records for Google Workspace
- Ayuda de administrador de Google Workspace: Set up SPF
- Ayuda de administrador de Google Workspace: Set up DKIM
- Ayuda de administrador de Google Workspace: Configurar DMARC