Authoritative vs Internal Relay Domains in Exchange

tl;dr: Ensure the accepted domain(s) in Exchange Online are configured as Authoritative, not Internal Relay, even if you're in hybrid, to take advantage of Directory Based Edge Blocking.

Those of you who have worked with Exchange Server for a long time and those familiar with cross forest migrations will probably know about Authoritative vs. Internal Relay domains. When a domain is set to Authoritative, email is delivered only to valid recipients in the Exchange organization. With Internal Relay domains, email is delivered to recipients that exist in the Exchange organization and other emails are relayed to another email server in a different location.

I've seen a number of customers (especially Exchange hybrid customers) configure their domains on-premises or in Exchange Online Protection as Internal Relay, thinking that this is required in order to relay emails on-premises or to their tenant. This isn't necessary because emails will still relay between on-prem and EXO using the targetAddress (aka external routing address) value, which always happens even if the domain is set to Authoritative.

Why is this a big deal? Well, Exchange Online online has a feature called Directory Based Edge Blocking (DBEB), which rejects messages for invalid recipients at the service network perimeter. Exchange Edge Transport servers will do the same thing for on-prem. DBEB prevents Exchange from accepting invalid emails, scanning them for malware and spam, perform rules processing, etc. when they have no hope of being delivered to a bad email address.

If a domain is set to Internal Relay, DBEB can't work since it would block unknown emails from being relayed to another server. With DBEB, Exchange performs a directory lookup before it even accepts the email. If the recipient address doesn't exist, Exchange rejects the email with a 550 5.4.1 Recipient address rejected: Access denied error. RFC states it's up to the sending server to generate the NDR back to the sender.

Read more ...

Keep your Exchange Federation Trust up-to-date

From time to time, Microsoft refreshes the certificate used by the Microsoft Federation Gateway service in Office 365. They just did this again on July 5, 2019. The MFG is the trust broker used by hybrid organizations and by other on-premises orgs that share free/busy information between them. Most Exchange configurations will update the federation trust metadata automatically, but if your on-premises org is running Exchange 2010 or Exchange 2013 on Windows Server 2008 you will need to update this manually.

Begin by testing to see if the metadata is up-to-date in your org by running the Test-FederationTrust cmdlet in EMS from one of your Exchange servers. The cmdlet normally does not require any switches to run.

Exchange will check AD to confirm that the Federation Trust configuration object exists and is valid, the Token Issuer certificate is valid, and then request a delegation token from the MFG. Here's what a good test looks like in Exchange 2010:

Test-FederationTrust from Exchange 2010

Exchange 2013+ performs a few more detailed tests using a built-in test account:

Test-FederationTrust from Exchange 2013

If you see any validation errors, such as the following error, you will need to update your MFG refresh token manually:

Id : TokenValidationType : ErrorMessage : Failed to validate delegation token.

You can update AD with the latest Microsoft Federation Gateway certificate one time by running the following cmdlet from EMS on any Exchange server in your org:

Get-FederationTrust | Set-FederationTrust –RefreshMetadata 

Once updated, run the Test-FederationTrust cmdlet again to confirm the validation and delegation token is valid.

If you want to automate this process, you can create a scheduled task on one of your Exchange servers to update the federation trust once per day. Nothing will actually update in your environment unless Microsoft updates their MFG certificate. Run the following from an elevated CMD prompt or EMS window to create the scheduled task:

Schtasks /create /sc Daily /tn FedRefresh /tr "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -command Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010;$fedTrust = Get-FederationTrust;Set-FederationTrust -Identity $fedTrust.Name -RefreshMetadata" /ru System

Remember, you will only need to do this if your organization runs Exchange 2010 or Exchange 2013 on Windows Server 2008. Later versions of Windows allows Exchange to update the federation trust certificate automatically.

Read more ...

Congratulations 2019-2020 Microsoft MVP!

Once again I am deeply honored to receive the Microsoft MVP Award in the Office Servers and Apps category for 2019-2020. This is my eleventh consecutive year for this award.

The MVP Award is an important recognition to me and I'm very pleased to receive it. It includes several benefits, but the most important one to me are all the interactions with the great product groups at Microsoft. These relationships allow me to reach out to specific product team members to provide feedback and get clarification on product features and behaviors.

It's a mutually beneficial partnership -- under NDA, Microsoft is able to talk with MVPs about product futures, provide access to technology adoption programs (TAPs) to try out new software, and solicit our feedback. As MVPs, we are able to provide important and honest feedback to the product teams about how new features and behaviors will affect our customers, beta test new software and file bug reports, and be advocates for you, the customer.

This also adds value to my IT consulting business, EXPTA Consulting. It's evidence that Microsoft values my technical leadership and real-world experience, which I bring to each and every engagement, and customers know that I provide the best results as their trusted advisor.

Read more ...