¿Que son los dominios Aceptados? | Exchange 2016

Hola amigos,

En esta sencilla publicación, explicaremos los dominios aceptados bajo los cuales trabaja Exchange Server, esto aplica no solo para Exchange 2016, si no también para Exchange Online (varia un poco), 2013, 2010 y 2007. Coff Coff, también conocido como el Poderoso Exchangiiiiiiii

El concepto de dominios aceptados se presentó inicialmente en Exchange 2007 y se ha seguido usando en las versiones subsecuentes. Como bien sabemos Exchange Server en palabras sencillas es un servidor de calendario y de correo electrónico corporativo. Para que este ruteo (o relay) de correo funcione de manera apropiada primero deben ser configurados los llamados dominios aceptados (Accepted Domains)

¿Que es un Dominio Aceptado?

El nombre de espacio (Name space o Address space) de SMTP (Simple Mail Transfer Protocol) para el cual un servidor de Exchange Server envía y/o recibe correo electrónico.

¿Que tipos hay?

Existen 2 tipos de dominios aceptados

1. Dominios autoritativos (Authoritative Domains)
2. Dominios de ruteo (Relay Domains: Internal Relay / External Relay)

¿Que hace cada uno?

AUTHORITATIVE DOMAINS:  Estos son los dominios para los cuales Exchange aceptara correo, de los cuales somos propietarios y tenemos alojados todos los buzones dentro de una misma organización de Exchange.

INTERNAL RELAY: Estos son los dominios para los cuales Exchange aceptara correo, pero no necesariamente todos los buzones se encuentran en una misma organización, a esto se le conoce como un espacio de nombre compartido (Shared SMTP namespace).  Es decir, buzones de un mismo dominio, pueden estar alojados en diversas organizaciones de Exchange. Este tipo de dominio aceptado es comun durante adquisiciones corporativas.

EXTERNAL RELAY:  Estos son los dominios para los cuales Exchange aceptara correo,  sin embargo no cuenta con buzones alojados en su organizacion (es),  simplemente lo rutea a una organización ajena(externa) ya sea de Exchange o de otro sistema de correo. Esto similar a lo que realizan las empresas de anti-spam y seguridad de correo, como ProofPoint o Symantec Cloud, aceptan el flujo de un dominio del cual no tienen buzones

Nota: Cabe mencionar que Exchange online solo cuenta con Authoritative e internal relay

ORGANIZACIONES:

ORG1 – México

ORG2 – Chile

ORG3 – Colombia

ORG4 – Perú

ORG5 – España

ORG – Office 365

Escenario 1: Somos dueños de la compañia imvoacevedo.com,  contamos con una sola organización de Exchange Server en México llamada: ORG1

Supongamos que usuario@externo.com manda un correo a geovany@imvoacevedo.com

1. los servidores de externo.com haran un query de DNS hacia el dominio imvoacevedo.com buscando los MX
2. En los DNS públicos de imvoacevedo.com habrá un registro MX (Mail eXchanger) que indicara a que IP se debe enviar el correo (comúnmente un firewall o una solución de seguridad en la nube)
3. El servidor de correo de externo.com entonces enviara el correo a la IP indicada
4. El firewall o IP que reciba a su vez ruteara el correo a los servidores de Exchange Server (esto es comunmente seguridad perimetral)
5. México-ORG1 al tener imvoacevedo.com como autoritativo Exchange aceptara y depositara localmente el correo al buzón y de no encontrarlo, mandara un NDR (Non-Delivery Report) indicando que no existe

Escenario 2: Nuestra organización en México (ORG1) ha crecido y absorbió la compañía Marsupial.com que se encuentra en Chile bajo la organización de Exchange ORG2.

El acuerdo del merger fue que no abra buzones con el dominio @marsupial.com en México (ORG1), Sin embargo, el flujo debe ser centralizado y pasar a traves de México (ORG1) antes de ser enviado a Chile (ORG2)

Supongamos que usuario@externo.com manda un correo a eduardo@marsupial.com

