mx records

9
Configure MX Records for Incoming SMTP E-Mail Traffic  by Daniel Petri - January 7, 2009 How do I configure and test the MX Record for my Internet Domain name? There are several new features included within Exchange Server 2007, which some of my articles touch on briefly. However, if you are looking for training that takes you from installation to integration with Outlook and management of Exchange Server 2007 then you need Train Signal's training videos. The Exchange Server 2007 training videos are taught by Microsoft MVP and MCSE, David Shackelford, who teaches with a "Hands- on" approach. 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 c onnection 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 queu ing 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 h ost 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.

Upload: vipin-mathur

Post on 10-Apr-2018

218 views

Category:

Documents


0 download

TRANSCRIPT

8/8/2019 MX Records

http://slidepdf.com/reader/full/mx-records 1/9

Configure MX Records for Incoming

SMTP E-Mail Traffic

 by Daniel Petri - January 7, 2009

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

There are several new features included within Exchange Server 2007, which some of my

articles touch on briefly. However, if you are looking for training that takes you frominstallation to integration with Outlook and management of Exchange Server 2007 then

you need Train Signal's training videos. The Exchange Server 2007 training videos are

taught by Microsoft MVP and MCSE, David Shackelford, who teaches with a "Hands-on" approach.

When you want to run your own mail server, and it does not matter what version andmake 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 reachyour 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 anyvalue 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 notneed 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.

8/8/2019 MX Records

http://slidepdf.com/reader/full/mx-records 2/9

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 cansuccessfully 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:

8/8/2019 MX Records

http://slidepdf.com/reader/full/mx-records 3/9

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.130dpetri.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, andwhat'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.

8/8/2019 MX Records

http://slidepdf.com/reader/full/mx-records 4/9

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 25traffic 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 thereal mail server (after scanning it for spam, viruses and so on).

Let's say you have the following LAN configuration:

8/8/2019 MX Records

http://slidepdf.com/reader/full/mx-records 5/9

The Domain name system (DNS) implements a distributed, hierarchical, and redundant

database for information associated with Internet domain names and addresses. This List

of DNS record types provides an overview of types of resource records (database

records) stored in the zone files of the DNS.

 [ edit  ] Resource Records

Code NumberDefining

RFCDescription Function

A 1 RFC 1035 addressrecord

Returns a 32-bit IPv4 address,most commonly used to map

hostnames to an IP address of the host, but also used for 

DNSBLs, storing subnetmasks in RFC 1101, etc.

AAAA 28 RFC 3596IPv6 address

record

Returns a 128-bit IPv6

address, most commonly usedto map hostnames to an IP

address of the host.

8/8/2019 MX Records

http://slidepdf.com/reader/full/mx-records 6/9

AFSDB 18 RFC 1183AFS

database

record

Location of database servers of 

an AFS cell. This record is

commonly used by AFSclients to contact AFS cells

outside their local domain. A

subtype of this record is used by the obsolete DCE/DFS file

system.

CERT 37 RFC 4398Certificate

recordStores PKIX, SPKI, PGP, etc.

CNAME 5 RFC 1035Canonical 

name record

Alias of one name to another:

the DNS lookup will continue

 by retrying the lookup with thenew name.

DHCID 49 RFC 4701DHCP

identifier

Used in conjunction with the

FQDN option to DHCP

DLV 32769 RFC 4431

DNSSEC

Lookaside

Validation

record

For publishing DNSSEC trustanchors outside of the DNS

delegation chain. Uses the

same format as the DS record.RFC 5074 describes a way of 

using these records.

DNAME 39 RFC 2672delegation

name

DNAME will delegate anentire portion of the DNS tree

under a new name. In contrast,

the CNAME record creates analias of a single name. Like the

CNAME record, the DNSlookup will continue by

retrying the lookup with thenew name.

DNSKEY 48 RFC 4034DNS Key

record

The key record used in

DNSSEC. Uses the sameformat as the KEY record.

DS 43 RFC 4034Delegation

signer

The record used to identify the

DNSSEC signing key of a

delegated zone

HIP 55 RFC 5205 Host IdentityProtocol

Method of separating the end-

 point identifier and locator 

roles of  IP addresses.

IPSECKEY 45 RFC 4025 IPSEC KeyKey record that can be used

with IPSEC

KEY 25 RFC 4034 Key record Used only for TKEY (RFC

2930). Before RFC 3755 was published, this was also used

8/8/2019 MX Records

http://slidepdf.com/reader/full/mx-records 7/9

