Exchange Server EMail Routing – Accepted Domains and Send Connectors

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:

  1. Authoritative
  2. Internal Relay
  3. 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:address space

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.

Advertisements

Clearing Logs from All Exchange Servers

Here’s a fun script. There are plenty of scripts that clear logs from an Exchange server, but this one goes the extra mile by doing it on every Exchange server in your environment (CAS, HUB, and MBX). The short explanation for why is that I work with 16+ node Exchange deployments, so setting up a single-server script on multiple servers is a huge pain. I imagine other people are dealing with that as well.

The script will pass through a list directories that are stored in a hash table and delete all .log files in that directory and all child directories, based on the age of the file (older than 7 days by default).

This script is *not* meant to clear Transaction Logs and should not be configured to do so, though it is certainly possible to configure it to do so. You’ve been warned.

#This line will check to determine if the Exchange Snapin is added. If not, it will add it. For other Exchange versions, change to match your version's snapin name.
if((get-pssnapin | where {$_.name -eq "microsoft.exchange.management.powershell.snapin"}) -eq $null){Add-PSSnapin microsoft.exchange.management.powershell.snapin}

#Pulls a list of Exchange servers.
$servers= Get-exchangeserver

#This foreach loop will pass through the list of servers one at a time and run an invoke-command command against each server. The invoke-command script
#uses a hash table that holds each log file folder.
foreach ($server in $servers)
{
    #This command will run a script that cycles through a Hashtable of paths to pass to a delete command. Change the file paths to match your environment.
    #Current paths are Exchange and IIS defaults.
    Invoke-Command -ComputerName $server -ScriptBlock {
        #Number of days worth of files you want to retain when the script runs. This value should be negative because the .AddDays() method doesn't do subtraction,
        #and there is no .RemoveDays() method. So if you wanted to keep 14 days of files, you would set this value to -14. Default is -7.
        $x = -7
        #User Instruction - Change $dirnumber to match the number of directories you would like the script to clear.
        $dirnumber = 3
        #This hashtable is used to store paths where you would like to delete files. Hashtable starts with 3 entries, add more by appending a comma, then
        #the path in quotations. Be sure to add the file extension (*.log for log files) that you want to erase to avoid potential disaster. Also, don't do transaction logs.
        $dirs = @{dir="C:\Program Files\Microsoft\Exchange Server\V15\Logging\*.log","C:\inetpub\logs\LogFiles\W3SVC1\*.log","C:\inetpub\logs\LogFiles\W3SVC2\*.log"}
        #Simple counter object to keep track of which cycle the deletion script is on.
        $i=0
        #This is the loop that does all the magic. As long as the cycle number ($i) is less than the number of directories in the $dirs hashtable,
        #the loop will continue cycling, finding and removing files based on
        while ($i -lt $dirnumber){
            $files = dir $dirs.dir[$i] -recurse | where {$_.LastWriteTime -lt ((get-date).AddDays($x))} | Remove-Item -Confirm:$false -force -ErrorAction SilentlyContinue
            $i++
        }
    }
}

Adam’s O365 Tips and Tricks Part 1: Exchange Online Email Recovery and Retention

With most people moving to Exchange Online or other cloud-based solutions for email, I’ve decided to write up some tips and tricks that might not be well known, but will give you some useful tools for managing Office 365 (Well, I guess they’re calling it Microsoft 365 now), which is the cloud service I am most familiar with. I’ll be expanding and adding articles on the subject as I come up with ideas and remember things I’ve done through the years, so be sure to check back periodically to see what’s new. For this edition, I’ll be covering Exchange Online Backups

Exchange Online Backups Aren’t Necessary!

One thing that drives me bonkers about the third party tools market for Office 365 are the number of companies selling Office 365 Backup Services. Some of that may be helpful for things like OneDrive and SharePoint (Unless you have an E3 license), but Exchange Online provides numerous tools for recovering email and handling retention for all license levels, as long as it’s configured correctly.

Recovering Deleted Emails