1. los servidores de externo.com haran un query de DNS hacia el dominio marsupial.com buscando los MX
2. En los DNS publicos de marsupial.com habra un registro MX (Mail eXchanger) que le indicara a que IP enviar el correo (comúnmente un firewall o una solución de seguridad en la nube)
3. El servidor de correo de externo.com entonces enviara el correo a la IP indicada
4. El firewall o IP que reciba a su vez el correo lo enviara a los servidores de Exchange Server (esto es comunmente seguridad perimetral)
5. México-ORG1 aceptara el correo y buscara por un buzón «eduardo@marsupial.com» localmente, de no encontrarlo ruteara el correo a través de un conector SMTP de envio hacia Chile-ORG2 (previo a esto se debe configurar los conectores de ruteo, pero no entraremos en detalles, eso en otra publicación)
6. Chile-ORG2 a su vez tendrá un conector de recepción, teniendo como autoritativo el dominio marsupial.com aceptara el correo y depositara el mensaje al buzón y de no encontrarlo enviara un NDR (Non-Delivery Report) indicando que el buzón no existe, cabe mencionar que si un mensaje es enviado de ORG2 hacia un buzón del mismo dominio @marsupial.com, este no sera ruteado a México-ORG1 ya que chile-ORG2 es autoritativo de ese dominio, es decir, solo existen buzones con ese dominio en esa organización de Exchange

Escenario 3: Nuestra creciente empresa, adquiere una compañia independiente que no cuenta con infraestructura propia de mensajeria: Tlacuache.com

El requerimiento es que en ambas organizaciones de Exchange: Mexico (ORG1) y Chile (ORG2) compartan el espacio de nombre tlacuache.com y alojen buzones con ese dominio

Supongamos que usuario@externo.com manda un correo a dos recipientes: elcanaca@tlacuache.com y elferras@tlacuache.com

1. los servidores de externo.com haran un query de DNS hacia el dominio tlacuache.com buscando los MX
2. En los DNS publicos de tlacuache.com habra un registro MX (Mail eXchanger) que le indicara a que IP enviar el correo (comúnmente un firewall o una solución de seguridad en la nube)
3. El servidor de correo de externo.com entonces enviara el correo a la IP indicada
4. El firewall o IP que reciba a su vez el correo lo enviara a los servidores de Exchange Server (esto es comunmente seguridad perimetral)
5. México-ORG1 teniendo tlacuache.com como internal relay aceptara el mensaje y buscara por los buzones elcanaca@tlacuache.com y elferras@tlacuache.com localmente, depositara el correo para elferras@tlacuache.com, sin embargo no encontrara el buzón elcanaca@tlacuache.com por lo cual ruteara el correo a través de un conector SMTP de envío hacia Chile-ORG2 (previo a esto se debe configurar los conectores de ruteo, pero no entraremos en detalles, eso en otra publicación)
6. Chile-ORG2 a su vez tendrá un conector de recepción y teniendo como internal relay tlacuache.com, aceptara el correo y lo depositara al buzón. De no encontrarlo el buzón enviara un NDR (Non-Delivery Report) indicando que no existe. Cabe mencionar que si un mensaje es enviado de Chile-ORG2 hacia el un buzón del dominio @tlacuache.com, de no existir localmente este sera ruteado hacia México-ORG1 dado que comparten el espacio de nombre

Escenario 4: Nuestra empresa, comienza a ofrecer servicios de limpieza y seguridad de mensajeria.

Adquiere un contrato con la empresa Moyol.com en Colombia (ORG3). En el cual todo el flujo de correo de este dominio debe ser «limpiado» por la seguridad de México (ORG1) antes de llegar a Colombia-ORG3. Cabe mencionar que a diferencia de ORG2, ORG3 es una empresa independiente y no tiene directa relación con nuestra organización. Es pues, una organización externa

Supongamos que usuario@externo.com manda un correo a Enrique@moyol.com

