Email Delivery

Email Domains Point to Microsoft Service

When an Email client program or service sends mail, it collects the list of email domain names (the part of each destination email address following the “@”). It does a DNS lookup of the domain name requesting an “MX record” response. You can do the same lookup yourself with a command:

The yale.edu domain is associated with a network destination of yale-edu.mail.protection.outlook.com which is a Microsoft address. A copy of the email is sent to that network address.

While individuals can subscribe to Office 365 with individual, family, or small business accounts, large enterprises like Yale contract for a single bulk service. We have a “tenant” account associated with our mail domain, and we manage the creation of individual accounts within that tenant. We have a similar arrangement with Google.

The user sees the Microsoft mail service as Office 365 or Outlook, just as they see the Google service as Gmail. The yale-edu.mail.protection.outlook.com address is associated with a network service technically known as ExchangeOnline (EXO). Yale defines Email addresses for each user in its own yale.edu mail domain, while Microsoft also assigns an address in its own Microsoft mail domain (@mail.onmicrosoft.com) for the same account.

Although most mail goes to “@yale.edu”, Yale also owns a number of other mail domain names. Some have been created for special uses, and some are historical artifacts. We do not create separate Microsoft tenants for them, so our one tenant treats them all as alternate domains for the same pool of accounts.

An administrator can list all of them:

When the DomainType is “Authoritative”, then mail sent to that domain must be delivered to an account in the yaleedu tenant. For DomainType “InternalRelay” the mail may end up in a mailbox in the yaleedu tenance of EXO, but it may also be forwarded to an external mail account also owned by Yale, but on a different server. For example, the mail domain “@yale.edu” receives mail for both O365 and Google/Eliapps mail users, so ExchangeOnline has to look up the account name and decide if the mailbox is local or if the mail should be forwarded on to Google.

Mail may be processed by one or more filters to block phishing, spam, malware, or other undesirable content. This is outside the scope of this document.

Recipients (Mailboxes or forwarding addresses)

Some email addresses are configured in ExchangeOnline by an administrator. Generally EXO refers to such addresses and any mailboxes associated with them as types of Recipients (the generic term for a mail address that EXO will process).

Distribution Groups logically replace a single email address with a set of configured member email addresses, and then the mail has to be delivered or forwarded to each member.

A Shared Mailbox has a single local mail account that can be read by a group of configured owners. There are also Mailboxes associated with rooms and equipment that can be reserved.

There are also Aliases defined in Exchange that receive mail addressed to an “@yale.edu” account and forward it to another Email address in some other system.

These administratively defined recipients exist only in ExchangeOnline. They are not necessarily Identities and are not associated with AD or AzureAD (a.k.a. Entra ID). However, if an Email Address is associated with one of these objects it is important that normal Identity processing not generate the same Email Address for a person. Therefore, any Email account name that consists of no more than 14 alphameric characters overlaps the Netid space and cannot be created unless a Dependent Netid is also created to reserve that name. In addition, the Email Address can be explicitly reserved by creating a Reserved Email Alias.

There are three types of Recipients associated with Identities. Their EXO names are:

UserMailbox - This is a Yale Exchange (“O365”) mail account connected to an AD User Object. The Mailbox is created after the AzureAD Object associated with the AD object is assigned an “exchange” License.

MailUser - A MailUser is an AD User Object with no exchange license and therefore no EXO mailbox, but that does have a configured RemoteEmailAddress (also known in AD as the “targetAddress” LDAP property). All students with an Eliapps mail account are MailUsers to EXO. When a mail message arrives at ExchangeOnline because of its “@yale.edu” suffix, an AD User object is associated with that email address, and the AD User object has a targetAddress in the form of “aliasname@bulldogs.yale.edu”, then EXO acts as an email client, does a DNS lookup of the “bulldogs.yale.edu” mail domain, and forwards the mail to Google.

MailContact - This is an AD Contact object with a targetAddress property. A Contact is not a user and cannot login, but the targetAddress provides an alias destination that can forward mail sent to an “@yale.edu” address to an external mail system. Currently ITS staff who have both Microsoft and Eliapps mail accounts have their AD User object associated with their Exchange account, and therefore a separate Contact object was needed to points to their “@bulldogs.yale.edu” account. No automated IAM process creates Contacts. They are manually created by some Admin and are only needed for non-standard cases.

An AD User Object without an exchange license or a targetAddress and a Contact Object without a targetAddress are not Recipients and will be ignored by Exchange.

Configure Email Addresses to Recipients

The special EXO objects created by Admins for special purposes are static, or at least they are only changed manually by the same Admins that created them.

The end user driven dynamic part of Email Addresses is configured in the Yale Email Alias database table. The Help Desk may respond to requests by adding Aliases using the Online Directory Maintenance Tool (ODMT).

Each Email Alias has an ALIAS_NAME that becomes an Email Address by appending “@yale.edu” to it. The Alias Table then associates this Email Address with a UserMailbox or a Google “@bulldogs.yale.edu” targetAddress.

IIQ reads the Alias Table every few hours. It only processes Aliases associated with a Microsoft or Google mail account. Any Alias changes result in corresponding changes to three properties of AD User objects:

• mailNickName

• proxyAddresses

• targetAddress

Every ALIAS_NAME associated with a Microsoft mailbox must result in an entry in the proxyAddresses list of the AD User object associated with that mailbox. Every ALIAS_NAME associated with a Google Eliapps mail account must result in an entry being stored in the proxyAddresses list of the AD User object that also has a targetAddress pointing to that address in the “bulldogs.yale.edu” mail domain. The Primary ALIAS_NAME is stored as the mailNickName of the User.

First the AD must be synchronized with the AzureAD (Entra ID). During synchronization, changes to these three fields are reviewed by ExchangeOnline and may be rejected if a new EmailAddress is a duplicate of an already configured Address belonging to a different recipient.

ExchangeOnline processing of Received Mail

ExchangeOnline receives a copy of any email message that contains at least one destination EmailAddress that is in one of the mail domains it is configured to manage.

Each such destination address must be matched to an entry in one proxyAddresses list. For this to be efficient, ExchangeOnline must translate the set of all proxyAddresses properties into a indexed table that maps every configured EmailAddress to a recipient.

However, the proxyAddresses that IAM configures in AD can at most be described as a suggestion to ExchangeOnline. EXO will reject any address that duplicates one it already has, and it will add additional addresses that it thinks are required if they are not provided. For example, if an AD User object has an exchange license and is therefore a UserMailbox, EXO insists that the UserPrincipalName be included in the list of EmailAddresses associated with that UserMailbox. EXO will also generate missing “@mail.onmicrosoft.com” native Microsoft addresses.

Yale Email Aliases to ProxyAddresses

Each entry in the Email Alias table maps an ALIAS_NAME to a MAILBOX, identifies the Netid that owns the alias, and flags one Alias owned by each Netid as the Primary Alias.

IAM only recognizes MAILBOX values ending in “@connect.yale.edu” (Microsoft accounts) and “@bulldogs.yale.edu” (Google accounts). Other MAILBOX values may exist, but IAM ignores those Aliases and delivery of messages to the coresponding Email Addresses would have to be manually configured by some Admin.

Until ExchangeOnline took over the processing of all incoming Yale Email, the Alias Table was used to route incoming mail to servers. The ALIAS_NAME is its primary key and guarantees uniqueness.

However, today the Alias Table populates the proxyAddresses lists in AD. To do this, IIQ views the Alias Table through Database Views that only include Microsoft and Google MAILBOX values and group together all the ALIAS_NAMEs that map to the same MAILBOX value.

The Primary Alias entry in the proxyAddresses list is given a capitalized “SMTP:” prefix, while Secondary Aliases are given a lowercase “smtp:” prefix.

The database View is used to generate a list of EmailAddresses. That list is then compared to the values in the AD proxyAddresses list from the corresponding AD User object. Any entry generated from the Alias table that is missing or different from the AD list is added to or changed in the AD.

Primary Email Alias

The Primary Email Alias also sets the value of the mailNickName field in AD which is managed by the Mail Routing Task in the Email Provisioning IIQ. It also determines the UserPrincipalName (UPN) and “mail” attribute of the User object, but those are set in the Identity Management IIQ.

Additional Email Addresses unrelated to Aliases

Separate from the Email Alias table, there are some entries added to the proxyAddresses list by IIQ because they should be there:

• The address “smtp:netid@yale.edu” is usually set, but we do not recommend using it in mail unless the netid is also the Email Alias.

• The address “smtp:netid@connect.yale.edu” is added to the proxyAddresses list so that mail addressed to it can be delivered. This is an internal name that is not published and, although it is a MAILBOX value in the Alias table, it would otherwise not be known to EXO.

• The “smtp:aliasname@mail.onmicrosoft.com” native Microsoft address if necessary because EXO will add it to the EmailAddresses list in the cloud and we don’t want the LocalAD and AzureAD to have differences.

The native Eliapps mail address “aliasname@bulldogs.yale.edu” is not added to the proxyAddress list because the bulldogs.yale.edu Mail Domain has an MX record pointing directly to Google and external mail for such an address does not pass through EXO. When an Outlook user sends mail to such an address, Exchange has no special outbound processing, looks up the MX record as if it were any non-Yale address, and sends the mail to Google.

However, “SMTP:aliasname@bulldogs.yale.edu” is added to the targetAddress property of the AD User object for Eliapps mail owners. Therefore, external mail for “aliasname@yale.edu” is received by ExchangeOnline, is processed by mail filters, and is then forwarded to Google using the targetAddress/ExternalEmailAddress because Eliapps accounts are MailUser Recipients.

The MailNickName

Once upon a time each department could have its own local mail server. With a small number of users, it made sense to address mail “to: Fred” and then the mail would go to user “Fred” in the department.

PC Mail became Exchange, then Exchange because an Enterprise Cloud Service. However, to maintain compatibility Microsoft preserves the ability to give a short MailNickName to every user. The MailNickName is a required field, so if you have a hundred thousand users, the unique mail nickname can no longer be short. We set the MailNickName field to the Primary AliasName, which is guaranteed to be unique.