How to Decommission a Shared SMTP Namespace in Exchange Server

In a previous article I demonstrated how to setup a shared SMTP namespace in Exchange Server.

A shared SMTP namespace may be a permanent situation for some organizations, but for others it is only temporary while a migration is occurring (eg, during a merger of two companies).

When that temporary need no longer exists the shared SMTP namespace can be decommissioned. While this may not be strictly necessary, it is a good idea for neatness and efficiency in the Exchange organization.

For this scenario I recommend an approach like this.

Analyze the Send Connector(s) to Verify They Are Not Being Used

Part of the shared SMTP namespace configuration is a send connector to route emails from organization A to organization B.

You can use protocol logs to confirm that the send connector no longer has email traffic passing through it. Theoretically no traffic would be passing through the send connector but there are situations where some non-essential traffic is still passing through.

For example, organization B may have some old mailboxes that you decided did not need to be migrated to organization A, so any stray emails sent to those mailboxes will still show up in the protocol logs.

Either way, the protocol log data will help you find and fix (or choose to ignore) any remaining email traffic.

Remove the Send Connector

After confirming the send connector is no longer in use you can remove it.

I like to make note of the details of the send connector for future reference, just in case I need to reverse the change and re-establish the connector again.

[PS] C:>Get-SendConnector oldcompany.com | fl


AddressSpaces                : {SMTP:*.oldcompany.com;1}
AuthenticationCredential     :
Comment                      :
ConnectedDomains             : {}
ConnectionInactivityTimeOut  : 00:10:00
DNSRoutingEnabled            : False
DomainSecureEnabled          : False
Enabled                      : True
ErrorPolicies                : Default
ForceHELO                    : False
Fqdn                         :
HomeMTA                      : Microsoft MTA
HomeMtaServerId              : HO-EX2010-MB1
Identity                     : oldcompany.com
IgnoreSTARTTLS               : False
IsScopedConnector            : False
IsSmtpConnector              : True
LinkedReceiveConnector       :
MaxMessageSize               : 10 MB (10,485,760 bytes)
Name                         : oldcompany.com
Port                         : 25
ProtocolLoggingLevel         : None
RequireOorg                  : False
RequireTLS                   : False
SmartHostAuthMechanism       : None
SmartHosts                   : {[10.10.10.10]}
SmartHostsString             : [10.10.10.10]
SmtpMaxMessagesPerConnection : 20
SourceIPAddress              : 0.0.0.0
SourceRoutingGroup           : Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers       : {HO-EX2010-MB1, HO-EX2010-MB2}
TlsAuthLevel                 :
TlsDomain                    :
UseExternalDNSServersEnabled : False

Then remove the send connector with the Remove-SendConnector cmdlet.

[PS] C:>Remove-SendConnector oldcompany.com

Confirm
Are you sure you want to perform this action?
Removing Send connector "oldcompany.com".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Change the Accepted Domain to Authoritative

With no send connectors to route the formerly shared domain to other organizations you can change the accepted domain from InternalRelay to Authoritative.

[PS] C:>Set-AcceptedDomain oldcompany.com -DomainType Authoritative

Also, you may want to enable address book lookups for the domain so that non-existent recipients can be rejected by recipient filtering (more info on that here).

[PS] C:>Set-AcceptedDomain oldcompany.com -AddressBookEnabled $true

Update Email Address Policies (Optional)

Depending on your organization’s needs you may also need to change the primary SMTP address for migrated users, eg to align with the new company name/brand after a merger.

You can read more about using email address policies here.

Summary

As you can see decommissioning a shared SMTP namespace is not a complex process, at least for scenarios that were not highly complex to begin with. I’ve seen a few organizations over the years that left shared SMTP namespace configurations in place long after they were no longer required. While this doesn’t necessarily cause serious problems it is certainly worth decommissioning them for neatness and efficiency.