_______________________________
In This Chapter
- Mail Flow Connectors
- Message Tracing
- Transport Rules
- Accepted Domains
_______________________________
The flow of e-mail is THE most important part of Exchange Online. Without proper mail flow, the proper function Exchange Online in an organization breaks down. Potential problems with Exchange that would interrupt mail flow are Internet connection issues or Office 365 Service Issues. Being able to properly configure, maintain and troubleshoot SMTP in the messaging system is key.
The Exchange Admin Center (EAC) provides a way to configure mail flow features like send and receive connectors, transport rules, journaling and message traces. However, the EAC is limited in many ways and some configuration options REQUIRE the use of PowerShell as no option is offered through EAC. Examples of this are usually found in the expanded control of connectors and Centralize Transport settings in Office 365.
This chapter will cover the various parts of Exchange Online mail flow from what the components are, the cmdlets used to configure them as well as cmdlets used to troubleshoot mail flow issues that could come up.
If you have a Hybrid configuration, the SMTP connectors can be key to making mail flow functional in Exchange Online. By default there are no connectors for sending and receiving email in Exchange Online. This may seem strange for anyone who has managed Exchange on-premises before, but it will make sense once we dive deeper into it. By default there is a no need to configure a Send Connector as email will flow outbound via internal mechanisms that are built into your Exchange Online tenant.
Let’s explore the PowerShell cmdlets that can manage, report or modify connectors in Exchange:
Get-Command *connector*
By default, a brand new tenant has no connectors that will show with the Get-*Connector cmdlets:
Get-InboundConnector
Get-IntraOrganizationConnector
Get-OutboundConnector
No connectors exist by default:
So what does this mean for your Office 365 Tenant? How does mail even flow without connectors? By default Exchange Online Protection (EOP) handles the connections for Inbound and Outbound traffic. Microsoft provides good documentation on this here:
That begs the question, if mail will flow to and from your Exchange Online tenant, why would we need to configure a connector in Exchange Online? There are a few scenarios that would require specific connectors created. One of these is Exchange Hybrid. If you have an Exchange Server, or other mail system, that is on-premises and you are transitioning to Office 365, then you will need connectors. Inbound and outbound connectors will probably both be needed in order to configure Hybrid with the legacy mail server. If running Exchange on-premises with Exchange Online, utilize the Hybrid Configuration Wizard to configure these options.
Another scenario is if journaling is configured, the end point for the journaled messages may require a specific connector. This connector would possibly use smart host settings, authentication and more. Another scenario would be if you require the connection to use Transport Layer Security (TLS) and if a TLS connection could not be established, then the connection would not be made and email not delivered. Banks and other institutions could require this. This is otherwise known as a mandatory TLS connection.
Example
For this example, we would like to route email from our on-premises mail server which is not an Exchange server and thus no Hybrid connector will be created. From the connector cmdlets, it looks like the *InboundConnector noun is the one we need for this scenario. First, we can review the Get-Help on the cmdlet:
A sample connector can be created like so:
New-InboundConnector -Name 'Inbound Mail Connector' -ConnectorType 'OnPremises' -ConnectorSource 'Default' -Enabled:$True -CloudServicesMailEnabled:$True -TlsSenderCertificateName 'mail.scolesfamily.net' -SenderDomains @('*') -RequireTls:$True -RestrictDomainsToCertificate:$True -RestrictDomainsToIPAddresses:$False
Notice these parameters:
ConnectorType - this is the source of the traffic, in our case an on-premises mail server
CloudServicesMailEnabled - default setting, allows for cross-premises message header tags
Example
In this example we are taking an on-premises connector that is used to force a TLS connection to a particular banking institution. The connector has a couple of parameters that we need to copy to the new one in Exchange Online:
SMTP SmartHost - mail.bankinstitute.net
Domains - (a list of 50+ domains...)
The original connector has quite a few domains, so using PowerShell to store this in a variable and then pass this along to the Exchange Online connector would be the best way to do so.
Let's review what the cmdlet, New-OutboundConnector, has for examples:
The above example does not include our need for adding a list of domains for the connector, but if we review the full help for the cmdlet, we see we can use 'RecipientDomains' for this. There is also an option called 'SmartHost' where we can specify the remote destination for emails that match this connector:
# Store all domains in a $Domains variable
$Spaces = (Get-SendConnector "Bank Institution Connector").AddressSpaces
$Domains = @()
Foreach ($Space in $Spaces) {
$Domains += $Space.Address
}
# Connect to Office 365
$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session
# Configure new Send-Connector
New-OutboundConnector -Name "Banking" -ConnectorSource Default -ConnectorType Partner -TlsSettings DomainValidation -TlsDomain *.bankinstitute.net -Enabled $True -SmartHost mail.bankinstitute.net -RecipientDomains $Domains -UseMxRecord $False
Some additional parameters to cover here:
TLSDomain - The domain(s) to be secured by this connector. If an email is set to a domain on the list, the email will be routed through this connector.
TLSSettings - The connector will verify the FQDN of the target server's certificate and that it matches the domain in the TLSDomain parameter.
Now we have a connector in Exchange Online that uses TLS to server mail.bankinstitute.net and if no TLS connection can be made the connection will fail and no mail will be transported. If the connection succeeds, all mail will be transported securely. The connection between the servers is now secure, however, no security is applied directly to the message like S/MIME or IRM.
Removing an existing connector is sometimes needed after a service is retired or internal mail servers are removed. PowerShell provides a cmdlet that allows for the removal of a connector. To find out about this cmdlet, use the Get-Help:
Get-Help Remove-InboundConnector -Examples
Get-Help Remove-OutboundConnector -Examples
Using the above examples, we can write a small one-liner to remove any old or test connectors that are no longer needed. To remove the connector, the Remove-ReceiveConnector needs an identity of the connector to be removed. The help file also provides information on what comprises an appropriate identity for the Receive Connector.
Remove-ReceiveConnector “BOA”
In practical terms, a report on connectors would be good for overall Exchange Online documentation and not much else. A report like this would be just another page in an environment's documentation, providing a comprehensive look at the servers. Connectors, both Outbound and Inbound, have quite a few properties that could be documented. Cherry picking properties is not advisable because a missed property could cause an issue on a rebuild of a connector. So, a simple way to document a connector is to export all settings to a text file.
Example - Documenting One Connector
Get-OutboundConnector | fl > 'C:DocumentationOutboundConnector.txt'
Part of the Receive-ApplicationRelay.txt file:
Example – Document All Connectors
$Inbound = (Get-InboundConnector).Name
Foreach ($Connector in $Inbound) {
Try {
Get-InboundConnector -Identity $Connector -ErrorAction STOP | fl > 'C:DocumentationInboundConnector.txt'
Write-Host “The Inbound Connector $Connector has been documented.” -ForegroundColor Cyan
} Catch {
Write-Host “The Inbound Connector $Connector has not been documented.” -ForegroundColor Red
}
}
$Connector = $Null
$Outbound = (Get-OutboundConnector).Name
Foreach ($Connector in $Outbound) {
Try {
Get-OutboundConnector -Identity $Connector -ErrorAction STOP | fl > 'C:DocumentationOutboundConnector.txt'
Write-Host “The Outbound Connector $Connector has been documented.” -ForegroundColor Cyan
} Catch {
Write-Host “The Outbound Connector $Connector has not been documented.” -ForegroundColor Red
}
}
Using the Try and Catch along with Foreach loops the above script will document all Send and Receive Connectors. There is also some visual feedback as to which connectors are properly documented and which ones are not. Below is the visual output from the script:
One of the options when configuring Hybrid with Exchange Online and Exchange On-Premises is a concept called Centralized Mail Transport. Centralized Mail Transport routes all emails from your Office 365 mailboxes to your on-premises servers before sending them to the Internet. The reason an organization would do this is if there is an internal processing that is needed for all messages in an environment - journaling, Data Loss Prevention (DLP), etc. - that would necessitate all emails to flow back to an on-premises servers. Inbound messages that are directed to your Exchange Online tenant will also pass through Exchange:
Adding Centralized Mail Transport
There are two ways to add this to your tenant. One is to use the Hybrid Configuration Wizard and the other is to use PowerShell to change 'RouteAllMessagesViaOnPremises' settings in order to turn it on. This setting is a property on the Outbound Connector that was created by the Hybrid Connector. In most cases this property will be off and only because Microsoft does not recommend it for most organizations and turns it off by default. If, however, we need this setting to be true, we simply need to run the following:
Set-OutboundConnector 'Hybrid Mail Flow Outbound Connector' -RouteAllMessagesViaOnPremises $True
** Note ** Make sure you have good reason to turn on Centralized Mail Routing as it does indeed affect the way emails are routed in your environment.
Removing Centralized Mail Transport
In order to remove this setting, we need to configure the property to the opposite value, like the below example:
Set-OutboundConnector 'Hybrid Mail Flow Outbound Connector' -RouteAllMessagesViaOnPremises $False
** Note ** One caveat to turning this on is that if there is an issue with the mail from between on-premises and Exchange Online, messages could queue up and eventually fail.
In Office 365, tracking down a message requires the use of Message Trace PowerShell cmdlets. A good introduction to this was provided in Chapter 9. Please refer to page 187 for more information on how to track down a message.
Transport Rules can be used for so many purposes. These rules are usually created in the EAC, however, there are some rules that are easier to create in PowerShell due to the amount of options available. Let’s start with what is available outside of PowerShell.
Within the EAC there are some pre-canned templates for Transport Rules:
While these rule templates make life easier for making certain rules, PowerShell provides for additional configuration options not available in the web interface. With this thought in mind, this section will cover the Transport Rule PowerShell cmdlets. First, start with what cmdlets are available for Transport Rules:
Get-Command –Noun TransportRule
** Note ** In the above PowerShell cmdlet, a difference technique is used to find a cmdlet. The term we are searching for in the PowerShell cmdlet is in the noun (right of the hyphen) portion of the PowerShell cmdlet. We can use the ‘-Noun’ parameter to find cmdlets with the ‘TransportRule’ phrase in the noun.
Let’s now examine these cmdlets in the context of some real-world scenarios.
Example 1
In this scenario the legal department has requested a disclaimer to be placed at the bottom of each email. The disclaimer has to contain text that was provided. Other requirements for the disclaimer are that it must only be applied once to a message, it can be applied to only external emails, it needs to be in HTML format and contain images that provide link backs to the company’s Facebook sites. PowerShell can be used to create a Disclaimer rule:
New-TransportRule -SentToScope ‘NotInOrganization’ -ApplyHtmlDisclaimerLocation ‘Append’ -ApplyHtmlDisclaimerText ‘This email is for its intended recipient. If you are not the recipient, please delete this email immediately.’ -ApplyHtmlDisclaimerFallbackAction ‘Wrap’ -Name ‘Legal Required Disclaimer’ -StopRuleProcessing:$false -Mode ‘Enforce’ -RuleErrorAction ‘Ignore’ -SenderAddressLocation ‘Header’ -ExceptIfSubjectOrBodyContainsWords ‘This email is for its intended recipient’
$Logo = ‘<br><div style=”color:#675C53; letter-spacing: 2px; line-height: 125%;”><a href=”https://www.facebook.com”> <img src=”https://www.facebookbrand.com/img/assets/asset.f.logo.lg.png “></a><br></div>’
New-TransportRule -Name ‘FaceBook_logo’ -Comments ‘Contoso Signature - Logo’ -FromMemberOf ‘[email protected]’ -ApplyHtmlDisclaimerText $Logo -ApplyHtmlDisclaimerLocation Append -ApplyHtmlDisclaimerFallbackAction Wrap -ExceptIfSubjectOrBodyContainsWords ‘This email is for its intended recipient’ -Enabled $False -Priority 10
Example 2
Your company has decided to block all ZIP attachments in emails from external senders. The rule should also send the original email to an email address of “[email protected]” and delete it prior to delivery.
New-TransportRule -Name "ZIP Block" -AttachmentNameMatchesPatterns zip -GenerateIncidentReport "[email protected]" -IncidentReportContent AttachOriginalMail -DeleteMessage $True -SetAuditSeverity Medium
Options needed for this new Transport Rule:
AttachmentNameMatchesPatterns - the name of the attachment to be found with the rule - in this case it will be ‘zip’
GenerateIncidentReport - destination email address for incident reports when the rule matches its criteria
IncidentReportContent - specifies the message properties that are included in the incident report
SetAuditSeverity - defines a severity assigned to the message and logged into the message tracking logs
Incident report looks like the below image, notice the Rule Hit at the bottom of the screenshot for ‘ZIP Block’. Below is an example of real spam being blocked because of the ZIP attachment:
The original email is an attachment in this case ‘Blank 2’ is the original message with the ZIP file.
Accepted Domains are domains for which Exchange will answer SMTP deliveries for. If a domain is not defined and an email delivery is attempted for that domain, it will not be delivered. Defining these domains is important. In addition to defining the domain, it is also ideal to have Postmaster email addresses defined as well:
PowerShell
Get-Command *accepted*
Notice there is no option here for adding an Accepted Domain for routing email through Exchange. Why is this missing from Exchange Online? It's because the domain needs to be added to the MSOL connection point via New-MsolDomain first. Then the added domain can be manipulated within Exchange Online PowerShell.
** Note ** A new connection to MSOL can be initiated in PowerShell from any location that has the MSOnline PowerShell module available.
Once connected, a simple one-liner like the one below can be used to add an unverified domain to your tenant:
New-MsolDomain -Name OnlinePowerShellBooks.Com
One the domain is verified we can now work with it in Exchange Online. One thing you will notice is that the domain is not set to the default, which would be needed to change the default domain from the current default to the correct external domain:
Set-AcceptedDomain -Identity OnlinePowerShellBooks.Com -MakeDefault $True
Other Domain types are ‘ExternalRelay’ and ‘InternalRelay’. The ExternalRelay one allows emails to exit Exchange and be delivered to an Internet destination. While the InternalRelay type allows for only local relay, possibly to another internal mail server.
RFC 822 specifies that the Postmaster address be valid for an organization. The standard does not specify whether or not the email address is attached to one mailbox or simply as an alias for any number of mailboxes in Exchange. To find a mailbox that has the [email protected] address attached to it, simply use the Get-Mailbox cmdlet:
Get-Mailbox [email protected]
If a mailbox is found, then this requirement from RFC 822 has been satisfied. However, what if there is more than one domain in the environment? First, a list of accepted domains is needed:
Get-Command –Noun AcceptedDomain
From the above results we can choose Get-AcceptedDomain as our seed cmdlet. As always, make sure to store the output from the Get-AcceptedDomain cmdlet with a variable. However, in this scenario the script does not need all information about an accepted domain, only the name of the domain is needed. How do we get this property? Well, let’s examine the output of Get-AcceptedDomain cmdlet:
From that cmdlet, the property is appropriately name ‘Domain Name’. So, using a variable for store, the Get-AcceptedDomain cmdlet and the ‘DomainName’ property, the following one-liner is assembled:
$AcceptedDomains = (Get-AcceptedDomain).DomainName
For processing more than one domain, a Foreach loop will be used:
Foreach ($Domain in $AcceptedDomains) { }
Now, for each domain, the verification check is for ‘[email protected]’. In order to do this, first the script needs to assemble the postmaster address:
$Postmaster = ‘Postmaster@’+$Domain
Now with the correct address, the script can check for a mailbox with this address. The Get-Mailbox cmdlet is the best option for this. All that is needed is the email address, which was just assembled for the Postmaster mailbox:
$Check = Get-Mailbox $Postmaster
However, what if the mailbox does not exist? There will be a need for error handling. In order to do so, results from a Get-Mailbox cmdlet for the constructed Postmaster address are stored in a variable. If the variable is empty, then a negative response is written to the screen. If the Postmaster mailbox is found, a positive response is displayed.
$Check = Get-Mailbox $Postmaster -ErrorAction SilentlyContinue
If (!$Check) {
Write-Host $Postmaster" does not exist." -ForegroundColor Yellow
} Else {
Write-Host $Postmaster" does exist." -ForegroundColor Cyan
}
Assemble all the code together to get this:
$AcceptedDomains = (Get-AcceptedDomain).DomainName
Foreach ($Domain in $AcceptedDomains) {
$PostMaster = ‘Postmaster@’+$Domain
$Check = Get-Mailbox $Postmaster -ErrorAction SilentlyContinue
If (!$Check) {
Write-Host $Postmaster" does not exist." -ForegroundColor Yellow
} Else {
Write-Host $Postmaster" does exist." -ForegroundColor Cyan
}
}
In the below testing, the two domains listed in Exchange do not have a Postmaster address defined and thus generate yellow text, a warning to add these addresses.
To rectify this, either create a Postmaster mailbox that has both these aliases assigned to it, create one Postmaster mailbox per domain or add the aliases to an existing account, preferably in IT.
In order to remove an accepted domain, simply remove the domain from MSOL after connecting to your MSOL service.
Remove-MsolDomain -DomainName OnlinePowerShellBooks.Com -Force
The 'Force' switch is optional and will forcibly remove the domain even if there are dependencies on the domain.