Alias de correo: definición, configuración y buenas prácticas

Si gestionas una empresa, necesitas más direcciones de correo que empleados. Necesitas sales@ para clientes potenciales, support@ para incidencias y billing@ para facturas. El método tradicional consiste en pagar un buzón independiente para cada una: tres licencias, tres cuotas mensuales y tres inicios de sesión que gestionar.

Una alternativa más eficiente es el alias de correo. Permite crear identidades profesionales asociadas a funciones sin pagar licencias adicionales ni gestionar accesos separados. Sin embargo, una configuración incorrecta puede revelar la identidad principal, provocar fallos de SPF y DMARC o crear un bucle de enrutamiento que impida entregar mensajes.

Esta guía explica qué es realmente un alias de correo en el plano técnico, los casos de uso más útiles, el funcionamiento SMTP del enrutamiento, el problema de «Enviar como» que complica muchas configuraciones, los errores habituales y la configuración paso a paso de alias en TrekMail.

¿Qué es un alias de correo?

Un alias de correo es una dirección virtual de enrutamiento que apunta a un buzón existente. No tiene almacenamiento propio, credenciales de acceso ni identidad independiente. Cuando llega un mensaje a esa dirección, el servidor consulta su tabla de enrutamiento, encuentra el buzón de destino configurado y dirige allí el mensaje, incluso antes de terminar de recibir su cuerpo desde el servidor remitente.

No se inicia sesión en el alias, sino en el buzón al que dirige el correo. El alias es una instrucción del servidor: si llega correo para esta dirección, colócalo allí.

Tres cosas que un alias de correo no es:

• No es un buzón. El alias no tiene almacenamiento asociado. Si se elimina, los mensajes ya entregados normalmente permanecen en el buzón de destino, de acuerdo con la política de retención aplicable.
• No es una regla de reenvío. El reenvío envía el correo a otro servidor. Un alias suele resolver el destino dentro del sistema de correo configurado, lo que evita añadir por sí mismo los riesgos de autenticación propios del reenvío externo.
• No es una bandeja compartida. Varios alias pueden apuntar a un buzón, pero eso no equivale a una bandeja compartida donde varios usuarios trabajan juntos sobre una cola común.

La analogía de la recepción: tu buzón principal es la oficina; un alias es otra placa en la puerta. Si alguien escribe a «Fundador», «Director de ventas» o «Bob», todos los mensajes llegan al mismo despacho. El alias organiza profesionalmente el tráfico entrante sin exigir una oficina ni un presupuesto mayores.

Técnicamente, un alias se implementa como una entrada en el mapa de alias del servidor (en Postfix, virtual_alias_maps; en Exim, una entrada del router; en plataformas alojadas, una regla de enrutamiento). Cuando el demonio SMTP procesa una conexión entrante, consulta ese mapa durante la fase RCPT TO. Si encuentra la dirección en la tabla, reescribe de forma transparente la ruta de entrega. El remitente no ve este proceso.

Alias, reenvío y buzón de correo

Un alias de correo se diferencia del reenvío en un aspecto esencial: normalmente resuelve el mensaje dentro del sistema configurado, mientras que el reenvío lo transmite a un servidor externo, lo que puede exponerlo a problemas de SPF y DMARC. Un buzón es distinto de ambos: cuenta con almacenamiento, credenciales propias y una identidad independiente. Confundir estas opciones puede generar costes innecesarios o problemas de entrega.

El criterio es sencillo: si el correo permanece en tu sistema, usa un alias. Si debe llegar a otro servidor, usa reenvío, pero comprueba antes la compatibilidad actual con SRS y ARC para reducir fallos con remitentes que aplican DMARC estricto. Si una persona necesita iniciar sesión, administrar su propia bandeja o mantener una trazabilidad clara, crea un buzón real.

Consulta el marco de decisión completo en alias de dominio frente a buzón: cómo elegir.

Casos de uso realmente relevantes

Las mejores configuraciones de alias resuelven un problema operativo real; no son solo un detalle estético. Estos son los patrones más útiles.

1. Enrutamiento por funciones (una presencia profesional)

Un fundador en solitario puede crear info@, press@, accounts@ y sales@ como alias y dirigirlos a su buzón principal. Así presenta puntos de contacto diferenciados. Cuando contrate a un comercial, podrá eliminar el alias sales@ y crearle un buzón real. Es un traspaso limpio que, según el plan, no exige reconfigurar otros destinos ni añadir costes.