1. los servidores de externo.com haran un query de DNS hacia el dominio moyol.com  en busca de los MX.
2. En los DNS publicos de Moyol.com habra un registro MX (Mail eXchanger) que le indicara a que IP enviar el correo (comúnmente un firewall o una solución de seguridad en la nube)
3. El servidor de correo de externo.com entonces enviara el correo a la IP indicada
4. El firewall o IP que reciba a su vez enviara el correo a los servidores de Exchange Server (Esto es comunmente seguridad perimetral)
5. Al tener definido moyol.com como un domino aceptado de tipo external relay, México-ORG1 aceptara el correo, aplicara los controles de seguridad y anti-spam, sin embargo, no intentara buscar el buzón localmente
6. México-ORG1 buscara el conector de envio a través del cual rutear moyol.com  (comúnmente a traves de un smarthost)
7. -Colombia-ORG3 a su vez tendrá un conector de recepción para correos provenientes de México-ORG1 y teniendo como autoritativo el dominio Moyol.com, aceptara el correo y depositara el mensaje, de no existir el buzón enviara un NDR (Non-Delivery Report)

Escenario 5: Nuestra organización (ahora global) absorbe una nueva compañía llamada cacheton.com y decide comenzar un ambiente híbrido con Office 365

El requerimiento es que todos los buzones de cacheton.com esten alojados en la nube al igual que los altos ejecutivos del domino imvoacevedo.com

Supongamos que usuario@externo.com manda un correo a Francisco@imvoacevedo.com y Salvador@cacheton.com

1. los servidores de externo.com haran un query de DNS hacia los dominios cacheton.com e imvoacevedo.com  en busca de los MX.
2. En los DNS publicos de de estos dominios habra un registro MX (Mail eXchanger) que le indicara a que IP enviar el correo (comúnmente un firewall o una solución de seguridad en la nube)
3. El servidor de correo de externo.com entonces enviara el correo a la IP indicada
4. El firewall o IP que reciba a su vez enviara el correo a los servidores de Exchange Server (Esto es comunmente seguridad perimetral)
5. México-ORG1 aceptara los correos al tener imvoacevedo.com y cacheton.com como Internal relay
6. México-ORG1 buscara por los buzones, de no encontrarlos, enviara el correo a través de conectores de envío. Cabe mencionar que imvoacevedo.com es un dominio hibrido por lo cual al momento que fueron migrados los buzones se les estampo una dirección del tipo @imvoacevedo.mail.onmicrosoft.com mientras que cacheton.com es un dominio nativo de 365 (No entraremos en detalles sobre un ambiente híbrido)
7. -Office 365-Exchange Online ORG a su vez tendrá un conector de recepción para correos provenientes de México-ORG1 y teniendo como autoritativos los dominios , aceptara y depositara los correos, de no existir el buzón enviara un NDR (Non-Delivery Report)

Nota: Todos estos diagramas son a alto nivel. En un ambiente de producción entran en juego varias tecnologías que permiten la sincronización de objetos para evitar que el NDR lo mande el servidor final. Por ejemplo FIM que hara sync de usuarios a la solución perimetral, Edge servers y edge-sync, relaciones de confianza entre forest de AD, GAL sync, Site-Links entre organizaciones, reglas de transporte, configuración de conectores para ruteo, tipos de conectores, diferentes puntos de entrara del correo a las organizacion, diferentes soluciones de correo ajenas a Exchange server como lo es Lotus dominos  o Postfix, como funcionan los dominios aceptados en ambiente hibrido etc. Sin embargo la idea de esta publicación es enfocada a los dominios aceptados y no enteramente a como rutear el flujo de correo. Utilicen estos diagramas como referencia y no como solución absoluta

Como pueden ver en la imagen siguiente, el ambiente puede seguir creciendo y aumentando la complejidad, componentes involucrados, etc.  Sin embargo los principios básicos siempre serán los mismos referente a los dominios aceptados. Si entienden lo básico lo demas sera mas fácil

¡Enhorabuena!

Acaban de aprender los principios básicos de los dominios aceptados en Exchange server, coman una galleta y dense una palmada en la espalda, se lo han ganado

Por Geovany Acevedo

Coman frutas y verduras