Configure MX Records for Incoming SMTP E-Mail Traffic

[Jordan_Tsafaridis]

Αγαπητοί συνάδελφοι της κοινότητας καλησπέρα και σας εύχομαι Καλή Ανάσταση σε όλους σας και στις οικογένειές σας.

 

Λαμβάνοντας αφορμή από την πρόσφατη δημοσίευση με τίτλο "Second MX record for exchange", παρακάτω παραθέτω το παρακάτω άρθρο αυτούσιο στην Αγγλική.

 

Δυστυχώς δεν είχα τον απαραίτητο χρόνο για να το μεταφράσω. Ελπίζω ότι ο xrisxal2000 θα βρει τις απαντήσεις τις οποίες χρειάζεται στο θέμα του στο άρθρο αυτό.

 

Ιορδάνης Τσαφαρίδης

 

Configure MX Records for Incoming SMTP E-Mail Traffic

How do I configure and test the MX Record for my Internet Domain name?

When you want to run your own mail server, and it does not matter

what version and make of mail server you're using - as long as the mail

server is using SMTP as the e-mail transfer mechanism - you'll need to

configure the MX Records for your domain.

MX is an acronym for Mail eXchange. MX is defined in RFC 1035. It specifies

the name and relative preference of mail servers for the zone. MX is a

DNS record used to define the host(s) willing to accept mail for a given

domain. I.e. an MX record indicates which computer is responsible for

handling the mail for a particular domain.

Without proper MX Records for your domain, only internal e-mail will

be delivered to your users. External e-mail from other mail servers in

the world will not be able to reach your server simply because these

foreign servers cannot tell to which server they need to "talk" (or open

a connection to) in order to send the mail destined for that domain.

You can have multiple MX records for a single domain name, ranked in

preference order. If a host has three MX records, a mailer will try to

deliver to all three before queuing the mail.

MX Records must be in the following format:

domain.com.    IN    MX   10     mail.domain.com.

The Preference field is relative to any other MX Record for the zone

and can be on any value between 0 and 65535. Low values are more

preferred. The preferred value is usually 10 but this is just a

convention, not a thumb rule. Any number of MX Records may be defined.

If the host is in the domain it requires an A Record. MX Records do not

need to point to a host in the same zone, i.e. an MX Record can. point

to an A Record that is listed in any zone on that DNS or any other DNS

server.

External and Internet-connected networks

When connecting your mail server to the Internet (or to another

ex-organizational mailing system that uses SMTP) you must always make

sure that the rest of the world can successfully resolve your domain's

MX Record. Failing to do so will cause e-mail traffic not to be

delivered to you.

In order to properly configure your domain's MX Record you should

contact your ISP (Internet Service Provider) or the party responsible

for hosting your DNS Domain name. They will ask you for your FQDN (Fully

Qualified Domain Name) and IP address of your mail server. Make sure

you know them.

When your mail server is connected directly

to the Internet

In cases where no NAT (Network Address Translation) is being used and

where your mail server is directly connected to the Internet, you will

need to provide them with the FQDN and IP address of your mail server.

Note: This is, by far, the least secure method for

connecting a mail server to the Internet.

Let's say you have the following LAN configuration:

In the above example you need to give the mail server's IP address as

your MX Record.

Domain name: dpetri.net

Record FQDN	Record Type	Record Value	MX Pref
mail.dpetri.net	A	212.143.143.130
dpetri.net	MX	mail.dpetri.net	10

You should make sure the ISP has had all the necessary routing tables

updated in order to provide Internet availability to your internal IP

network range.

Note: It doesn't matter if the real host name of the

mail server is NOT "mail". Internet hosts don't mind that, they just

need to know what's the name of the mail server, and what's the IP

address for that name.

When NAT is being used

In cases where NAT (Network Address Translation) is being used you

will need to provide them with the IP address of your external NAT

interface, and configure your NAT device with Static Mapping for TCP

Port 25, and have all TCP Port 25 traffic forwarded to the internal IP

address of your mail server.

Let's say you have the following LAN configuration:

In the above example you need to give the NAT's IP address as your MX

Record.

Domain name: dpetri.net

Record FQDN	Record Type	Record Value	MX Pref
mail.dpetri.net	A	192.90.1.1
dpetri.net	MX	mail.dpetri.net	10

Note: Make sure you properly configure the NAT

device to forward all TCP Port 25 traffic to 192.168.0.10.

When a Mail Relay is being used

In cases where you have a DMZ (Demilitarized Zone) with a Mail Relay

host (i.e. Linux, Windows 2000/2003 + IIS and SMTP, a dedicated

appliance and so on) you will need to provide the FQDN and IP address of

your Mail Relay machine, and configure the Firewall to only allow TCP

Port 25 traffic to be sent to the Mail Relay's IP address, not to your

real mail server.

You should then configure the Mail Relay to forward the incoming

e-mail traffic to the real mail server (after scanning it for spam,

viruses and so on).

Let's say you have the following LAN configuration:

 

 

In the above example you need to give the Mail

Relay's IP address as your MX Record.

Domain name: dpetri.net

Record FQDN	Record Type	Record Value	MX Pref
mail.dpetri.net	A	192.90.1.17
dpetri.net	MX	mail.dpetri.net	10

Note: Make sure you properly configure the Firewall

device to forward all TCP Port 25 traffic to 192.90.1.17, and to allow

192.90.1.17 to send TCP Port 25 traffic to your internal mail server at

192.168.0.10. Also, make sure you let the internal mail server

communicate only with the Mail Relay device and that you set up an SMTP

Connector on the mail server and configure it to relay all external mail

to the Mail Relay.

Note: Some networks might use the Internet Router as

their NAT device, and let the Firewall do just that. In those cases,

the scenario is a mixture between option #2 (NAT) and this one.

Internal networks

As stated above, there is usually no need to configure MX Records for

internal use, simply because internal (i.e. inter-organization) e-mail

and replication traffic is usually controlled via Active Directory-store

information. However there are some cases where you will want to

configure internal MX Records.

While these MX Records will generally not cause any harm even if you

configure them without actually needing them, you must pay close

attention to various configuration issues, especially when Mail-Relays

and Smart-Hosts are involved. Therefore I cannot say for sure if

configuring non-necessary MX Records will cause any problems to your

local network. If you do not know for sure (and this might be the case

since you've bothered to read this article in the first place) I suggest

you consult a network specialist before doing any changes.

Fault Tolerance

In case your mail server fails you'd like to still be able to receive

incoming e-mail messages. Most small to medium sized companies will pay

their ISPs some monthly fee and that will buy them storage space on the

ISPs mail servers. For that to happen, a new MX Record will be added to

their DNS information, pointing to the ISPs mail server with a higher

priority. For example:

Record FQDN	Record Type	Record Value	MX Pref
mail.dpetri.net	A	192.90.1.17
mail.isp.com	A	212.143.25.1
dpetri.net	MX	mail.dpetri.net	10
dpetri.net	MX	mail.isp.com	100

Load Balancing

Medium to large sized companies will want to configure some load

balancing features for their incoming mail servers. For that to happen,

the company must set up a number of mail servers, each one with a

different IP address (actually, one can use Network Load Balancing -

NLB, or even clustering but that's a topic for a different article).

Then new MX Records will be added to their DNS information, pointing to

the mail servers, all with the same priority. For example:

Record FQDN	Record Type	Record Value	MX Pref
maila.dpetri.net	A	192.90.1.17
mailb.dpetri.net	A	192.90.1.18
mailc.dpetri.net	A	192.90.1.19
mail.isp.com	A	212.143.25.1
dpetri.net	MX	maila.dpetri.net	10
dpetri.net	MX	mailb.dpetri.net	10
dpetri.net	MX	mailc.dpetri.net	10
dpetri.net	MX	mail.isp.com	100

Testing the MX Record configuration

Testing the MX Record configuration is critical especially when

configuring it for the first time with a new ISP you don't know that

well and so on. Use NSLOOKUP or DIG or any other DNS querying tool to

make sure your records are set straight.

Sample screenshot is of an NSLOOKUP test to Microsoft's MX Records:

Also, make sure you can connect to the mail server by using the MX

Record information. You can do so by using Telnet, as described in the SMTP, POP3 and

Telnet in Exchange 2000/2003 and Test SMTP Service in

IIS and Exchange articles.

 

[Develekos]

Καλή Ανάσταση και σε εσένα συνάδελφε,

Βέβαια σε κάθε περίπτωση θα μπορούσες απλά να βάλεις το link για την εν λόγω σελίδα και όχι όλο το κείμενο [].

 

Εσύ να 'σαι καλά,

Γιάννης