Thursday, February 16, 2012

Accepted Domain Concepts



Understanding Accepted Domains
An accepted domain is any SMTP namespace for which a Microsoft Exchange organization sends or receives e-mail. Accepted domains include those domains for which the Exchange organization is authoritative. An Exchange organization is authoritative when it handles mail delivery for recipients in the accepted domain. Accepted domains also include domains for which the Exchange organization receives mail and then relays it to an e-mail server that's outside the Active Directory forest for delivery to the recipient.
Looking for management tasks related to managing transport servers? See Managing Transport Servers.
Contents
http://i.msdn.microsoft.com/Global/Images/clear.gif  Configuring Accepted Domains
http://i.msdn.microsoft.com/Global/Images/clear.gif   
Accepted domains are configured as global settings for the Exchange organization and on computers that have the Edge Transport server role installed. You must configure every domain for which your Hub Transport servers relay or deliver messages as an accepted domain in your organization. The Edge Transport server requires that all domains for which it accepts and relays messages are configured as accepted domains.
We recommend that you create and manage all accepted domains inside the organization and synchronize that information to the Edge Transport server by creating an Edge Subscription. When you subscribe the Edge Transport server to the Microsoft Exchange Server 2010 organization, all accepted domains that are configured in the organizational settings for the Hub Transport server role are replicated to the Edge Transport server during EdgeSync synchronization. To modify the accepted domain configuration on an Edge Transport server that's subscribed to the Exchange 2010 organization, you must make the change on the Hub Transport server.
There are three types of accepted domains: authoritative, internal relay, and external relay. These accepted domain types are described in the following sections.
http://i.msdn.microsoft.com/Global/Images/clear.gif  Authoritative Domains
An organization may have more than one SMTP domain. The set of e-mail domains for an organization are the authoritative domains. In Exchange 2010, an accepted domain is considered authoritative when the Exchange organization hosts mailboxes for recipients in this SMTP domain. The Edge Transport servers should always accept e-mail that's addressed to any of the organization's authoritative domains.
By default, when the first Hub Transport server role is installed, one accepted domain is configured as authoritative for the Exchange organization. The default accepted domain is the fully qualified domain name (FQDN) for your forest root domain. Frequently, the internal domain name differs from the external domain name. For example, your internal domain name may be contoso.local, although your external domain name is contoso.com. The Domain Name System (DNS) mail exchange (MX) resource record for your organization references india.com. contoso.com is the SMTP namespace that you assign to users when you create an e-mail address policy. You must create an accepted domain to match your external domain name.
By default, no accepted domains are configured on the Edge Transport server role.
http://i.msdn.microsoft.com/Global/Images/clear.gif  Relay Domains
When e-mail is received from the Internet by an Edge Transport server and the recipient of the message isn't part of an authoritative domain, the sending server tries to relay through the Exchange server. When a server acts as a relay server that has no restrictions, it can put a large burden on Internet-connected servers. Administrators can prevent this open relay scenario by rejecting all e-mail that isn't addressed to a recipient in the organization's authoritative domains. However, there are scenarios where an organization wants to let partners or subsidiaries relay e-mail through the Exchange servers. In Exchange 2010, you can configure accepted domains as relay domains. Your organization receives the e-mail messages and then relays the messages to another e-mail server.
You can configure a relay domain as an internal relay domain or as an external relay domain. These two relay domain types are described in the following sections.
http://i.msdn.microsoft.com/Global/Images/clear.gif  Internal Relay Domain
When you configure an internal relay domain, some or all of the recipients in this domain don't have mailboxes in this Exchange organization. Mail from the Internet is relayed for this domain through Hub Transport servers in this Exchange organization. This configuration is used in the scenarios that are described in this section.
An organization may have to share the same SMTP address space between two or more different e-mail systems. For example, you may have to share the SMTP address space between Microsoft Exchange and a third-party e-mail system, or between Exchange environments that are configured in different Active Directory forests. In these scenarios, users in each e-mail system have the same domain suffix as part of their e-mail addresses.
To support these scenarios, you must create an accepted domain that's configured as an internal relay domain. You must also add a Send connector that's sourced on a Hub Transport server and configured to send e-mail to the shared address space. If an accepted domain is configured as authoritative and a recipient isn't found in Active Directory, a non-delivery report (NDR) is returned to the sender. The accepted domain that's configured as an internal relay domain first tries to deliver to a recipient in the Exchange organization. If the recipient isn't found, the message is routed to the Send connector that has the closest address space match.
If an organization contains more than one forest and has configured global address list (GAL) synchronization, the SMTP domain for one forest may be configured as an internal relay domain in a second forest. Messages from the Internet that are addressed to recipients in internal relay domains are received and processed by the Edge Transport server and then relayed to the Hub Transport servers in the same organization. The receiving Hub Transport servers then route the messages to the Hub Transport servers in the recipient forest. You configure the SMTP domain as an internal relay domain to make sure that e-mail that's addressed to that domain is accepted by the Exchange organization. The connector configuration of your organization determines how messages are routed.
In the following figure, Fourthcoffee.com is configured as an internal relay domain for the Exchange 2010 organization in the Contoso.com forest. The MX resource records for Fourthcoffee.com reference a public IP address for the Contoso.com organization. A forest trust exists between Fourthcoffee.com and Contoso.com, and GAL synchronization is configured. The Contoso.com Edge Transport server accepts messages for the Fourthcoffee.com SMTP domain from the Internet and then relays those messages to the Hub Transport servers in the Contoso.com Exchange organization. The messages are then routed to the Hub Transport servers in the Fourthcoffee.com Exchange organization. A cross-forest Send connector is configured for routing messages from Contoso.com to Fourthcoffee.com. Messages that are sent from Fourthcoffee.com to external recipients are routed to the Hub Transport servers in the Contoso.com forest. A second cross-forest Send connector is configured for routing messages from Fourthcoffee.com to Contoso.com. When the Hub Transport servers in Contoso.com receive messages from the internal relay domain Fourthcoffee.com, they deliver messages for recipients in authoritative domains and relay messages for Internet recipients to the Edge Transport server for delivery.
Configuration of an internal relay domain
External Relay Domain
When you configure an external relay domain, messages are relayed to an e-mail server that's outside the Exchange organization and outside the organization's network perimeter. The messages are relayed by the Edge Transport server.
In this scenario, the MX resource record for the external relay domain references a public IP address for the Exchange 2010 organization that's relaying messages. The Edge Transport server receives the messages for recipients in the external relay domain and then routes the messages to the e-mail system for the external relay domain. A Send connector from the Edge Transport server to the external relay domain is required in this scenario. The external relay domain may also use your organization's Edge Transport server as a smart host for outgoing mail.
In the following figure, Adatum.com is configured as an external relay domain for the Exchange 2010 organization in the Contoso.com forest. The MX resource record for Adatum.com references a public IP address for the Contoso.com organization. The Contoso.com Edge Transport server accepts messages for the Adatum.com SMTP domain from the Internet and then relays those messages to the e-mail servers in the Adatum.com organization. Adatum.com also uses the Contoso.com Edge Transport server as a smart host for routing outgoing messages. Messages that are sent from Adatum.com to external recipients are routed to the Edge Transport servers in the Contoso.com organization. When the Edge Transport servers in Contoso.com receive messages from Adatum.com, they deliver messages for recipients in authoritative domains and internal relay domains to the Hub Transport servers and route messages to the Internet.
Configuration of an external relay domain




