Alias de correo del dominio: 5 problemas y cómo diagnosticarlos

Configuraste un alias de correo de dominio - sales@yourcompany.com dirigido a tu bandeja de entrada, support@ al equipo de soporte. Todo parecía correcto en el panel. Después dejaron de llegar consultas, un cliente dijo que su mensaje había rebotado y descubriste que llevabas tres semanas respondiendo desde tu dirección personal.

Cuando falla un alias de correo de dominio, revisa tanto las erratas como la interacción entre el enrutamiento y la autenticación moderna - SPF, DKIM, DMARC -. Una regla heredada puede entrar en conflicto con las comprobaciones del receptor.

Si ves 550 5.7.520, 554 5.4.14 o mensajes que desaparecen pese al amable 250 OK de tu servidor, deja de adivinar. Esta guía explica cinco errores habituales de configuración, sus códigos y las soluciones que conviene comprobar.

Si primero necesitas entender la arquitectura - qué distingue un alias de un buzón -, lee alias de correo de dominio frente a buzón antes de continuar.

¿De verdad falla tu alias de correo de dominio? Empieza aquí

Estos cinco patrones sirven como puntos de partida para investigar. Cada uno ofrece síntomas y códigos útiles. Identifica la fila más cercana antes de modificar DNS, reglas de enrutamiento o políticas administrativas; el código orienta la investigación, aunque no demuestra por sí solo la causa.

Por qué fallan los alias: el problema de los dos remitentes

Un mensaje puede tener dos direcciones de remitente con funciones distintas; que difieran no supone por sí solo un fallo. El remitente del sobre (RFC 5321 MAIL FROM) sirve para dirigir los rebotes y es la identidad que comprueba SPF. El remitente de la cabecera (RFC 5322 From:) es el que ve el destinatario en Gmail u Outlook y el dominio con el que DMARC exige alineación.

Al enrutar internamente - de sales@ a bob@ en el mismo servidor - no se introduce necesariamente otro salto SMTP externo, pero tampoco se garantiza la autenticación. Al reenviar fuera, el servidor receptor ve la IP del reenviador y puede comprobar SPF contra el dominio original. Si esa IP no está autorizada, SPF falla. Con p=reject, un fallo de DMARC puede provocar rechazo u otro tratamiento según el receptor; una firma DKIM alineada que se conserve puede permitir que DMARC pase. El rechazo, la cuarentena y los avisos de rebote dependen de la fase SMTP y de las políticas.

Error de configuración 1: reenvío externo sin SRS

Reenviar un alias a Gmail, Yahoo o una cuenta personal de Outlook.com puede romper SPF; el resultado de DMARC también depende de DKIM y de su alineación. Es un problema relevante en el período 2025-2026, especialmente cuando los remitentes publican p=reject, no una garantía de que todo reenvío falle.

Ejemplo: el cliente alice@bank.com escribe a contact@yourdomain.com. Tu servidor reenvía a you@gmail.com. Gmail consulta SPF para bank.com. La IP del reenviador no figura en ese registro y SPF falla. El banco publica p=reject. Si tampoco pasa DKIM alineado, el receptor puede rechazar el mensaje. Tu servidor ya pudo devolver 250 OK al salto anterior, pero eso no confirma la entrega final ni impide necesariamente un rebote posterior.

La solución para la identidad del sobre: Sender Rewriting Scheme (SRS). SRS reescribe el remitente del sobre con tu dominio antes del reenvío:

Sobre original: alice@bank.com
Después de SRS: SRS0=hash=TT=bank.com=alice@yourdomain.com

Ahora Gmail comprueba SPF para yourdomain.com. Si tu servidor está autorizado, SPF puede pasar para ese sobre reescrito. SRS se habilita en el servidor a través del proveedor o del administrador. Existen módulos para Postfix y Exim; hay que comprobar su configuración.

Advertencia importante: SRS puede resolver la autorización SPF del sobre reenviado, pero no restaura la alineación DMARC con el dominio From original. Para que pase la alineación DMARC, puede bastar una firma DKIM original, válida y alineada que sobreviva al reenvío. ARC (Authenticated Received Chain) aporta información que el receptor puede valorar tras validar la cadena y confiar en el servicio que la sella; no crea alineación ni garantiza la entrega. Firmar con otro dominio tampoco corrige la alineación con el remitente original.

Una alternativa más sencilla: evitar el reenvío a proveedores externos. Usa un buzón IMAP real en tu dominio y accede desde un cliente móvil. El reenvío externo, un patrón ya común en 2012, requiere hoy gestionar cuidadosamente la autenticación, aunque sigue siendo viable en algunos casos.

Error de configuración 2: Microsoft 365 bloquea el reenvío externo

