dialog question 64x64 FAQ – Technical recommendations
 		 

The section is under development.

If you have suggestions or questions that should be covered in this section, please mail us to Contact .

 

How to configure properly a domain for receiving and sending of E-Mails? (click to show/hide)

Work with E-mail can be divided into two stages:

  • Receipt of email.
  • Sending of email.

For reliable operation of each of the steps it is necessary to make the following settings:

.

Settings for receipt of email:

.

Required:

  • A mail server on which your domain is registered in the list of domains it serves.
  • Publication in the DNS zone of your domain an «MX» record that refers to your email server.

.

Remember:

  • When creating an MX-record, specify the server name but not its IP-address.
  • After creation of MX-type record, it is necessary to enter an A-type record for the name of the server.

In the domain's zone file it looks like this:

@    IN MX 10 mail

mail IN A     5.6.7.8

  • It is preferably to choose a server name which "speaks" of the functionality of the server, for example, MX.domain.name. I.e. any name indicating its direct relation to the processing of emails. The most frequently used names are MX, Mail, EMail, SMTP, Relay, etc.
  • For each MX-record, a degree of Preference (Priority) is specified. This numerical value is in the range from 1 to 255. In this case the smaller is the number, the higher is the priority of the server. Often a standard gradation is used:

10 — Very high.

20 — High.

30 — Normal.

40 — Low.

If you have a single email server, it can be of any Priority, preferably not more than 50.

You can get a list of email servers of a domain using the command:

# nslookup -type=mx domain.name

.

.

Settings for email sending:

This stage of setting is the most crucial, because its proper execution influences the reliability of delivery of your email to email servers of other domains.

.

Required:

  • Unauthorized sending of email on your email server must be disabled (Free Relay). Otherwise, SPAMmers will eventually settle on your server, and the server will be included into "Black lists" of many mail systems or RBL / DNSBL services.
  • To configure Reverse Resolving for an IP-address of an email server. Checking this conformity is a basic SPAM protection.

Setting and inspection of Reverse zone (Reverse Resolving):

For each host there must be configured a PTR-record which returns the host name. For this name an A-record in the DNS zone of the domain must exist, which returns the IP-address of the host. This confirms the belonging of the host to the domain.

.

Reverse Resolve (Reverse Resolving):

# nslookup -type=ptr 1.2.3.4

Non-authoritative answer:

4.3.2.1.in-addr.arpa name = web-mail.domain-mail.com.

.

Direct Resolve (Resolve):

# nslookup -type=a web-mail.domain-mail.com.

Non-authoritative answer:

Name: web-mail.domain-mail.com.

Address: 1.2.3.4

.

Remember:

  • A name returned at Reverse Resolve (Reverse Resolving), must match the name of the email server declared in the corresponding MX-record of the domain and in the A-record for a name.
  • It is an ERROR to specify several names for the IP-address of the server in the Reverse Resolve zone, for example: MX.domain.name and GW.domain.name. As a result, the server cannot always be checked by the Reverse Resolve. The reason for this phenomenon is in the technology of the DNS server operation, which gives the names in the form of a list, with unpredictable sequence of names, and the checking party often takes the first name from the list in the response..
  • Who and on what DNSs specifies the Reverse Resolve?

There are two variants:

    • If you use addresses provided by your HSP/ISP, then the question should be addressed to him. Some HSPs/ISPs provide an opportunity to define names for the IP-addresses given to the client through the corresponding service in the "Personal Account".
    • If your company has acquired its own AS (Autonomous System) with a pool of addresses, so to perform a Reverse Resolve, in the requisites sent to the AS registrar you must specify a list of DNS servers, on which the corresponding [.IN-ADDR.ARPA] zone will be located.

.

How to delegate an authority to send email on behalf of your domain, or what is a SPF and what is it used for?

.