for DNSSEC, but DNSSEC

now uses DNSKEY.

LOC 29 RFC 1876Location

record

Specifies a geographicallocation associated with a

domain name

MX 15 RFC 1035mailexchange

record

Maps a domain name to a listof mail exchange servers for 

that domain

 NAPTR  35 RFC 3403Naming

Authority

Pointer

Allows regular expression

 based rewriting of domainnames which can then be used

as URIs, further domain names

to lookups, etc.

 NS 2 RFC 1035name server

record

Delegates a DNS zone to use

the given authoritative name

servers

 NSEC 47 RFC 4034Next-Secure

record

Part of DNSSEC—used to prove a name does not exist.

Uses the same format as the

(obsolete) NXT record.

 NSEC3 50 RFC 5155NSEC record

version 3

An extension to DNSSEC that

allows proof of nonexistence

for a name without permittingzonewalking

 NSEC3PARAM 51 RFC 5155NSEC3

parameters

Parameter record for use with

 NSEC3

PTR 12 RFC 1035pointer

record

Pointer to a canonical name.Unlike a CNAME, DNS

 processing does NOT proceed,

 just the name is returned. Themost common use is for 

implementing reverse DNS

lookups, but other uses include

such things as DNS-SD.

RRSIG 46 RFC 4034DNSSEC

signature

Signature for a DNSSEC-

secured record set. Uses the

same format as the SIG record.

SIG 24 RFC 2535 Signature

Signature record used inSIG(0) (RFC 2931). Until

RFC 3755 was published, the

SIG record was part of DNSSEC; now RRSIG is used

for that.

SOA 6 RFC 1035 start of 

authority

Specifies authoritative

information about a DNS

8/8/2019 MX Records

http://slidepdf.com/reader/full/mx-records 8/9

record

zone, including the primary

name server, the email of the

domain administrator, thedomain serial number, and

several timers relating to

refreshing the zone.

SPF 99 RFC 4408 SPF record

Specified as part of the SPF

 protocol, as an alternative to

storing SPF data in TXTrecords. Uses the same format

as the TXT record.

SRV 33 RFC 2782Service

locator

Generalized service location

record, used for newer  protocols instead of creating

 protocol-specific records such

as MX.

SSHFP 44 RFC 4255

SSH Public

Key

Fingerprint

Resource record for publishingSSH  public host key

fingerprints in the DNS

System, in order to aid inverifying the authenticity of 

the host.

TA 32768 NoneDNSSEC

Trust

Authorities

Part of a deployment proposalfor DNSSEC without a signed

DNS root. See the IANA

database and Weiler Spec] for details. Uses the same format

as the DS record.

TXT 16 RFC 1035 Text record

Originally for arbitrary

human-readable text in a DNSrecord. Since the early 1990s,

however, this record more

often carries machine-readabledata, such as specified by RFC

1464, opportunistic

encryption, Sender PolicyFramework (deprecated),

DomainKeys, DNS-SD, etc.

 [ edit  ] Other types and Pseudo Resource Records

Other types of records simply provide some types of information (for example, an

HINFO record gives a description of the type of computer/OS a host uses), or others

return data used in experimental features. The "type" field is also used in the protocol for various operations.

8/8/2019 MX Records

http://slidepdf.com/reader/full/mx-records 9/9

Code NumberDefining

RFCDescription Function

* 255 RFC 1035All cached

records

Returns all records of all types knownto the name server. If the name server 

does not have any information on the

name, the request will be forwardedon. The records returned may not be

complete. For example, if there is both

an A and an MX for a name, but thename server has only the A record

cached, only the A record will be

returned.

AXFR  252 RFC 1035Full Zone

Transfer

Transfer entire zone file from themaster name server to secondary name

servers.

IXFR 251 RFC 1995

Incremental

Zone

Transfer

Requests a zone transfer of the given

zone but only differences from a previous serial number. This request

may be ignored and a full (AXFR) sent

in response if the authoritative server is unable to fulfill the request due to

configuration or lack of required

deltas.

OPT 41 RFC 2671 OptionThis is a "pseudo DNS record type"

needed to support EDNS

TKEY 249 RFC 2930Transaction

Key

One way of providing a key to be usedwith TSIG

TSIG 250 RFC 2845Transaction

Signature

Record that supports one set of security mechanisms for DNS. Used to

secure communication between DNSresolvers and Name servers, in

contrast to DNSSEC, which secures

the actual DNS records from theauthoritative name server.