Exchange Server (And Exchange Online) can be a little confusing at times, particularly when we’re dealing with mail routing. Internal mail routes are handled almost automatically (especially if you keep all your Exchange servers in the same AD Site, which I recommend), but how do you get it to route email to mail servers *outside* your organization? What about partner companies, business departments with their own AD forests, or between on-prem and cloud mail platforms? Most environments don’t have to mess with complicated mail routing issues, but if you’re a consultant, or if you are working with a large Exchange deployment with multiple partner organizations, you will need to understand how mail routing works in Exchange. There are 3 pieces to this; Exchange Organizations, Accepted Domains, and Connectors.
Exchange Organizations
This portion of Exchange Mail routing is more about terminology than function. Put Simply, an Exchange Organization is an number of Exchange mail servers that exist in a single Active Directory (AD) forest. Exchange is heavily integrated with Active Directory, which is Microsoft’s technology that allows central control of usernames, passwords, and computers/devices. If you’re trying to learn Exchange Server and you don’t know anything about Active Directory, stop and learn that first, or you will have a lot of problems understanding what is going on.
An Exchange Organization covers every single Exchange server that exists in the same AD forest. You can’t have two Exchange Organizations in the same forest, and this is an important concept, because email routing in each Exchange Organization is controlled with Active Directory Sites and not traditional email routing techniques. If two users in the same AD Forest want to send email to one another, it doesn’t matter what their @domain.com email address is (As long as it’s an accepted domain for that Organization), mail routing will be done automatically by Exchange based on which AD Site each each user’s mailbox is located in.
The need for clear terminology is because Exchange deployments in different Forests have to be routed properly to work right. This is especially complicated if multiple Exchange Organizations have users with the same email domain (@domain.com).
Accepted Domains
Accepted domains are the core component of Exchange email routing. Each domain represents the portion of an email address after the @ sign. So for my email address, adam@acbrown-it.com, the Exchange environment that managed my email has acbrown-it.com as an accepted domain. In Exchange Server (On-prem) there are also three types of accepted domains. For Exchange Online, there are two types of accepted domains. The accepted domain types are:
- Authoritative
- Internal Relay
- External Relay (On-prem only)
Each type of accepted domain functions differently and, depending on circumstances, can be used to route email. It’s worth noting here that the name of each type doesn’t necessarily make its function obvious. Here’s how they work…
Authoritative Domain
You might think that an Authoritative domain would be a central server for a specific email domain. For instance, if you had an environment that had multiple Exchange organizations, the name “Authoritative” would make you think that you would set the @domain.com domain as authoritative on the main Exchange server that receives email for this domain. This is not how it works. When a domain is set as authoritative, that tells Exchange that all mail routing for the domain will STOP at this organization. If you were set up with two Exchange organizations that had @domain.com email addresses in them and you set the first server that received email for that domain as authoritative for the accepted domain, no email would ever reach the second Exchange organization. In this case, Authoritative should be seen as the Exchange server saying, “The buck stops here!” for all email in that domain.
Internal Relay
Internal Relay domains are used in situations where more than one Exchange Organization contains users with the same email domain. When an organization is set up to use an Internal Relay domain, it will look for a mailbox that matches the email address in its own organization first, but if it doesn’t find that mailbox, it will send the message off to another organization. This is very important to remember, because you have to decide where the email will go next using a Send Connector (explained later). If you use Internal Relay domains, note that Email routing between organizations *must* stop at an authoritative domain. If it doesn’t, email will get NDRs referencing Loop Detection, which is a pain.
External Relay
An External Relay domain only exists in on-prem Exchange. External Relay works similarly to an Internal Relay domain, except that Exchange will *not* check its own recipient list to see if the email address matches. Email addresses that match an External Relay domain will be immediately forwarded without any real processing. This type of accepted domain has very little functional use these days, except to allow for a hub and spoke architectural design, when a single entity acts as a central point for mail. With an External Relay domain, that central point can relay messages to as many other entities as it wishes without wasting CPU cycles checking the recipient lists before forwarding the messages to their ultimate destination. This type of accepted domain is not available in Exchange Online, simply because Microsoft wants you to check the recipient list before forwarding messages, and to reduce complexity (Since Office 365 is heavily marketed toward smaller businesses whose technical staff may be lacking experience or knowledge, and having this option available might confuse people).
Send Connectors
Accepted domains aren’t enough to properly route mail through Exchange, since they just tell the system what to do with email once received. After messages are processed against the accepted domain list, Exchange has to know what to do with them. This is where send connectors come in.
Each send connector is configured to apply to a specific list of domains (Or all domains, if the connector uses the * address scope). If the transport service sees an email it needs to send outside the Exchange organization, it will process the email domain against the list of send connectors to determine how to send the message. Each send connector has an address “scope” or address space that determines when it’s supposed to be used. If the email domain of the recipient on the email that is being sent outside the organization matches the send connector, that connector’s rules will be used.
One important thing about send connectors that you need to remember is that there should always be a connector with an address space that has just an asterisk (The star symbol) as shown here:
This will always be processed *last* and ensures that emails that don’t match any other send connector get routed properly (Unless you only want the Exchange server to route to domains you specify, in which case, leave off the * connector from the list…also, you’re crazy if you want to do this).
If you want to get really, unnecessarily complicated, you can also configure Scoped Send Connectors (to ensure only Exchange servers in a specific AD site can use the connector) or implement secondary connectors for the same domain (If you want to allow Exchange to have a second location to send mail to if the first location fails). I don’t recommend doing either of these things. If you find that you do need to, you may need to re-examine your Exchange architecture (Up to you).
The Delivery tab of the send connector properties is where the work of a send connector is defined. By default, the connector will follow the MX record settings that the server sees when determining where mail is sent. It’s important to note here that you have to pay attention to what the *server* sees, not what is available to everyone on the Internet. If your Exchange server is set up to use a Domain Controller for DNS, you can create your own MX records for any domain in the world by creating a Forward Lookup Zone for that domain, then creating MX records to route mail for that domain. Again, I don’t recommend doing this, just note that it’s a possibility, so make sure you are taking that into account when troubleshooting.
More common, however, is what is called “Smarthost” delivery. A Smarthost is basically any SMTP server that is capable of determining how to properly handle the message. Almost every mail server in the world can be used as a smarthost, but you should have a specific purpose in mind when using this setting. For instance, if you want to send all email to a spam filter for processing and relay, you would set up an address space of * and set the smarthost to the spam filter’s IP/DNS address. Your Exchange deployment is probably configured to do this already (Even Exchange Online has a hidden send connector that points outgoing email to Exchange Online Protection). If, however, you want to send email for a specific domain to a specific server, you would set the address space to equal the domain, then set the smarthost to be the IP/DNS address of that server.
Summing Up
If you understand the relationship between send connectors and accepted domains, you can do a lot of really cool stuff. For instance, you could have half your users in Office 365 and half in Google Apps (Probably not the best idea, but it’s possible). Exchange Hybrid configurations make heavy use of accepted domains and send connectors to properly route email between cloud and on-prem users. And there are plenty of other use cases. If you’re feeling brave or working in a test lab, tinker around with these settings a bit and see what nifty tricks you can pull, but take care to remember the rules as I’ve explained them. If you don’t, you may spend hours troubleshooting just to find yourself feeling really dumb when you discover that the accepted domain isn’t set right or the send connector sends to the wrong server.
