Configuring SMTP Domains for Inbound and Relay


So for many weeks I've debated about what to post here.  My colleagues and I have worked pretty hard since the release of Exchange 2000 to document the SMTP Transport stack.  So I figured by now everyone knew everything there was to know about setting up SMTP domains for inbound and relay.  We covered the topic in the Greenbooks (http://www.microsoft.com/technet/prodtechnol/exchange/2003/Library/default.mspx), web casts, KB articles (http://support.microsoft.com/?id=260973, http://support.microsoft.com/?id=268838), and more.  But the truth is, it is complex, and is difficult to troubleshoot without understanding how it all works.  So here's everything you ever wanted to know on how to configure SMTP domains for inbound and relay.
 
First, you have to know what inbound and relay domains are.  Clearly, it would be bad for Exchange to accept email for every SMTP domain.  Either one of two things would happen, we'd either be generating a lot of non-delivery reports (NDRs) for emails we never should have accepted, or we'd be forwarding email to a lot of different domains around the world.  Thus, we limit what we accept for inbound and relay.  Inbound domains (authoritative) are domains that Exchange accepts mail for, and if there is no match in the directory (AD), we generate an NDR.  Relay domains are domains that we accept mail for, check to see if there is a match in our directory, and if not, forward it using either DNS or to a smart host.
 
So, out of the box, Exchange accepts email for just one authoritative inbound domain, your default domain.  The Exchange Metabase Update agent (also known as DS2MB) replicates this domain from the default recipient policy object into the IIS metabase, where SMTP reads it.  A good chunk of the SMTP related configuration is replicated in this manner.  So this means that you may have to wait on the local Config_DC to complete replication, but shortly thereafter, DS2MB will notice the change and replicate them to the metabase.  Even better (especially those who remember 5.5), few changes require any sort of restart of services.
 
New installations will have the default domain of their AD namespace, which is typically not what you want to leave it as.  You can of course change this default domain to be anything you wish, whether it resolves in DNS or not.  In fact, that is one way that you can for all practical purposes prevent inbound email.  Next you may want to configure it such that Exchange accepts email for other domains.  Simply make sure that SMTP domain appears in a recipient policy.  It need not be the default, although it can be, and you need not use the Recipient Update Service (RUS) to stamp all user accounts.  For example, if you only had two users that need to accept email for the secondary domain, then you would simply create a new recipient policy with a blank LDAP filter (assuming you put the addresses on the two accounts manually) or create a filter that selects just those two users. In either case, the RUS would not stamp the rest of your accounts. Yes, there is no "reroute" functionality like Exchange 5.5, but this provides nearly identical results.  You can add up to about 1000 domains total before you need to start thinking about performance and our "hosted Exchange" solution.  Speaking of Exchange 5.5, if you are in a mixed site/AG, although you can add SMTP domains to any recipient policy, if you DO want the RUS to stamp addresses on the users, you will need to use the special recipient policy for that site.  Yes, this policy supports multiple SMTP domains.  Just make sure you're running the latest service pack and you should be able to do this. 

Now let's say you want a relay or non-authoritative domain.  Since relay is considered mail not destined for the local organization, you do not configure this on the recipient policy.  What you do is create a new SMTP connector with a specific address space (e.g., "myrelaydomain.msft") and check the box for "Allow messages to be relayed to these domains" on the same tab.  You do not ever want to do this on a connector with address space of "*" because that would open you up to allow relay to all domains, which would clearly be bad.  Selection of the bridgehead of this connector should be done with care.  This checkbox is what allows you to receive mail for this domain, so this is one of the only places where a connector not only serves an outbound purpose, but an "inbound" (well, relay) as well. 
 
On the topic of RUS and relay/non-authoritative domains: you may wish to stamp SMTP addresses of the non-authoritative domain on users in your directory.  This is where the checkbox for "This Exchange Organization is responsible for all mail delivery to this address" on the recipient policy comes in.  This check box tells DS2MB not to replicate this domain to SMTP, not to accept the domain as inbound (thus limiting acceptance to the bridgehead with the connector mentioned in the previous paragraph), and also not to generate NDRs if no match is found for a particular address in the directory.  A few words of warning here:  First, never configure an authoritative domain for relay by adding a connector.  This makes no sense to DS2MB and it will probably warn you with an event in your event log.  You may also get unpredictable results.  Secondly, ALL recipient policies should match on this setting.
 
Complex?  Sure, though the most common scenarios are actually easier than in 5.5 where you had to go to both Site Addressing AND the IMC Routing tab.  In addition to getting into trouble by not following my words of warning above, there is at least one other major limitation.

Allow me to help this be less complex as well - nothing related to this should ever have you modifying your SMTP VS settings.  Just your recipient policies for inbound, and SMTP connectors for relay.
 
<sidebar>By the way, under very few circumstances would I recommend using the setting "Forward unresolved recipients to smart host", even though we've presented it as an option in KB321721 (
http://support.microsoft.com/?id=321721).  Certainly, you cannot mix the "Method 1" with "Method 2" as they are mutually exclusive. </sidebar>
 
Troubleshooting this comes down to looking at the NDR you're getting back:

5.7.1 means that you haven't either accepted the domain as inbound or relay
5.4.6 means loop -- that the server is configured non-authoritative for this domain, but then has no place to forward the message and is trying to deliver it back to itself (particularly if you are using contacts where the target SMTP address is a shared domain and/or DNS is resolving the domain back to the sending server)
5.1.1 means that the server couldn't find a match for the user in AD, and the server is authoritative for this particular domain
 
It is certainly possible, on a server that ran Exchange 2000 prior to SP3 (even if it has SP3 or later now) that DS2MB is confused and cannot replicate.  Usually you get events in your event log from MSExchangeMU and you're getting NDRs, even though you're positive that you configured this correctly.  Optionally, you can perform the following steps:

1. Backup the metabase
2. Stop the SMTP service
3. Use Metaedit or MBExplorer to delete all subkeys under LM/SMTPVS/X/Domain
4. Use the same tool to delete the LM/DS2MB key
5. Restart the Exchange System Attendant & SMTP services

If you aren't sure if this is your issue, or if you need help, please call Support Services and do not attempt this on your own.  Editing the metabase is just like editing the registry and you should only proceed if you know what you are doing.  It should take much less time to pick up the phone than it would to reinstall and re-patch Exchange and IIS.
 
In conclusion, if you would like to pick my brain on other Transport related topics, please post your suggested topics feedback here: 
http://blogs.msdn.com/exchange/archive/2004/08/11/213211.aspx.

- Scott Landry

Comments (6)
  1. Alexander Scoble says:

    Hi Scott,

    Thanks for the informative article.

    Couple of things: Why was the "reroute" functionality not included in the new Exchange?

    For those of us used to Exchange 5.5, that was a very nice feature as it allowed us to only have to set up and worry about one domain when we set up user accounts, as opposed to now having to make sure that every domain that we receive mail using is properly set up in the accounts.

    Why do you recommend not using forward all email to smart host?

    A lot of places use a mail gateway, firewall or forwarder to mask the internal domain structure and this cannot be done if the internal SMTP server cannot forward all email to one IP. A gateway could also be used to scan outgoing email for viruses/spam activity as an additional layer of protection.

    Also, is there a KB article or other web page that shows how to customize the error messages that the Exchange SMTP service generates?

    A lot of the error messages that I’ve seen just tell the user the error number without explaining what the error message means or what to do or not do.

    Thanks

  2. Scott Landry says:

    Alex,

    I shall attempt to address your questions:

    Q: Why was the "reroute" functionality not included in the new Exchange?

    A: The new functionality was deemed all that was required. There was no Recipient Update Service in Exchange 5.5, so it would have been difficult to manually add secondary addresses. In Exchange 2000/2003, all you have to do is configure a recipient policy. Optionally, it is relatively easy to write a managed SMTP event sink to do this.

    Q: Why do you recommend not using forward all email to smart host?

    A: I do recommend it if that’s what your configuration requires, but use an SMTP connector to do so. Do not configure this on the SMTP Virtual Server. You may be able to get away with this only if you have just a single Exchange server.

    Q: Is there a KB article or other web page that shows how to customize the error messages that the Exchange SMTP service generates?

    A: SMTP error messages can be customized, although they generally have accurate descriptions already. However, the Exchange store potentially will override the SMTP error message anyway (so you get an error message that is localized to your own language). Furthermore, there is also the potential that the error message was generated while talking to a remote system and the error message there is not as complete. In any case, check out KB284204. There are varying ways to accomplish NDR/DSN customization, depending on exactly which you would need to do, including an SMTP DSN sink, a store event, or a third party solution. You should also check out Jason’s blog topic for size limit error customization at http://blogs.msdn.com/exchange/archive/2004/04/20/117024.aspx.

    Hope this helps!

  3. Jesse Cadd says:

    Hi,

    It may be important to note the effect of checking the "This Exchange Organization is responsible for all mail delivery to this address" checkbox. Mail submitted to a domain with this checkbox selected *cannot* be relayed out of the organization, even if an SMTP connector has been configured to do so.

    At least, that’s been my understanding/experience…

    }-]

  4. Scott Landry says:

    Jesse,

    Of course you are correct. The scenario I described was with the box unchecked. By *checking* the box (default), you are telling DS2MB that it is okay to replicate it to the metabase, and Advanced Queuing will generate an NDR if the recipient does not resolve in the Active Directory. Thus, the message would not be relayed.

    Thanks for pointing this out and my apologies for not being a tad more clear on this very important point.

  5. Pingback/trackBack says:

    Everything you ever wanted to know on how to configure SMTP

  6. Newbie Admin says:

    Awsome article! This was exactly what I had been looking for…. You would think microsoft would have you set the domains you want to accept mail for under the properties tabs of the default SMTP virtual server? Not under recipeint policies? But of course this is the opinion of a complete noob ;-) Thank you soo much for cluing me in!!

Comments are closed.

Skip to main content