Accepted Domains and E-Mail Address Policies
You must configure an accepted domain before that SMTP address space can be used in an e-mail address policy. When you create an accepted domain, you can use a wildcard character (*) in the address space to indicate that all subdomains of the SMTP address space are also accepted by the Exchange organization. For example, to configure Contoso.com and all its subdomains as accepted domains, enter *.Contoso.com as the SMTP address space. The accepted domain entries are automatically available for use in an e-mail address policy.
If you delete an accepted domain that's used in an e-mail address policy, the policy is no longer valid, and recipients with e-mail addresses in that SMTP domain will be unable to send or receive e-mail.

Understanding Remote Domains
Applies to: Exchange Server 2010 SP2
You can create remote domain entries to define the settings for message transfer between the Microsoft Exchange Server 2010 organization and domains outside your Active Directory forest. When you create a remote domain entry, you control the types of messages that are sent to that domain. You can also apply message format policies and acceptable character sets for messages that are sent from users in your organization to the remote domain. The settings for remote domains are global configuration settings for the Exchange organization.
The remote domain settings are applied to messages during categorization. When recipient resolution occurs, the recipient domain is matched against the configured remote domains. If a remote domain configuration blocks a specific message type from being sent to recipients in that domain, the message is deleted. If you specify a particular message format for the remote domain, the message headers and content are modified. Information about the remote domain configuration is stored in Active Directory. The settings apply to all messages that are processed by the Exchange organization.
   For more details follow the link:
http://technet.microsoft.com/en-us/library/bb124423.aspx




7 comments:

Brillica Services-Technology Solution Provider said...

wow arun this really helped me a lot..u r such a great technical person.

Arun Chaudhary said...

Thanks Yogender, I will try to give you more valuable information

Arun Chaudhary said...

Exchange querry by my one of client, Mr. Gary Richefond from UK.

Hello Arun,

I am excited by your news, sorry I have not got back to you sooner but I have been away for some time and have only just returned to the UK within the last few weeks. I am getting involved in a small migration project from Exchange 2003 to Office 365 and wondered if you had any valuable insight into this; I am considering running a test pilot in order to ascertain the merits of this service. Anyway, I hope this email finds you well and will endeavour to keep incontact with you as I hope to be back in India in May/June sometime.

Arun Chaudhary said...

Hey,

Thank you very much for that, I await your reply but in particular I am wanting to know the best way to utilise the exitisting public folders we have in Exchange 2003 in Office 365. As I am sure you are no doubt aware public folders are not supported in the Office 365 platform.

From what I gather the options availble are "Shared MailBoxes" and or "Sharepoint". I do not have much experience with Sharepoint and am just looking into the shared mailbox option. Any advice\ pointers \guides you could give me on this subject matter would be much appreciated.

Thank you again for your interest and I look forward to hearing from you

Anonymous said...

Great information. Lucky me I came across your site by accident (stumbleupon).
I've book-marked it for later!
My web site: no exchange server

Saurabh Srivastava said...

Really a good work is done..... helpful information and lots of matter is available here.

Arun Chaudhary said...

Thanks sir, Please check the your querry answer, that how to add multiple exchange accounts in outlook 2010,
I post a new topic for this