When you send email message to external parties, you will notice that any one who opened the message header can easily see all your Exchange servers internal names. This is because each server during the routing path, will stamp the message header with its own name.

This can be considered a bonus to email administrators, as they can easily track all hops that a message went through on its journey from one mailbox to another. This can be handy in troubleshooting also.

On the other hand, some enterprises might not want their internal server names to be exposed like this in the message header for messages sent outside their network.

Hide Exchange Server Names Externally

The good news is that you can configure the send connector to hide the server names so that they will not appear in the message header.

The first thing is to determine the name of the connector that is sending emails to the internet. One you identified the send connector name, you can run this command to see what rights are given in that connector:

Get-SendConnector "my Send Connector Name"| Get-ADPermission | Where-Object {$_.extendedrights -like "*routing*"} | fl user, *rights


The output of this command will show Anonymous Logon entry with extended right named ms-Exch-Send-Headers-Routing


Hide Exchange Server Names Externally

To remove that specific permission from the send connector, you can simply run:

Remove-ADPermission -id "my Send Connector Name" -AccessRight ExtendedRight -ExtendedRights  "ms-Exch-Send-Headers-Routing" -user "NT AUTHORITY\Anonymous Logon"

Doing so, your Exchange server names will no longer appear on the message header for messages going outside your organization.

So we have learned how to hide Exchange server names externally. If you want to revert back your changes, and return the permission back, just run:

Get-SendConnector "my Send Connector Name"| Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-Send-Headers-Routing

Final Thoughts

We talked about how to hide exchange server names externally, and how you can easily run one PowerShell command to configure what permissions are assigned to anonymous logon. It is not required to do so in your environment, as this is a matter of privacy and security measure that can be or cannot be applied to every organization.