How To Setup Exchange To Receive Emails For A Shared SMTP Domain

Assume that we have 2 Exchange organizations, one is responsible for *@MainCompany.com emails (MainOrg), the other is responsible for *@subCompany.com emails (SubOrg). Now we want MainOrg to receive emails on behalf of SubOrg, meaning all emails that are sent to *@subCompany.com address should go to Exchange server in MainOrg.

Note: SubOrg doesn't have to be Exchange, it could be any mail system

1. For all users in SubOrg, create contacts in MainOrg
2. Create a Recipient Policy that will generate exactly same @subCompany.com email addresses for contacts you created in step 1. This Recipient Policy should NOT be authoritative for subComapany.com
3. Change public MX record of subCompany.com so it now points to MainCompany Exchange server instead of subCompany Exchange server
4. Create a SMTP connector on MainOrg Exchange server, specify subCompany.com as its space
5. Enable "relay for this domain" on the connector created in step 3, forward all mail to subCompany exchange server (subOrg Exchange as smart host)
6. Restart Routing Engine and SMTP services

Caution: subOrg must be configured as "authoritative" for @subCompany.com

Exchange routing considerations

- Internal messages always go for shortest route available
- A connector will be considered off ONLY when all bridgehead server(s) on that connector are down
- For external messages, a route is chosen with closest SMTP name space matching first regardless the cost. For example, an email destined to *.net will go to connector that is responsible for *.net even it has higher cost than the one that is responsible for * space.
- Routing does not fail over from a connector with a specific address space to a connector with a less specific space. So when there is problem with all *.net connector(s), emails will be queued up in *.net connector(s)
- The above 2 rules don’t apply to user who doesn’t have permission to the specific connector. Consider connector that a user doesn’t have permission as non-exist when routing his emails.

SMTP Virtual Server vs. SMTP Connector

SMTP Virtual Server vs. SMTP Connector
1. SMTP virtual server is the protocol stack that actually does the work - sending/receiving SMTP emails. SMTP virtual server alone gives you ability to send/receive Internet emails.
2. SMTP Connector is built on the top of virtual server and provides you more control - such as dispatching emails to different domains to different routes, applying different restrictions, etc.
3. SMTP virtual server only sends/receives emails to/from the IP address it is bound.
4. As for DNS, either specify external DNS servers on SMTP virtual servers or specify forwarder on DNS server that Exchange server uses.
5. The benefits of SMTP Connector are 1) ease of administration; 2) to simplify troubleshooting when issue surfaces.
6. You can either have your SMTP connector delivery the emails directly (given that the connector is able to resolve external domain names - using one of 2 settings in item 4 )
- or -
You can have your SMTP connector forward all emails to a smart host. Although you can specify a smart host on an virtual server, it’s better to set it on the connector. The smart host setting on the connector overrides any smart hosts on the virtual server.