To send e-mail on behalf of your domain, the host must be ready to undergo a series of checks on its personal trustworthiness:

  • The Reverse Zone of the host must be checked. You need to link the IP-address of this host with your domain by configuring for it the Direct and Reverse Resolve to DNS.
  • Even if the host has proved its involvement in your domain, it must be authorized to send e-mail. These rights must be specified in the email policy of the domain, SPF-record of the domain.

To manage the rights for sending e-mail on behalf of the domain, an SPF (Sender Policy Framework) technology is used. More details about the SPF technology are available on http://www.openspf.org/. The majority of modern MTAs support the SPF and provide tools for its tweaking. You can find more information about the SPF syntax on the same resource http://www.openspf.org/SPF_Record_Syntax.

.

The SPF-record in the DNS zone has the TXT-type and the following format:

@ IN ТXT «v=spf1 mx -all»

or

@ IN ТXT «v=spf1 a mx -all»

or

@ IN ТXT «v=spf1 +a +mx -all»

where:

«v=spf1» — is a version of SPF-record format, for proper recognition of the record by the server.

«mx» or «+mx» — is a tag that recommends to receive email from email servers of the domain. I.e. from the addresses which the checking party receives in two stages: a request of the list of email servers names, and then a request of the list of IP-addresses for each email server.

«a» or «+a» — is a tag that recommends to receive email from all the IP-addresses for which there is a record of A-type in the DNS zone of the domain.

ATTENTION: The tag «a» or «+a» makes sense if an IP-address of the server from which email is sent, can pass the Reverse zone check.

«-all» — is a tag of the policy towards all other senders of email on behalf of your domain.

.

Can have the following values:

«+all» — to receive email (NOT RECOMMENDED).

«-all» — not to receive email (RECOMMENDED).

«~all» — receipt of email at the discretion of the receiving party.

.

It is possible to give a server the right to send email on behalf of your domain, even if it cannot pass the check by tags «+a» and «+mx», by means of the tag:

«ip4:<ip4-address>» — is a single trusted IP-address.

or

«ip4:<ip4-network>/<prefix-length>» — is a trusted network.

.

Thus, for a domain with a single trusted address [1.2.3.4] and a trusted network [3.4.5.0/24], the SPF-record will be as follows::

@ IN ТXT «v=spf1 ip4:1.2.3.4 ip4:3.4.5.0/24 a mx -all»

or

@ IN ТXT «v=spf1 ip4:1.2.3.4 ip4:3.4.5.0/24 +a +mx -all»

ATTENTION:

      • Sequence of tags does not matter.
      • All tags must be separated by a space.
      • Do not write a network in the form of [3.4.5.*] and other variations. I.e. in the «ip4:» tag format other characters except [0-9/.] are not permitted.
      • It is not recommended to write a network in the format of [3.4.5.1/24]. When you specify a network, you must specify <network address>/<mask> and not <any network address>/<mask>. If you have difficulties in calculating network addresses masks, you can use the IP-calculator, for example: http://jodies.de/ipcalc.
      • Do not specify systems not controlled by you in the list of trusted hosts and networks. Besides, do not write ranges of the type: «ip4:128.0.0.0/1» or all networks of your provider with a "reserve" and other "simplifications". Remember that networks under a mask [/16], and less, are rarely specified even by large email hostings and portals.
      • Is not recommended for Internet providers to specify in the list of trusted networks any networks allocated for clients for static and furthermore, for dynamic allocation. These ranges most likely get into blocked ranges, which can lead to blocking of the entire domain.

Other SPF-tags and their extensions, such as: [a/<prefix-length>], [a:<domain>], [a:<domain>/<prefix-length>], [ptr], [exists] and [exp] shall be used at the discretion of administrators. Tags [include] and [redirect] should be used with caution, especially if you include SPF-records of foreign domains as trusted.

ATTENTION: If you use tags «a» and «ptr», you need to duplicate the addresses of hosts and networks in the tags «ip4:».

.