2. Estrategia de seguimiento de proveedores

En lugar de facilitar tu correo empresarial principal a un proveedor que aún estás evaluando, crea alias específicos: hubspot@yourdomain.com, linkedin@yourdomain.com y surveygizmo@yourdomain.com. Si aparece spam en linkedin@, tendrás una pista concreta sobre el origen de la exposición. Puedes eliminar ese alias sin alterar el resto de la configuración.

Es el equivalente, en el correo, a un token señuelo. Puede estar incluido en el servicio y ahorrar bastante tiempo de diagnóstico si se compromete la base de datos de un proveedor.

3. Variantes con erratas y direcciones antiguas

Si te llamas Michael, habrá quien escriba a micheal@yourdomain.com. Si tu empresa cambió de marca el año pasado, quizá aún recibas mensajes en el dominio antiguo. Los alias permiten dirigir errores comunes y direcciones anteriores a la bandeja actual. Así reduces pérdidas sin consultar dos sistemas.

4. Subdireccionamiento con «+» (alias sin configuración)

Muchos sistemas modernos, como TrekMail, Gmail y Microsoft 365, admiten el subdireccionamiento definido en RFC 5233. Si tu dirección es bob@company.com, puedes utilizar bob+newsletter@company.com o bob+support-ticket@company.com sin configuración administrativa adicional. El correo llega a la bandeja de Bob y la etiqueta permite filtrarlo automáticamente.

La contrapartida es que algunos formularios rechazan el carácter +. Resulta práctico para filtrar y rastrear, pero no se acepta de forma universal. Para direcciones funcionales formales, conviene crear un alias propiamente dicho.

5. Gestión de agencias y varios dominios

Si gestionas correo para varios clientes o una agencia con un dominio por cliente, la facturación por usuario afecta a cada dirección funcional que necesita un buzón propio (support@clientdomain.com, billing@clientdomain.com). El coste de otra licencia acaba en la factura del cliente o reduce tu margen. Según las condiciones vigentes del plan de tarifa fija de TrekMail, puedes crear alias en los dominios de clientes sin una cuota adicional por cada alias: un panel y una tarifa, sujetos a los límites actuales. Para equipos con decenas de dominios, consulta alojamiento de correo multidominio a escala.

6. Enrutamiento departamental al crecer el equipo

Al crecer el equipo, las direcciones por departamento mejoran el enrutamiento y la responsabilidad. hr@, legal@ y finance@ pueden apuntar ahora al empleado responsable o redirigirse a un buzón compartido cuando el equipo lo justifique. Crear un alias suele ser económico y cambiar su destino puede ser rápido cuando alguien cambia de función. Normalmente no requiere modificar DNS ni repetir toda la incorporación.

Cómo enruta el correo un alias (mecánica SMTP)

Un alias actúa durante la fase RCPT TO de una conexión SMTP, antes de transferir el cuerpo completo. Cuando el servidor remitente envía RCPT TO: <sales@yourdomain.com>, tu servidor consulta la tabla de alias, encuentra la entrada de sales, cambia la ruta interna al buzón de destino y acepta la conexión con 250 OK. El encabezado To: original se conserva; solo cambia la ruta interna de entrega.

Paso a paso:

1. Un servidor externo conecta con tu servidor MX y abre una sesión SMTP.
2. El servidor remitente envía: RCPT TO: <sales@yourdomain.com>
3. Tu servidor consulta el mapa de alias. No existe un buzón llamado sales, pero sí una regla que dirige a bob@yourdomain.com.
4. El servidor acepta la conexión (250 OK) y entrega el mensaje al buzón de Bob.
5. El cliente de Bob muestra To: sales@yourdomain.com; el encabezado original sigue intacto.
6. El servidor remitente no necesita saber que existe el alias. No se abre otra sesión SMTP ni aparece un rebote solo por esta resolución.

En Postfix, uno de los MTA de código abierto más utilizados, se implementa mediante virtual_alias_maps, una tabla que relaciona alias con buzones reales. Otros MTA lo resuelven de otro modo (Exim usa configuraciones de router; Haraka, enrutamiento mediante complementos), pero el concepto es el mismo: una regla del servidor resuelve el destino antes de almacenar el correo.