Si el alias reenvía fuera y el remitente recibe 550 5.7.520 Access denied, revisa las políticas de Microsoft. La opción predeterminada "Automatic - System-controlled" del filtro de spam saliente de Exchange Online se interpreta como bloqueo del reenvío externo automático. Es una medida para limitar la extracción de datos; comprueba la política efectiva de tu organización.

Corrección en el portal administrativo: habilita el reenvío solo con autorización de tu organización. Los pasos siguientes modifican la política predeterminada y pueden afectar a todas las cuentas a las que se aplique.

1. Abre el portal Microsoft 365 Defender
2. Ve a: Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. Edita Anti-spam outbound policy (Default)
4. Establece "Automatic forwarding rules" en On - Forwarding is enabled

Si solo necesitas habilitarlo para determinados usuarios - una opción más acotada -, crea una política saliente específica para esas cuentas en vez de cambiar el valor de toda la organización.

Alternativa con PowerShell:

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

Error de configuración 3: el bucle de enrutamiento

Un bucle puede producir 554 5.4.14 Hop Count Exceeded. El mensaje va de una dirección a otra hasta alcanzar el límite del servidor - por ejemplo, 15-20 saltos si así está configurado -, y se detiene. El remitente puede recibir un rebote; el destinatario previsto puede no recibir nada. El umbral depende del sistema.

Comprueba si hay una regla olvidada en el buzón de destino:

Alias del servidor: info@ → admin@
Regla del buzón admin@: reenviar todo a info@ para archivarlo
Resultado: bucle hasta superar el límite de saltos

Busca también en lo que suele olvidarse: una respuesta de vacaciones de hace dos años o una regla "archivar todo en info@". Revisa los alias del servidor y las reglas de los clientes. En Exchange, comprueba las reglas de transporte del centro administrativo. En Google Workspace, revisa "Filtros y direcciones bloqueadas" de cada cuenta afectada.

Corrección estructural: comprueba cómo se expanden los alias y cuándo se aplican las reglas del buzón. Según el servidor, una redirección que conserve el destinatario original puede volver a activar el alias. Define rutas de entrega sin ciclos y verifica su comportamiento; el nombre "redirect" o "deliver to" no garantiza por sí solo el resultado.

Error de configuración 4: exposición de identidad al enviar como alias

Un alias que solo recibe puede no cubrir tu necesidad de identidad. Si respondes a un mensaje enviado a sales@yourcompany.com y el destinatario ve bob.smith@yourcompany.com en From, la respuesta no usa la dirección esperada. Esa exposición puede pasar inadvertida desde tu lado.

Revisión en Google Workspace:

1. Abre la configuración del usuario → Cuentas → "Enviar correo como"
2. Añade la dirección del alias
3. Revisa "Tratar como un alias" según el uso de la identidad. Desmarcarlo puede servir para una identidad independiente, pero no garantiza privacidad. Comprueba From, Reply-To y las cabeceras de un mensaje de prueba.

Revisión en Microsoft 365:

En M365, "Bob en nombre de Sales" puede indicar permisos de envío en nombre de otro. El envío desde alias es una función distinta de "Send As" y de esos permisos. Para habilitar la función de alias en la organización:

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

La opción corresponde a Exchange Online, no a Exchange local. No es una solución universal al indicador "en nombre de": revisa los permisos, el tipo de dirección y la compatibilidad del cliente.

Error de configuración 5: conflicto con el catch-all

Un catch-all (*@domain.com) recoge direcciones sin coincidencia específica. Si tu sistema aplica una coincidencia genérica antes que los alias concretos, puede dirigir mensajes al buzón equivocado sin un error evidente.

En los mapas indexados de Postfix, virtual_alias_maps busca la dirección exacta antes del catch-all del dominio; no depende simplemente del orden de las líneas. Este ejemplo coloca primero los alias explícitos para facilitar la lectura:

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

La posición final del catch-all es ilustrativa, no una regla universal de evaluación; en mapas PCRE sí puede importar el orden de los patrones. Antes de aplicar el ejemplo, guarda una copia de seguridad de la configuración y los mapas existentes, prueba las correspondencias de destinatarios y valida la configuración y las rutas con autorización administrativa antes de recargar. En mapas respaldados por MySQL, comprueba las consultas y la precedencia de búsqueda de direcciones concretas frente al dominio; el orden de las filas por sí solo no garantiza esa prioridad.

Diagnóstico avanzado: lee las cabeceras completas

Cuando un mensaje parece desaparecer sin rebote, las cabeceras de uno que haya llegado a spam pueden ayudar. Authentication-Results informa de las comprobaciones realizadas por ese receptor. Contrástalo con los registros y el seguimiento de entrega; no explica necesariamente todos los saltos.

En Gmail: abre el mensaje → menú de tres puntos → "Mostrar original". Busca el bloque de autenticación:

Ejemplo de fallo - falta SRS:

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

smtp.mailfrom sigue siendo alice@bank.com. Si la IP corresponde al reenviador, el ejemplo indica que el sobre no se reescribió con SRS.

Ejemplo que pasa - SRS activo y autenticación alineada conservada:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

El sobre se ha reescrito y SPF pasa para yourdomain.com. Ese SPF no está alineado con el From original. Para explicar el resultado DMARC mediante DKIM, debe existir una firma válida y alineada, no mostrada en este extracto; SRS por sí solo no lo explica.

Para comprobar cómo responde el servidor a una dirección de alias, usa swaks solo con autorización en servidores y dominios que controles. Sustituye los valores de ejemplo por direcciones de prueba propias, no de terceros: este comando puede enviar un mensaje de prueba.

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK confirma aceptación en esa fase SMTP, no la existencia de un buzón ni la entrega final; un catch-all o la validación diferida también pueden aceptarlo. 550 User Unknown indica que el servidor rechazó la dirección como desconocida en esa prueba. Revisa mapas, políticas y registros.

Prevención: simplifica las rutas y reduce los saltos

Para reducir errores, elimina cuando sea posible los patrones que los favorecen. Estas dos pautas cubren buena parte de los casos anteriores.

Regla 1: evitar el reenvío externo cuando no sea necesario. Conserva el correo de empresa en su dominio y consulta el buzón con un cliente IMAP en el móvil. El reenvío puede complicar SPF y DMARC, pasar datos por terceros y exigir una identidad de envío adicional. Si lo necesitas, valora esas implicaciones y configura la autenticación.

Regla 2: reducir las cadenas de alias a un salto.

Cada salto añade una oportunidad de bucles, cambios de cabecera o fallos de autenticación. Un solo salto es un objetivo de diseño útil, no un requisito universal.

Para direcciones temporales o de campañas, considera el direccionamiento con signo más - bob+newsletter@domain.com - en vez de crear siempre otro alias. Comprueba la compatibilidad y las opciones actuales de TrekMail, Gmail y Exchange; dependen del proveedor y de la configuración. Algunas páginas rechazan el carácter +, por lo que tampoco funciona en todos los formularios.

Para comparar alias y reenvío en detalle, lee reenvío mediante alias de correo.

Cuando el problema es el modelo de precios

Parte de esta complejidad aparece cuando el precio por usuario encarece los buzones independientes. Creas alias para evitar otra licencia y terminas dedicando horas a cabeceras SRS y políticas de reenvío en PowerShell.

La comparación histórica de TrekMail descrita aquí contrapone una cuota de servicio al cobro por cada buzón. El plan Starter ($3.50/mes) sirve como ejemplo de una oferta anterior con sales@, support@ y billing@ como buzones IMAP independientes, con acceso e identidad propios. Comprueba la tarifa vigente, los dominios y buzones permitidos y las cuotas compartidas de la cuenta. Para responder con cada identidad, verifica los permisos y la configuración del cliente SMTP; los buzones independientes no garantizan que ninguna cabecera revele otra identidad. En el modelo Nano con SMTP propio, este se necesita para todos los mensajes salientes, incluidas las respuestas; los planes de pago pueden ofrecer SMTP gestionado según sus prestaciones.

Para agencias, el plan Pro ($10/mes) para 100 dominios es también una referencia de la oferta anterior. Verifica la oferta y las condiciones actuales antes de dar de alta clientes. La herramienta de migración IMAP descrita puede copiar correo desde Gmail o cPanel con acceso autorizado y compatibilidad comprobada. Verifica carpetas y recuentos, coordina el cambio DNS y una copia final de los mensajes nuevos; IMAP no sustituye una copia de seguridad ni migra por sí solo contactos y calendarios.

Si configuras por primera vez el correo de un dominio, cómo crear correo con tu dominio explica el proceso. Consulta los precios de TrekMail para confirmar la tarifa de la cuenta, los límites y las condiciones de prueba. La oferta anterior incluía una prueba de plan de pago de 14 días con tarjeta obligatoria; comprueba las condiciones vigentes antes de registrarte.

Conclusión

Los alias pueden fallar por problemas SPF al reenviar sin SRS, bloqueos de Microsoft 365, bucles de reglas olvidadas, identidades de envío mal configuradas y conflictos con catch-all. Los códigos ayudan a investigar, pero la solución exige comprobar la ruta real, las políticas y la autenticación alineada.

Si estos problemas se repiten, quizá no sea solo la configuración: puede que estés construyendo soluciones alternativas para un modelo de precios por usuario. En ese caso, conviene revisar también la arquitectura y el plan.

Para ampliar el contexto sobre arquitectura y diagnóstico, empieza por configuración y soluciones de reenvío de correo.