The most important thing you can do with Exchange Online is to make sure that a feature called “Single Item Recovery” is enabled. What this feature will do is allow admins to recover any deleted item in any mailbox, even if the user has purged it from the Deleted Items folder (Available by Right-Clicking Inbox and selecting “Recover Deleted Items”). Single Item Recovery will allow items to be deleted, but will retain them for a period of time that you can configure in Exchange Online Powershell (Default is…*Forever*). Recovering emails usually requires the InPlace eDiscovery feature in the compliance tools (Those controls have moved around a lot, so just look for any compliance search features in EoL’s admin portal or the O365 Portal). For a more in-depth look at the feature, visit this Technet Blog.

Fun With Shared Mailboxes

One of the more entertaining features of Exchange Online is Shared Mailboxes. A Shared Mailbox is a limited functionality mailbox that (currently) has a 50GB limit, does not have a password (and so can’t be logged into directly), and is FREE. Yes, you read that correctly. You can have as many shared mailboxes in your EoL tenant as you want and don’t have to pay a license for them. This opens up a world of possibilities for creative admins. Just realize that you have to grant users permission to open these mailboxes before they can be accessed. By default, once you grant permission to a shared mailbox, it will auto-mount in Outlook after about an hour (you can keep it from mounting automatically by using PowerShell to grant the permission with the -automapping switch set to $false).

Shared Mailboxes feel very much like a legal gray area in Exchange Online, because even the entry level subscriptions for EoL allow them and they can be used to mimic many of the higher cost subscription features. If you feel icky about these tips, feel free to ignore them, as the legality of these uses really isn’t documented anywhere. Microsoft’s licensing tactics are notorious for being extremely complicated and confusing (I like to joke that understanding Microsoft’s licensing requires a chicken, a sacred altar, and an obsidian dagger crafted under the light of a blood moon), so take all this under advisement.

Terminated User Retention

If you are off-boarding an employee that is leaving the company for any reason, it is always a good idea to retain a copy of that user’s email for legal or transitional purposes. Most of the time, admins will access the user’s mailbox and export it to a PST for safe-keeping. This is absolutely still a possibility in EoL, but why use your own on-prem data storage to keep the email when you can convert the mailbox to a shared mailbox and have that users’ email available in the cloud for as long as you want without having to pay for it? It’s a great trick for handling data retention following an employee leaving. The EoL admin portal even makes it easy for you. Just click on the recipient and click the “Convert to shared mailbox” button. The process may take a while to finalize, since Shared Mailboxes are stored on different databases with cheaper storage than live mailboxes. Once the process is complete, however, you can either leave the mailbox as is or grant access to people who need it.

Mailbox Extension

This one is more legally questionable than terminated user retention (which seems to be perfectly acceptable, given the ease of implementation), and is entirely theoretical from a licensing standpoint, so if someone knows whether this is allowed or not, feel free to comment and I’ll remove this section. That said, it’s possible to use shared mailboxes to give a user more storage space for their mailbox.

The current limits for Exchange mailboxes are extremely generous, with 50GB for Business and E1 subscriptions, 100GB for E3 and up. Most organizations won’t use up a portion of that storage for email (especially considering the attachment limit of 50MB), but some executives and administrative staff members may break those limits, particularly in larger environments.

To add a shared mailbox as an extended storage space for a user’s mailbox, you need only create the shared mailbox in Exchange Admin > Recipients > Shared and add the necessary user as a “Delegate” with full access permissions. Instruct the user to move or copy emails to the new mailbox once it populates in Outlook, and voila. More mailbox. You can do this as many times as you feel necessary, just understand that adding mailboxes to Outlook can cause significant slowdowns once there are more than 3-4 additional mailboxes mounted.

Additional “FROM:” Addresses

One of the inherent limitations of Exchange that MS has either not been able to solve or has chosen not to solve is that each mailbox can only have a single email address assigned as the “From:” address. If you want to send email using multiple email addresses, you have to have an additional mailbox. The solution for this conundrum in Office 365 is to create a shared mailbox that has the additional email address set as the Primary SMTP address, then grant the user’s regular mailbox Send As permission on the mailbox. You can then choose whether to set up email forwarding on the shared mailbox to redirect messages to the primary mailbox (Preferred) or grant full access to the shared mailbox and mount it as a secondary.

End of Part 1

Hopefully one of these tips proves useful for you (The list is short right now, but I expect it to expand in time), and if you happen to know of a good trick, tool, or tip for other admins, let me know and I’ll add it to the list.