Un detalle importante: la resolución utiliza la dirección del sobre (la del comando SMTP RCPT TO), no necesariamente el encabezado To:. Un mensaje enviado a una lista puede contener To: list@example.com y RCPT TO: member@yourdomain.com; el alias se aplica al RCPT TO, no al encabezado.

El problema de «Enviar como»: responder desde el alias

Recibir correo mediante un alias es sencillo. Responder desde esa dirección es donde fallan muchas configuraciones. Cuando Bob recibe un mensaje dirigido a sales@yourdomain.com y pulsa Responder, la dirección From predeterminada puede ser bob@yourdomain.com, lo que rompe la identidad profesional buscada. El destinatario ve la dirección personal de Bob, no la funcional.

Cada plataforma gestiona «Enviar como» de forma distinta:

Google Workspace

Ve a Configuración de Gmail → Cuentas → «Enviar correo como» → Añadir otra dirección. Introduce el alias. Cuando aparezca el cuadro de configuración, revisa la opción «Tratarlo como un alias» de acuerdo con el comportamiento que necesites. La interfaz y el efecto exacto pueden cambiar, por lo que conviene confirmar con un mensaje de prueba qué dirección muestra From.

Microsoft 365

Históricamente podía requerir que el administrador ejecutara Set-OrganizationConfig -SendFromAliasEnabled $true. Sin esa capacidad, algunas respuestas mostraban «Bob en nombre de Ventas», lo que exponía la dirección principal. Microsoft añadió controles en el centro de administración en 2024, pero debes comprobar el ajuste y la documentación vigentes de tu organización.

TrekMail

TrekMail indica que permite configurar varias direcciones remitentes para un buzón y elegir From desde clientes como Outlook, Thunderbird, Apple Mail o webmail. Comprueba la disponibilidad y los pasos actuales en tu plan y cliente. La documentación está en ajustes IMAP/SMTP.

Errores de configuración que impiden la entrega

Los alias son sencillos en concepto, pero una configuración descuidada puede causar problemas. Estas tres situaciones explican muchos fallos.

1. La trampa del catch-all

Un alias catch-all (*@yourdomain.com) acepta todos los mensajes enviados al dominio, incluso los destinados a direcciones inexistentes. Puede parecer una red de seguridad, pero tiene costes.

En los ataques de enumeración de direcciones (DHA), los atacantes prueban miles de partes locales aleatorias. Sin catch-all, el servidor puede rechazar destinatarios desconocidos durante SMTP con 550 5.1.1 User unknown. Con un catch-all, acepta todo, lo que puede aumentar mucho el spam, saturar filtros y ocultar correo legítimo entre el ruido.

Si necesitas rescatar correo realmente mal dirigido, envía el catch-all a un buzón de cuarentena específico, no a la bandeja real de un usuario. Consulta los matices en configuración y riesgos del buzón catch-all.

2. El bucle de enrutamiento

Este problema es sutil. Configuras support@ como alias hacia bob@yourdomain.com. Bob se va de vacaciones y reenvía automáticamente todo a support@, pensando que el equipo lo atenderá.

Ahora existe un bucle:

support@ entrega a bob@ → bob@ reenvía a support@ → entrega a bob@ → reenvía a support@ → …

Los servidores suelen detectarlo. Postfix controla el número de saltos; si el mensaje supera el límite, puede aparecer un rebote 5.4.14 Hop count exceeded. El mensaje original puede no llegar al destino previsto. Antes de crear respuestas de vacaciones o reenvíos, documenta las relaciones existentes. No reenvíes un buzón a un alias que vuelva al mismo buzón.

3. La filtración de identidad al «Responder a todos»

Participas en una lista que escribe a marketing@yourdomain.com. El alias dirige al buzón principal bob@yourdomain.com. Si pulsas «Responder a todos» sin cambiar From, los destinatarios verán bob@yourdomain.com en vez de marketing@. En ámbitos sensibles, como el jurídico, médico o financiero, puede suponer una exposición real de privacidad.

La solución es configurar «Enviar como». Para comunicaciones funcionales sensibles, valora un buzón dedicado en lugar de un alias: acceso e identidad separados y menos riesgo de revelación accidental.

Alias y reenvío: SPF, DMARC y SRS

Al combinar un alias con reenvío externo, por ejemplo contact@yourdomain.com hacia un Gmail personal, pueden surgir conflictos de autenticación que afecten a mensajes legítimos. Es una configuración común y sus fallos no siempre son fáciles de diagnosticar.

Qué puede fallar y por qué:

Fallo de SPF: el servidor de reenvío retransmite a Gmail desde su propia IP. El dominio del remitente original, por ejemplo bank.com, puede publicar un SPF que no autoriza esa IP. Gmail observa entonces un fallo de SPF aunque el origen fuera legítimo, porque tu servidor no figura en la lista SPF de bank.com.

Rechazo por DMARC: si bank.com publica una política estricta (p=reject), el destinatario puede rechazar el mensaje si no pasa ni SPF alineado ni DKIM alineado. DKIM puede romperse si el reenviador modifica contenido firmado, como el cuerpo o ciertos encabezados. Si fallan ambos mecanismos, una política DMARC p=reject puede producir un rechazo, según la evaluación del receptor.

Dos mecanismos ayudan, pero requieren compatibilidad del proveedor:

• SRS (Sender Rewriting Scheme): el reenviador reescribe el remitente del sobre (MAIL FROM) con su dominio. Así SPF puede pasar en el destino para ese dominio, mientras los rebotes se codifican para regresar al remitente original.
• ARC (Authenticated Received Chain): el reenviador añade una cadena criptográfica que registra los resultados de autenticación observados antes del reenvío. Los receptores compatibles pueden tenerla en cuenta al evaluar un intermediario conocido. ARC se documenta en RFC 8617.

Muchos registradores de bajo coste y alojamientos compartidos antiguos no ofrecen ARC o SRS. En esas plataformas, los alias reenviados al exterior pueden perder mensajes de remitentes con políticas DMARC estrictas, aunque no es un resultado universal. TrekMail declara compatibilidad con SRS y ARC para correo reenviado; verifica la capacidad vigente antes de depender de ella.

Para profundizar, consulta reenvío de alias: ventajas, límites y soluciones y la guía general de configuración y diagnóstico del reenvío.

Configurar alias de correo en TrekMail

En TrekMail, cada alias pertenece a un dominio y dirige el correo a un buzón de la misma cuenta. Se gestiona desde la configuración de ese buzón. Esta es la secuencia general.

Paso 1: añade el dominio y configura DNS

Si el dominio aún no está en TrekMail, añádelo desde Dominios → Añadir dominio. La plataforma muestra los registros DNS necesarios, como MX, SPF, DKIM y DMARC, para copiarlos en el proveedor DNS. Consulta los valores actuales en registros DNS obligatorios. La propagación puede tardar alrededor de una hora o más según DNS; TrekMail muestra el estado cuando detecta los registros.

Paso 2: crea el buzón de destino

El alias necesita un destino. Ve a Buzones → Añadir buzón y configura la dirección y contraseña. Allí llegará el correo que dirija el alias. Según el modelo publicado de TrekMail, los buzones consumen almacenamiento agrupado en vez de generar automáticamente una cuota por usuario; comprueba el plan vigente.

Paso 3: crea el alias de correo

En la configuración del buzón de destino, abre Alias → Añadir alias. Escribe la parte local, por ejemplo sales, elige el dominio y guarda. Como no cambia DNS, la ruta suele quedar disponible cuando el sistema procesa la configuración.

Puedes crear tantos alias como permita el plan. La información publicada para Starter indica alias sin límite por dominio y sin cuota individual, pero conviene verificar las condiciones actuales.

Paso 4: configura «Enviar como» en el cliente

Si quieres responder desde el alias, además de recibir, añádelo como identidad remitente:

• Thunderbird: Configuración de la cuenta → Administrar identidades → Añadir. Introduce el alias y usa el mismo servidor SMTP y las credenciales autorizadas del buzón principal.
• Outlook (escritorio): según la versión y el servidor, el alias puede aparecer como dirección From. Si no aparece, revisa Archivo → Configuración de la cuenta → Correo electrónico → Más configuraciones y la documentación vigente sobre el encabezado From.
• Apple Mail: Mail → Preferencias → Cuentas → selecciona la cuenta → Información de la cuenta. Según la versión, añade el alias al campo «Dirección de correo» como valor separado por comas y comprueba que se ofrezca como From.
• Webmail: la interfaz de TrekMail puede ofrecer el alias configurado en el selector From; confirma el comportamiento actual con una prueba.

La documentación publicada de TrekMail indica IMAP en el puerto 993 (SSL/TLS) y SMTP en el puerto 587 (STARTTLS). Confirma los valores vigentes en la documentación de IMAP/SMTP.

