умолчанию. Изменить домен, используемый в качестве домена по умолчанию, 
можно через контекстное меню.

По сути никакого особого положения у домена, имя которого совпадает с 

FQDN сервера нет – данный домен после проведенной рассмотренной операции 
превращается   в   домен   псевдоним.   Можно   создать   много   различных   доменов 
псевдонимов, заставив тем самым почтовый сервер собирать в папку Drop почту 
для пользователей многих доменов. Так же можно не только создавать домены 
псевдонимы, но и удалять их, при этом НЕЛЬЗЯ удалить домен, используемый в 
качестве домена по умолчанию.

Но можно удалить домен, являющийся псевдонимом. 
Таким   образом,   существуют   два   способа   «переименовать»   домен,   в 

который по умолчанию собирает входящую почту данный SMTP сервер:

• Изменить системное  FQDN  узла, это автоматически приведет к тому, что 

SMTP сервер станет считать доменом по умолчанию (и собирать почту для 
этого домена) тот домен, который совпадает с FQDN данного сервера.

• Создать домен псевдоним с произвольным именем, сделать его доменом по 

умолчанию, удалить домен, имя которого совпадает с FQDN сервера. 

Вывод:   чтобы сконфигурировать почтовый сервер таким образом, чтобы 

он собирал в каталог  Drop  почту для некоторого домена, необходимо создать 
домен-псевдоним   с   необходимым   именем,   при   необходимости   доменов 
псевдонимов может быть сколь угодно много. Такая настройка имеет смысл в 
том случае, если это сервер будет объявлен в DNS как MX данного домена. При 
этом   вопросы   того,   КАКИМ   образом   почта,   накопленная   в   папке  Drop  будет 
предоставлена пользователям домена нас не интересует и эта задача в общем 
случае не решается средствами службы IIS SMTP. 

Теперь   рассмотрим   второй   случай:   пусть   мы   хотим   сконфигурировать 

данный почтовый сервер таким образом, чтобы он мог выполнять функции  MX 
некоторого   домена,   но,   так   как   служба  SMTP  IIS  не   может   обеспечить 
организацию доступа пользователей к почтовым ящикам, до наш сервер будет 
передавать   всю   поступившую   в   данный   домен   почту   ДРУГОМУ   почтовому 
серверу, который, вероятно, и будет хранить почтовые ящики пользователей и 
обеспечивать   к   этим   почтовым   ящикам   эффективный   доступ   самих 
пользователей.   Т.е.   нам   необходимо,   чтобы   сервер   считал   некоторый   домен 
«своим»,   т.е.   НЕ   рассматривал   передачу   почты   в   данный   домен   как   попытку 
отправить почту релейно, но НЕ собирал письма в этот домен в папке  Drop, а 
передавал   эти   письма   другому   серверу.   Для   этого   с   помощью   мастера 
добавления доменов снова создадим УДАЛЕННЫЙ домен. Мы уже рассматривали 
выше настройки, которые можно указать для удаленного домена. Для решения 
двух   различных   практических   задач   используется   один   и   тот   же   подход   – 
создание   удаленного   домена,   но   для   решения   данной   задачи   подход   к 
конфигурированию   удаленного   домена   будет   несколько   отличаться   от 
предыдущего случая использования удаленного домена. 

Свойства удаленного домена: