Previous Topic

Next Topic

Book Contents

Book Index






The type of domain – there are five domain Types:


This specifies a standard domain with users who have separate mailboxes. This is the default domain type and probably the most commonly used.

Domain alias

The Domain alias type is used to immediately forward any received messages to another domain.

The domain to be forwarded to must be specified in the Value box.

Forwarding can only be done to local domains (i.e. on the same IceWarp Server).

This domain is useful where you have registered multiple combinations of a domain name but want all messages to be collected from one point.

For example, if you own

and you want all messages to go to

You should set up a standard domain for .com, and alias domains for .net and .org.

Both the .net and .org domains should specify in the Value field.

Standard MX and A records should be set up for all three domains.

All messages received to the .net and .org domains will be immediately forwarded to the .com domain.

NOTE: This type of domain does NOT need to have an account defined within it. However, if an account is defined then any mail sent to that account will NOT be forwarded!

NOTE: For backwards compatibility reasons and for having possibility to define different rules for a domain alias, this option is still retained. To find additional information, go to the Domain – Aliases section.

Backup domain

The basic function of a backup domain is to accept messages and forward them immediately to another server. If the other server cannot be contacted then the messages are queued for delivery when the server is back online.

This can be useful in three suggested scenarios:

Backup Server

This is a backup to ensure no messages are lost if your primary server is offline.

  • You have your main server and a backup domain on different servers. Note that both servers should have the same domain name (e.g.
  • MX records are defined for both servers but the backup domain server's MX has a lower priority. For example, 2 MX records are created for, one points to and has priority 5 and the second points to and has priority 10.
  • The backup domain is set to forward all messages to your main server.

Now, if your main server is down for any reason, any remote connections should contact your backup server to deliver messages. When your main server is running correctly again the backup one will deliver all messages collected during the down-time.

Domain Gateway

This allows you to have a server between your "real" server and the internet.

  • You have a backup domain server connected to the internet and your main server is internal to your company.
  • An MX record exists for the backup domain server only.
  • The Value field should contain the internal IP address of your main server.
  • The backup domain is set to forward messages to your main server.

Now, all messages sent to your company will be initially processed by your backup domain server.

The backup domain server can do all the IceWarp Anti-Virus and AntiSpam processing and only deliver messages that you really want to your internal server.

Migration Scenario

The third scenario where the backup server can be implemented is to help implement a phased migration of users from one email server to IceWarp Server.

  • Set the system up the same as a domain gateway (see above) with the backup domain set up on the IceWarp Server you are migrating to.
  • Create user accounts in the backup domain for the users you want to migrate to the new server. Any messages for defined accounts will NOT be forwarded to the old server. When a user account is not defined (i.e. not migrated) the message will be forwarded as normally.

So now, as you define user accounts, they will effectively migrate to the new server.

NOTE: An important difference between the distributed domain and the backup domain is how they respond when they cannot connect to the receiving server:

A backup domain will save the message and deliver it when the server is back online.

A distributed domain will issue a 4xx warning to the originating server, effectively telling it to try again later.

NOTE: If you define a user on a backup domain then any messages for that user will not be forwarded, but will be stored in that domain.

NOTE: Domain aliases can be used. This can cause inconsistence between the address used for verification and address used for delivery.

Use the c_system_services_smtp_rewrite_backup_recipients API variable. When set to false, domain aliases (used within email addresses) are not rewritten; when set to true, domain aliases are changed to a domain name.

Distributed domain

The distributed domain is designed to be used where a business is spread across multiple locations and you wish to distribute your IceWarp email servers around your locations, each with a subset of your users.

  • At each location you should set up IceWarp Server.
  • On each server, you should set up a distributed domain, each with the same name (i.e. all called
  • An MX record should be set up for each server in the distributed domain.
  • The Value field should contain the internal IP addresses of all related distributed domains separated by semicolon.

Now, when a message is delivered to the receiving server, it will:

  • Use the SMTP VRFY or RCPT command (see Verification option further down) on all the other servers in the distributed domain to locate the recipient of the message (unless the user is a local one to this instance).
  • If the user is not found the message is rejected and a 5xx permanent error is reported to the sending server.
  • If any of servers in the distributed system cannot be contacted and none of the other servers (that can be contacted) has the appropriate recipient, then a 4xx temporary error is reported to the sending server, which should retry after a period of time.
  • If the user is found then any IceWarp Anti-Virus and AntiSpam processing is performed and the message is delivered to the distributed server that the user is defined on.

NOTE: Important difference between a distributed domain and a backup domain is how they respond when they cannot connect to the receiving server:

A backup domain will save the message and deliver it when the server is back online.

A distributed domain will issue a 4xx warning to the originating server, effectively telling it to try again later.

NOTE: Distributed domains REQUIRE recipient real time verification. If one of the destination servers defined in the Value field is inaccessible, the email will NOT be sent out and the user will get the "4xx – try again later" error, until the destination server (where the appropriate account is) is available. For WebClient, there is a work-around – use Bounce back messages for failed recipients (Administrator Options – Mail – General). Other option is to use backup domains, however you lose the IM/VoIP functionality of the distributed scenario.

NOTE: Anti-Spam is not performed for external recipients of distributed domains, this can be disabled by API variable C_AS_BypassDistributedDomain (set to 0). If disabled, Anti/Spam is performed provided that it is set for outgoing messages.

SEE the NOTE to domain aliases and verification within the Backup domain field.


This type of domain is used to hold all messages to be collected by another mail server using the ETRN or ATRN SMTP Client commands. This type would usually be used by ISPs.

One user account must be created to allow the collecting server to log in and collect mail.

This user account MUST have the ETRN/ATRN account option selected in the User – Options tab.

If a password is set for this account, the collecting server must specify the password in the ATRN command.


This option is valid for all domains except the standard one.

Multiple values can be specified in this field, separated by semicolons.

Port values can also be specified by adding a colon and the port at the end of the host name. This can be useful if your ISP blocks standard ports.

Syntax - <domain><:port>;<domain><:port>

Example -;

NOTE: It is recommended to use host names here. Using of IP addresses could cause problems in the case, it is changed.


If the collecting server has a static IP address then this field should contain the IP address. If the IP address is dynamic, the Value field should be left blank.

Domain alias

Field must contain the domain name of the server that you are aliasing.

Backup domain

Field can contain the host name or IP address of the server that email is to be forwarded to. If the field is left blank then an MX lookup is performed.

NOTE: You can use the authentication as described in the Use relay server field – Mail Service – General – Delivery section.

Distributed domain

Field should contain the IP addresses of the other servers in the distributed domain or can be left blank if MX DNS records are defined for all domains in the distributed system.

NOTE: You may want to use defined patterns (System – Advanced – Patterns) in this field. Use a pattern name in brackets – [pattern_name].

NOTE: This field is disabled for standard type domains. Although it is possible to access and edit it in WebAdmin, it is meaningless for this type.


Applies only to the Distributed domain and Backup domain types.

  • Distributed domain – initially the Default verification is assigned to it. This means that the VRFY command is used.

    This domain uses the VRFY command or RCPT one to locate the server where the user is defined. It is recommended to use the VRFY command. The RCPT command should be used on servers that do not support the VRFY command (very rare nowadays). Selecting of Use Minger with password for Distributed domain enables the password field and lets you to set it. For more information about Minger server, refer to the System – Services – SOCKS and Minger Server – Minger Server section.

  • Backup domain – initially the Default verification is assigned to it. For this type of domain it means that NO verification is used.

    Selecting of Use Minger with password for this domain type is senseless.

NOTE: For both domain types you can use the response cache. Result of a performed query is cached and the next query can be answered without necessity of another connection to a remote server.

Use the following API variables:

c_accounts_global_distributed_accounts_cache_enabled – bool – true/false

c_accounts_global_distributed_accounts_cache_max – integer – maximal number of cached items (zero means no limit)

c_accounts_global_distributed_accounts_cacheexpire – integer – cache expiration in seconds

Set values are used for both Distributed and Backup domains.

NOTE: Older MS Exchange versions (2000, 2003) do not support the VRFY command by default. This command can be disabled on newer versions, as VRFY* could be used for email harvesting. In this case, use the RCPT command instead.




IP Address

Enter an IP address here to bind this domain to that IP.

The IP address is also used for authentication, if this is not set correctly then none of your users will be able to authenticate.

NOTE: For binding of the IP address for outgoing connections, you have to enable the Use domain IP address for outgoing connections option. See the Domains and Accounts – Global Settings – Domains tab.

NOTE: For binding of the IP address for logging in, the C_Accounts_Policies_Login_DisableDomainIPLogin property has to be set to 0 using API.

This applies only for logging in when user names are used. When logging in with whole email addresses, setting to 0 is not necessary as IP address binding is ignored.


Enter a domain hostname to be used for outgoing connections.

This setting can be essential for domain identification by various AntiSpam technologies, including Greylisting, SPF and Intrusion Prevention. If defined here, the hostname defined under System – Services – Smart Discover – SMTP is bypassed.

NOTE: This option can be used just in the case the Use domain hostname for outgoing connections option (Domains & Accounts - Global Settings – Domains – Other) is enabled.


Domain folder, used for all domain settings and user accounts directories.

(By default, the path defined under System – Storage – Directories – Mail path is used.)

This acts as a prefix and is added to the mailbox path for all newly created accounts (within this domain).

NOTE: In the case you have mailboxes with non-standard mailbox paths in a domain, create the externaldirs.dat file with these paths and put it into the IceWarp/config directory.

E. g. you have most of users in a standard path but others are on a different disk (for example e) in the other_accounts folder. Add the e:\other_accounts path to the externaldirs.dat file.

Header / Footer

You have the option to specify a domain header and a footer. Enable the global header/footer option (Mail – General – Advanced tab – even if you do not use it globally) and open the domain Header/Footer dialog to specify your footer and header information. If the domain header and footer are not defined, the global will be used. You can see more in the global Header/Footer settings.

The Unknown Accounts section of the Options tab specifies how to handle messages that arrive for delivery to undefined accounts:





Specifies the action to take with any message that is destined for an account that is not defined on the server:

Reject mail

The message is rejected and returned to the sender. This is the recommended setting.

Forward to email address (catch-all)

The message is forwarded to the specified account. This can be useful if you wish to monitor these incoming messages but you could end up monitoring a lot of spam messages.

This is also a way an ISP can offer unlimited email aliases since messages can be sent to and it will be delivered to the this catch-all account. When using a catch-all account, it is suggested to switch on the Add X-Envelope-To option for that account (<account> – Options tab).

Enter the email address to use. Multiple addresses can be entered, separated by semicolons.

You can also use the '...' button to select accounts or groups with a dialog (see Select Accounts for more information).

Delete mail

The message is deleted, the sender will NOT be notified.


Specifies the email address that messages should be delivered to if the Forward to email address action is selected.

Send information to administrator

If this box is checked then the administrator's account will receive a copy of any message sent to any account that does not exist.

NOTE: This applies only in the case the Reject mail option or Delete mail is selected in the Action filed.

See Also








Directory Service



New Domain Wizard