Necesitas una dirección nueva: sales@, billing@, support@. Muchas guías dicen «usa un alias, es gratis». Puede funcionar hasta que las respuestas salen desde tu dirección personal, las facturas dejan de estar disponibles cuando alguien se marcha o un reenvío se rechaza por problemas de autenticación SPF. Puedes perder mensajes legítimos sin recibir tú una notificación de rebote.
Este es el problema de confundir un alias de correo con dominio y un buzón. Google Workspace y Microsoft 365 utilizan precios por usuario, como el intervalo de $6-$30 al mes citado en la fuente, que favorecen el uso de alias donde convendrían buzones; los importes actuales dependen del plan. No son equivalentes, ni en su arquitectura ni en su gestión.
Esta guía ofrece criterios para decidir: diferencias a nivel de protocolo, fallos posibles en producción y una matriz para cada tipo de dirección. Para entender el mecanismo de reenvío, consulta el análisis de reenvío de correo: configuración, solución de problemas y funcionamiento. Si estás eligiendo entre alias y buzones, empieza aquí.
¿Cuál es la diferencia real entre un alias y un buzón?
Un alias de correo con dominio es una regla de enrutamiento. Cuando un MTA recibe correo para alias@domain.com, lo dirige a una dirección de destino, por ejemplo reescribiendo el destinatario del sobre. El alias no tiene almacenamiento ni credenciales propios, ni constituye por sí solo una identidad independiente. Un buzón almacena mensajes: puede disponer de cuota, credenciales IMAP, carpeta de enviados e historial separados. Puedes iniciar sesión en un buzón si el servicio lo permite. No puedes iniciar sesión en la regla de alias.
| Característica | Alias de correo | Buzón completo |
|---|---|---|
| Función SMTP | Reescritura de RCPT TO (referencia al destino) | Almacenamiento de mensajes (destino final) |
| Inicio de sesión por IMAP | No | Sí, si dispone de credenciales propias |
| Almacenamiento | 0 GB propios; utiliza la cuota del destinatario | Parte asignada del almacenamiento compartido |
| Historial de auditoría | Mezclado con el correo del destinatario | Historial de enviados y recibidos separado |
| Identidad al responder | Requiere configurar «Enviar como» | Normalmente usa la dirección del buzón por defecto |
| SPF con reenvío externo | Puede fallar; SRS ayuda a autenticar el reenviador | No interviene el reenvío si la entrega es directa |
| Coste (Google Workspace / M365) | Alias generalmente incluido; depende del plan | $6-$30/usuario/mes en el ejemplo de la fuente |
| Coste (TrekMail) | Incluido según el plan descrito | Incluido según sus límites; modelo por dominio descrito |
Tres formas en que los alias pueden fallar en producción
Hay tres riesgos recurrentes: revelar la identidad principal al responder, fallos de autenticación SPF/DMARC al reenviar a direcciones externas y pérdida de acceso a los datos al eliminar la cuenta destinataria. No son casos que convenga ignorar. Pueden aparecer si utilizas un alias para tareas que necesitan un buzón con gestión propia.
1. Revelar la identidad al responder
Diriges el alias support@ a tu cuenta personal founder@yourdomain.com. Un cliente escribe a support@. Pulsas responder.
Si «Enviar como» no está bien configurado o el cliente selecciona otra identidad, la respuesta puede salir desde founder@. El cliente obtiene tu dirección directa y puede empezar a usarla en lugar del canal de atención.
Conviene comprobar cómo funciona «Enviar como» en el servicio y cliente concretos:
- Google Workspace: Añade y verifica la dirección cuando corresponda. Revisa «Tratar como un alias» según el tipo de cuenta y el método de envío; desmarcarlo no garantiza por sí solo un Return-Path determinado.
- Microsoft 365: El ejemplo de la fuente utiliza
Set-OrganizationConfig -SendFromAliasEnabled $trueen PowerShell. Confirma las condiciones actuales y la compatibilidad del cliente; algunos métodos muestran «En nombre de» y pueden revelar la identidad principal. - Clientes de escritorio (Outlook, Thunderbird): Configura y comprueba la dirección de remitente al responder. Según el cliente, puede ser necesario seleccionarla manualmente; un error puede revelar otra identidad.
Un buzón dedicado support@ suele facilitar que las respuestas salgan desde support@. Aun así, comprueba la identidad predeterminada, las delegaciones y la configuración del cliente; un buzón separado no sustituye estas verificaciones.
2. La trampa de SPF en los reenvíos
Una configuración habitual consiste en reenviar el alias contact@yourbusiness.com a un Gmail personal. El reenvío externo puede complicar la autenticación.
Los estándares de autenticación del correo, SPF (RFC 7208) y DMARC (RFC 7489), realizan comprobaciones distintas: SPF verifica la IP frente al dominio del remitente del sobre; DMARC exige que SPF o DKIM pasen con alineación respecto al dominio visible del remitente. El reenvío puede hacer fallar la comprobación SPF original.
Un posible fallo cuando un banco escribe a tu alias y este reenvía a Gmail:
- El servidor del banco envía a
contact@yourbusiness.com. - Tu servidor cambia el destinatario y reenvía a
you@gmail.com. - Gmail recibe la conexión desde la IP de tu servidor, no desde la del banco.
- Si se conserva el remitente original del sobre, el SPF del banco no autoriza tu servidor y SPF puede fallar.
- Si el banco publica
p=rejecty no pasa ninguna autenticación alineada, Gmail puede rechazar el mensaje según su política; un DKIM válido y alineado puede permitir que DMARC pase.
Puede que no recibas ningún aviso. Un rechazo puede generar una notificación para el remitente del sobre, pero no necesariamente para ti. Revisa los registros del reenvío y no des por hecho que todos los fallos llegan a tu bandeja de entrada.
SRS (Sender Rewriting Scheme) reescribe el remitente del sobre para que el receptor pueda validar SPF con el dominio del reenviador, siempre que este esté correctamente autorizado. El ejemplo siguiente ilustra el mecanismo; no garantiza la aceptación ni la alineación DMARC:
# Original envelope (bank → your alias)
MAIL FROM: <notifications@bank.com>
RCPT TO: <contact@yourbusiness.com>
# After SRS rewrite (your server → Gmail)
MAIL FROM: <SRS0=hash=TT=bank.com=notifications@yourbusiness.com>
RCPT TO: <you@gmail.com>Sin SRS u otro tratamiento adecuado, MAIL FROM conserva notifications@bank.com, un dominio que normalmente no autoriza a tu servidor, y SPF puede fallar en Gmail. Comprueba si el proveedor ofrece SRS o ARC y cómo trata DKIM; SRS por sí solo no alinea SPF con el remitente visible original, y ARC tampoco garantiza la aceptación. Consulta la configuración básica de SPF, DKIM y DMARC en nuestra guía de correo seguro para empresas.
3. Depender de una sola persona
Diriges billing@ a alice@. Alice gestiona las facturas. Alice se marcha. Eliminas su cuenta.
Si no reasignas el destino, billing@ puede devolver errores y las nuevas facturas dejar de llegar. Los registros de facturación de los últimos tres años guardados en el buzón de Alice pueden dejar de estar disponibles o perderse, según la retención y las posibilidades de recuperación del servicio.
Conservar la cuenta de Alice solo por las facturas también conserva sus conversaciones personales con RR. HH. Esto puede complicar la privacidad, la retención y el cumplimiento; conviene separar esos datos y definir una política adecuada.
Con un buzón dedicado billing@ y delegación compatible, Alice puede trabajar sin ser su propietaria exclusiva. Cuando se marche, revoca su acceso y revisa sesiones y credenciales. El historial puede permanecer separado del suyo y Bob puede recibir acceso ese mismo día si el servicio lo permite. Prepara y verifica el relevo para reducir interrupciones y pérdidas, sin darlas por imposibles.
Matriz de decisión: ¿alias o buzón?
Prioriza un buzón para direcciones que envían correo, cambian de responsable, necesitan un historial separado o reciben mensajes críticos o de gran volumen. Un alias encaja en el enrutamiento sencillo de poco volumen, las direcciones temporales de seguimiento y las redirecciones cuyo historial y respuestas pueden gestionarse adecuadamente en el destino.
| Tipo de dirección | Recomendación | Motivo |
|---|---|---|
first.last@ (fundador, empleado) | Buzón | Identidad principal: 2FA compatible, almacenamiento privado y sincronización IMAP |
support@, billing@, jobs@ | Buzón | Cuenta funcional: enviados separados, relevo de personal y separación del spam |
noreply@ | Buzón | O credenciales de envío de servicio: el alias no tiene autenticación SMTP propia |
info@, media@ | Alias | Enrutamiento de baja prioridad al buzón de quien gestiona la oficina |
vendor-name@, conf2026@ | Alias | Seguimiento temporal: desactivarlo cuando empiece a recibir spam |
*@domain.com (catch-all) | Solo un buzón de cuarentena | Evitar el buzón principal: puede acumular intentos de enumeración de direcciones |
La excepción de noreply@
noreply@ parece una dirección de enrutamiento, pero un alias por sí solo no ofrece credenciales de envío. Si tu aplicación utiliza autenticación SMTP, necesita un buzón autorizado o credenciales específicas de servicio, según el proveedor. No siempre hace falta un buzón con acceso IMAP. Guarda el secreto en la configuración protegida de la aplicación, no lo publiques ni lo distribuyas innecesariamente.
Precauciones con el catch-all
Un catch-all dirigido a una bandeja real puede aceptar mensajes para direcciones inexistentes, incluidos errores de escritura, spam e intentos de enumeración, según los filtros del servidor. Si lo necesitas, dirígelo a un buzón aislado y revísalo semanalmente. Evita que contamine el buzón principal de una persona. La guía de configuración del correo con dominio explica cómo plantear esta separación desde el principio.
Por qué el sector confunde ambos conceptos y qué propone TrekMail
El precio por usuario puede favorecer una arquitectura poco adecuada. Los planes de Google Workspace y Microsoft 365 tienen condiciones de licencia distintas, incluidos casos de buzones compartidos; conviene comprobarlas antes de comparar. Ahorrar los $6/mes del ejemplo usando un alias puede acabar complicando la identidad de respuesta, la auditoría y la autenticación del reenvío.
Modelo por licencia, ejemplo de la fuente: 5 empleados + 3 buzones funcionales (support, billing, noreply) = 8 licencias × $6 = $48/mes en este supuesto, no un mínimo universal. Dirigir
support@a un buzón personal evita una licencia en ese escenario, pero añade trabajo de configuración de «Enviar como» y posibles errores de identidad.TrekMail: Según el modelo descrito en la fuente, puedes crear
support@,billing@ynoreply@como buzones separados por $0 adicionales, dentro de los límites del plan. Consumen almacenamiento compartido sin añadir una licencia por usuario; confirma las condiciones actuales.
La fuente sitúa los planes desde $3.50/mes (Starter: 50 dominios, 15GB de almacenamiento compartido, 100 buzones por dominio y SMTP gestionado incluido). Describe Nano con 10 dominios, 5GB y hasta 10 buzones por dominio, sin tarjeta de crédito. Son condiciones de la versión descrita en la fuente, no una garantía de disponibilidad actual; consulta los precios vigentes.
Para agencias y proveedores de servicios gestionados, este modelo puede facilitar la creación de buzones funcionales para clientes sin presupuestar cada usuario por separado. Antes de añadir una dirección, comprueba los límites y la cuota disponibles. Nuestra guía de alojamiento de correo multidominio a escala explica el flujo operativo para gestionar numerosos dominios de clientes desde un panel.
Referencia rápida: cuándo usar cada opción
Usa un buzón cuando la dirección deba:
- Permitir leer correo por IMAP y enviarlo mediante el servicio compatible
- Cambiar de responsable cuando cambie el personal
- Mantener una carpeta de enviados separada para auditoría
- Gestionar correo crítico o de gran volumen
- Autenticarse en SMTP para envíos transaccionales, salvo que existan credenciales de servicio adecuadas
Usa un alias cuando la dirección deba:
- Dirigir correo de baja prioridad a un buzón existente
- Ser temporal, para seguimiento de eventos o identificación de proveedores
- Redirigir únicamente dentro del mismo dominio
- No necesitar identidad de respuesta ni un relevo de responsables independientes del buzón de destino
Conclusión
Los alias dirigen mensajes. Los buzones los almacenan y permiten gestionarlos y enviarlos con una identidad propia, según el servicio. No son intercambiables. El precio por usuario puede llevar a tratarlos como si lo fueran, pero usar un alias donde hace falta un buzón aumenta el riesgo de perder continuidad al cambiar el personal o de responder desde una dirección incorrecta.
Diseña la arquitectura según la importancia de cada dirección. Prioriza buzones para funciones críticas y alias para redirecciones sencillas. Compara las condiciones del proveedor y el coste real de mantener esa separación.
Consulta los planes de TrekMail: la fuente describe un modelo por dominio sin cargos por usuario y una prueba gratuita de 14 días en planes de pago. Comprueba las condiciones actuales.