Paso 5: prueba el flujo completo

Envía un mensaje desde una cuenta externa al nuevo alias y confirma que llega al buzón de destino. Después responde usando el alias como From y verifica que el destinatario ve esa dirección, no la del buzón principal. Si aparece una dirección incorrecta, revisa «Enviar como» en el cliente.

Con un dominio cuyo DNS ya está configurado, el proceso puede llevar unos tres minutos, aunque el tiempo real depende del cliente y de la plataforma.

El método tradicional frente al de TrekMail

Gestionar alias parece trivial hasta que se hace a escala o el modelo por usuario convierte cada dirección funcional en una decisión de coste.

El método tradicional (Google Workspace / Microsoft 365)

Estos servicios suelen cobrar por usuario. La cifra de referencia del texto original sitúa Google Workspace Business Starter en $6 por usuario al mes y Microsoft 365 Business Basic en un rango similar, pero precios y condiciones cambian. El alias puede estar incluido, aunque su buzón de destino requiere una licencia válida.

Muchos equipos pequeños agrupan todos los alias en una cuenta: info@, sales@, billing@ y support@ llegan al buzón del fundador. Así se reducen licencias, pero la bandeja puede volverse caótica: las oportunidades importantes se mezclan con avisos de facturación y la responsabilidad queda difusa.

Para las agencias, administrar alias en cientos de organizaciones de clientes puede implicar consolas separadas, scripts de PowerShell para permisos de «Enviar como» y licencias por puesto. Crear una dirección funcional puede exigir otra licencia o renunciar a almacenamiento dedicado.

El método TrekMail

TrekMail publica un modelo de alojamiento por tarifa fija, no por usuario. En el momento reflejado por la fuente, Starter cuesta $3.50 al mes y cubre hasta 50 dominios con almacenamiento agrupado. Verifica precios, límites y condiciones actuales antes de decidir.

Si el plan no cobra por cada buzón, puedes asignar a support@ un buzón propio en vez de añadirlo a la bandeja del fundador. Esto mejora la trazabilidad y simplifica el traspaso al contratar soporte, sujeto a almacenamiento, funciones y límites actuales.

La fuente indica que el plan Agency ($23.25 al mes) cubre 1,000+ dominios con importación masiva y acceso API. Son datos variables que debes confirmar. A esa escala, el coste indicado por dominio sería una fracción de centavo, un modelo diferente de las licencias por usuario.

Consulta los detalles vigentes en trekmail.net/pricing.

Referencia rápida

Usa esta tabla para decidir con rapidez:

Tres reglas que recordar:

1. Enrutamiento interno = alias. Enrutamiento externo = reenvío. No añadas los riesgos de autenticación del reenvío si basta un alias.
2. Configura «Enviar como» antes de comunicarte mediante un alias. Una respuesta desde la dirección principal rompe la identidad profesional prevista.
3. No dirijas un catch-all a la bandeja real de un usuario. Usa cuarentena o prescinde del catch-all.

Conclusión

Un alias de correo es una herramienta muy útil para el correo empresarial y también una fuente frecuente de errores. Bien configurado, ofrece varios puntos de contacto profesionales sin accesos separados y con poco coste adicional. Mal configurado, puede causar bucles, revelar identidades o agravar fallos de autenticación en el reenvío externo.

En resumen:

• Usa alias para direcciones funcionales, seguimiento de proveedores y variantes con erratas.
• Usa un buzón real cuando necesites acceso, almacenamiento o trazabilidad separados.
• Evita los catch-all salvo que dispongas de una estrategia de cuarentena controlada.
• Si reenvías un alias fuera, confirma la compatibilidad vigente con SRS y ARC; muchos alojamientos antiguos no la ofrecen.
• Configura siempre «Enviar como» antes de usar el alias en comunicaciones externas.

Si pagas por usuario solo para mantener varias direcciones funcionales, compara los modelos. La fuente presenta TrekMail con tarifa por dominio y cita Starter a $3.50 al mes para hasta 50 dominios. También indica que Nano no exige tarjeta ni periodo de prueba, con 10 dominios y 5 GB de almacenamiento agrupado. Verifica las condiciones actuales.

La fuente también describe planes de pago que exigen una tarjeta al iniciar la prueba de 14 días e incluyen SMTP gestionado, almacenamiento agrupado y alias multidominio. Consulta la oferta vigente en trekmail.net o compara planes en trekmail.net/pricing.