Final settings of DNS zone of the domain in the mail system should be as follows:

@    IN MX 10 mail

mail IN A     5.6.7.8

@    IN ТXT «v=spf1 mx -all»

or, if it is necessary to specify trusted addresses and networks:

@    IN MX 10 mail

mail IN A     5.6.7.8

@    IN ТXT «v=spf1 ip4:1.2.3.4 ip4:3.4.5.0/24 mx -all»

.

Now the domain setting for receiving / sending email can be considered as completed.

.

For example, you can see how academically competent, in terms of mail systems, the following domains were configured: YANDEX.RU, GMAIL.COM .

.

How to arrange the work of mail system of the hosting company. How to ensure sending of e-mail messages from WEB-site or other service on the hosting. (click to show/hide)

What is a Hosting company (Hosting, Hosting-operator, HSP (Hosting Service Provider))?

Hosting company – is a company engaged in the provision of services on placement of equipment, data storage and processing, hosting and implementation of application software (WEB-sites, etc.) of the customer on its technical platform.

The most widespread list of services of the hosting company:

  • Registration of domains.
  • Provision of services of Primary / Secondary DNS – means hosting of DNS zone of a domain.
  • Mail hosting – means receiving, sending, storage, provision of authorized access to stored email of the customer.
  • WEB-hosting – means hosting of websites.
  • VDS/VPS hosting – means creation and use of virtual servers.
  • Leasing of their equipment, most often of physical servers.
  • Colocation – is physical placement of equipment of the customer at hosting site and its connection to the means of communication.
  • Provision of technical means and conditions for creation of Cloud-solutions (Cloud-hosting).

ATTENTION: despite of a sufficiently large list of services, all of them are of technical nature. A hosting company is not obliged to provide services on right setting and maintenance of infrastructure of the customer, except for the cases when the service is provided separately on a paid basis, and has been acquired by the customer.

The list shows that only one service has a direct relationship to email – Mail hosting.

An optimal solution for mail hosting can be "Universal architecture of the mail system", see Architecture.

.

Mail hosting.

Formally, Mail hosting can be divided into two groups:

  • Simple — is a hosting which serves one or several domains belonging to a hosting company. This group includes most of free mail systems.
  • Multi-Domain — is a hosting that processes email not only of its domain(s), but also e-mail of customers’ domains.

It does not matter, to which group Mail hosting belongs; it should provide receipt, sending / forwarding and storage of customer e-mail, as well as provide an authorized access to it.

Storage of e-mail and an authorized access to it is entirely an area of responsibility of the hosting company.

Reliability of receipt and delivery of e-mail depends on the correct setting of DNS zone of the hosting company’s domain(s), DNS zone of the customer’s domain, as well as on the settings of DNS zones of mail systems with which an interaction occurs.

What must be declared in the DNS zone of any domain in terms of email?

  • MX-servers for receiving incoming email of the domain and to send the outgoing email of the domain.
  • If you use SMTP/Relay servers to send outgoing e-mail directly to MX-server of the recipient's domain, bypassing the MX-server of the sender’s domain, their IP-addresses or domain names must be specified in the SPF-record of email policy of the domain.
  • If you use WEB-Mail front, that gives users access to their email, as well as allows sending email messages using WEB-interface directly to the MX-server of the recipient’s domain, bypassing the MX-server of the sender’s domain, IP-addresses or domain names of this front must be specified in the SPF-record of email policy of the domain.

IMPORTANT: A hosting company that provides the service of Multi-domain mail hosting, should take the utmost responsibility in configuring the SPF-record of email policy of the domain when configuring the DNS zone. Is required to specify not only MX-servers for incoming email, but also a list of IP-addresses / networks [ip4:2.3.4.5] or domain names [a:web123.hsp-mail.name] of all trusted Relay servers from which the customer’s email can be sent. Why?

  • When configuring his domain, the customer specifies MX-servers of the hosting as MX-servers of his domain.
  • When configuring the SPF-record of email policy of his domain, the customer, in addition to his trusted hosts, should delegate to the hosting domain an authority to send e-mail on behalf of his domain. This action is performed by a field [include:] in the SPF-record. And it usually has the form:

@ IN TXT «v=spf1 ip4:3.4.5.6 include:HSP-Mail.name mx -all»

If the hosting is limited by a simplified SPF-record, like:

@ IN TXT «v=spf1 a mx ~all»

When inheriting such policy, failures of analysis and summation are guaranteed. Due to uncertainty what is meant by the field «a» – the domain of the hosting or the domain of the customer. Also very often not a starting SPF-record is indicated, but a field in the form of [include:spf.hsp-mail.name].

ATTENTION: all hosts listed as MX-servers or trusted senders in the SPF record of the domain should pass a check of the Reverse zone (Reverse Resolving).

ATTENTION:It is prohibited to indicate address ranges intended for virtual WEB-hosting or other services provided to customers in the SPF-records of hosting domains.

The reasons for this approach are obvious:

  • A hosting company is not able to control all WEB-sites hosted on its platform; at the same address there may be several hundreds or even thousands of them.
  • A hosting company is not engaged in administration of resources provided for the customer, except for the cases when the service is provided separately on a paid basis and has been purchased by the customer.

Consequently, there is no way to go bail for the trustworthiness of these resources. In most cases, these resources are connected with other domains or not connected with any domain, for example, test resources.

.

How to send e-mail from WEB-site, VDS/VPS and resources on the platform of a hosting company?

In this situation, we can recommend:

  • An authorized sending of email through the SMTP / Relay server of any domain in which the customer of the resource has an account.
  • If the resource (WEB-server, VDS / VPS, etc.) is completely under the control of the customer, it can be specified in the DNS zone of the domain of the resource customer in the fields MX / SPF as an authorized recipient / sender.
  • IP-address of the sender resource (WEB / VDS / VPS) can be included into the local White List of the SMTP / Relay server which is administered by the customer of the resource. Be careful if this is a WEB-site on a virtual hosting - on the same IP-address a lot of sites can be hosted.

We remind that the SMTP / Relay server is not engaged in receiving of incoming email of the domain; it doesn’t perform check of connections on the RBL / DNSBL services and must provide the Relay service only to authorized clients..

.

How to start the use of RBL? (click to show/hide)

In order to start using the RBL.RBLDNS.RU service, it is enough to specify it in the appropriate settings of your email server.

ATTENTION:

To avoid loss of important email, you must:

  • At the initial stage of use of RBL, avoid use of REJECT (refusal of receipt) policy of email from untrustworthy hosts. It is recommended to use marking for dubious emails or send them to a special mailbox. Pay your attention that the "manual analysis" is not a tedious task, because when receiving of hundreds of typical messages, they are easily grouped by theme and other features. Attention is paid only to such emails which fall out of the total mass.

 SPAM-GROUP-2

 

  • At the last stage, when during long time (1-2 months) there will be no problems in sending email, you can go to rejection of receiving email from the hosts of our RBL.

At erroneous blocking of the host you need to request an automated RBL control system to update the information about blocked domain in the section Service. If the domain is configured in accordance with our recommendations, it will be excluded from the Blocking list within 1-3 hours.

.

How to view settings of mail system of the domain? (click to show/hide)

At troubleshooting and resolving problems in delivery of e-mail, you must be able to determine the settings of the mail system in the DNS, both your own and others'.

Getting a list of mail servers of the domain:

# nslookup -type=mx domain.name

Getting the SPF-record (s) for the domain:

# nslookup -type=txt domain.name

Select data rows beginning with the prefix: [v=spf1].

For the fields obtained in the tags [include] and [redirect]a request is repeated individually:

# nslookup -type=txt spf.domain-include.name

.

.

Go to top