Guest Post: Migrating between email servers- SMTP Namespace Sharing

Third in our series of Guest posts by Exchange MVP’s is Clint Boessen, exploring the complexities of sharing an email domain- known as a SMTP namespace- essential when migrating between servers or running multiple mail servers.

Clint Boessen is an Exchange MVP from Western Australia focusing on Microsoft Business Productivity solutions.  Clint works for 4Logic Pty Ltd, an Information Technology and Consulting Company who is a Microsoft Partner predominately focusing on Microsoft.  Clint has a diploma in Network Engineering, an MCSE, MCITP and is currently working towards his MCM in Exchange Server. Clint maintains his own blog containing lots of hints, tips and tricks for IT Professionals which can be viewed at Part 1: An overview on SMTP Namespace Sharing SMTP Namespace Sharing is the concept of sharing an SMTP Namespace amongst multiple email systems. SMTP Namespace sharing is not limited to vendors or platforms; it can be configured across a wide variety of mail systems including Exchange 5.5 – 2010, Lotus Notes, Novell GroupWise, MDaemon and even many of your open source products such as QMail, Postfix, Sendmail and Zimbra. So what is an SMTP Namespace? An SMTP Namespace is simply the domain name at the end of an email address. Take my work email address The SMTP Namespace here is So how does SMTP Namespace sharing work? Regardless which SMTP mail server you're using, all SMTP mail servers follow the same principles when it comes to SMTP Namespace sharing. To understand how SMTP Namespace sharing works first we must understand the most common options for configuring an SMTP mail server:

  • SMTP servers authoritative for specific SMTP Namespaces.
  • SMTP servers authoritative for all SMTP Namespaces.

SMTP servers authoritative for specific SMTP Namespaces are generally SMTP servers connected directly to mail storage- typically mailboxes, although mail storage can be anything from a simple file base folder structure to a database system. By authoritative I mean "accept email for". For example my work email server is authoritative for however I may also choose to configure my work email server to be authoritative for other SMTP Namespaces such as and should I wish to receive email for these suffixes. SMTP servers authoritative for all SMTP Namespaces generally accept the email then relay it on to another SMTP server. These servers are generally referred to as "smart hosts". There are multiple reasons why people do this. For example an SMTP server may be setup to accept email from all SMTP Namespaces for spam/virus filtering purposes in which the mail server cleans the email then forwards the filtered email onto its destination like Mimecast. Other people such as ISP's may setup SMTP servers open to all SMTP Namespaces relay for their customers who would like to send e-mail but don't have their own SMTP server. SMTP servers authoritative for all SMTP Namespaces are generally locked down by using SMTP authentication or locked down to a specific IP range otherwise they would be an "open relays" and open to abuse. Open relays are a plague to internet email; this is where majority of the internet's spam comes from. Spammers have created scripts which troll through internet IP ranges scanning for open relay servers. If you setup an open relay server exposed to the internet there is a good chance within a couple of days you will already be relaying thousands of spam email. Note: Depending on the how the Administrator configures the SMTP server "smart hosts" may also be locked down to only accept email for a predefined range of SMTP Namespaces. Now we understand the how SMTP servers can be setup let's run through an example to explain SMTP Namespace sharing. Say you're migrating from one system to another so we have two different email systems running; you're migrating to Exchange 2010 from Zimbra. Both systems are authoritative for the SMTP Namespace and both have user mailboxes assigned to the email addresses. When configuring the MX records on the DNS zone file without an external smart host with routing, we only have two options. One email system can be the primary destination for or we can configure email's to be load balanced between the Exchange 2010 and Zimbra. Regardless which method we choose we run into a problem – there is no way for the sending email server to know which email system contains the recipient's mailbox. If you have followed up until this point it should be easy to understand how it works now. The SMTP Namespace sharing works like this:

  1. Configure the SMTP servers to receive all email addressed to even if they do not have a valid mailbox for the recipient address.
  2. Let's say the Exchange 2010 server receives an email addressed to, for email addresses it does not have a mailbox for it will forward it to the IP address of the Zimbra SMTP server.
  3. If the Zimbra SMTP server contains a mailbox for the user it will accept the email.

If you're thinking there is a problem with what I have just told you, please give yourself a pat on the back. What happens if the Zimbra email system does not contain a recipient for Zimbra would forward the email back to Exchange 2010. This would result in an infinite email loop between mail servers for any invalid SMTP recipient addresses. So how do email servers address this issue? SMTP Servers can add a flag to the MIME Header inside the email. The flag added to the message header is usually called X-Loop but can vary based on the type of SMTP server. If an SMTP server receives an email back that it has already stamped, it can generate an NDR and return it to the sender or simply delete the email. Not all SMTP Servers add a flag to the MIME Header automatically, configuration may differ. Please revert to vendor specific documentation. This concludes part one of this three part series. In part two we will be setting up SMTP Namespace Sharing between two forests, one running Exchange 2003 and one running Exchange 2010.