Re: Newbie to Exchange needs MX record info

That's correct.
Although since it's RFC defined, they do have some structure in it to
prevent happenstance but what you describe is pretty much the way it works.
:)

Al

"Gary Demi" <GaryDemi@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0F38B9FB-B0D4-47EB-90A0-3D10FEF808D9@xxxxxxxxxxxxxxxx
> Thanks, I was going on the assumption that the URL of the mailserver was
> comething like an http server such that http://page1.mydomain.com needed
> a
> defintion for page1 within the http server for mydomain.com.
> As I undersand it now you can give your mail server any name (in the MX
> record) thing as long as somehwere that name is resolved to an IP address
> that listens on port 25.
> --
> Gary Demi
> Software & Communication Concepts, Inc.
> Microsoft Registered Partner
> Houston, & Phoenix
>
>
>
> "Al Mulnick" wrote:
>
>> Here's your current:
>> Non-authoritative answer:
>> tektoneco.net MX preference = 0, mail exchanger = mail1.tektoneco.net
>> tektoneco.net MX preference = 10, mail exchanger = mail.tektoneco.net
>>
>> tektoneco.net nameserver = park10.secureserver.net
>> tektoneco.net nameserver = park9.secureserver.net
>> park9.secureserver.net internet address = 64.202.165.114
>> park10.secureserver.net internet address = 64.202.167.153
>>
>>
>> Here's Microsoft's:
>>
>> Non-authoritative answer:
>> microsoft.com MX preference = 10, mail exchanger = mailb.microsoft.com
>> microsoft.com MX preference = 10, mail exchanger = mailc.microsoft.com
>> microsoft.com MX preference = 10, mail exchanger = maila.microsoft.com
>>
>> microsoft.com nameserver = ns3.msft.net
>> microsoft.com nameserver = ns4.msft.net
>> microsoft.com nameserver = ns5.msft.net
>> microsoft.com nameserver = ns1.msft.net
>> microsoft.com nameserver = ns2.msft.net
>> maila.microsoft.com internet address = 131.107.3.124
>> mailb.microsoft.com internet address = 131.107.3.123
>> mailc.microsoft.com internet address = 207.46.121.52
>> ns1.msft.net internet address = 207.46.245.230
>> ns2.msft.net internet address = 64.4.25.30
>> ns3.msft.net internet address = 213.199.144.151
>> ns4.msft.net internet address = 207.46.66.75
>> ns5.msft.net internet address = 207.46.138.20
>>
>>
>>
>> Note how maila.microsoft.com has a corresponding record? That's an A
>> record
>> for the responsible host. So, you would define xxx.domain.com which
>> equates
>> to FQDN of a host. XXX == hostname while domain.com == tektoneco.net.
>> (note: I simplified these records to make the illustration clearer)
>> microsoft.com MX preference = 10, mail exchanger = maila.microsoft.com
>> maila.microsoft.com internet address = 131.107.3.124
>>
>> Translated means that for the zone microsoft.com, the mailhandler with a
>> preference of 10 is maila.microsoft.com or host maila in the
>> microsoft.com
>> domain is responsible for handling mail destined for the microsoft
>> domain.
>> In your case, I see A records for park9 and park10 in the
>> secureserver.net
>> domain. You would want one of those hosts to handle mail for you I
>> assume.
>> If not, then you'll need to publish a host record in the tektoneco.net
>> domain. That host might be named mail or it might be something else, but
>> if
>> it listens on tcp 25 and handles mail destined for tektoneco.net domain,
>> then it should have a corresponding MX record.
>>
>> CNAME records are discouraged by RFC so it's best not to use them if
>> possible.
>>
>> Does that make more sense?
>>
>> If not, drop a note to my email address and let me know. I don't always
>> catch NNTP messages.
>>
>> Al
>>
>>
>>
>> "Gary Demi" <GaryDemi@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:091412CA-F029-4375-B8E3-7DCD87C64CF5@xxxxxxxxxxxxxxxx
>> >I still don't get it, I took the cname records out for mail and set my
>> >mx
>> > records to
>> > pri=0 mail1.tektoneco.net
>> > pri=10 mail.tektoneco.net
>> > yet dnsreport doesn't like this at all, says thoses addressess resolve
>> > to
>> > 0.0.0.0, which I gues they should since we have no cname record for
>> > mail.tektoneco.net. I am still confused on what the Exchange mail
>> > server
>> > URL
>> > is. I would guess it must be xxxx.mydomain.com, so what is xxx using
>> > the
>> > default SBS2003 setup.
>> > Or otherwise where is the mailserver name determined by exchange.
>> >
>> > Take a look at our domain tektoneco.net , right now it is very
>> > difficult
>> > for
>> > me to make changes to the NS records as the owner want's me to go
>> > through
>> > him
>> > on any changes to the domain. I have full control over the server.
>> >
>> > I need to sit down and go through some basic Exchange documentation
>> > and/or
>> > tutorials, but right now, it's almost all working, just this silly MX
>> > record
>> > problem.
>> > --
>> > Gary Demi
>> > Software & Communication Concepts, Inc.
>> > Microsoft Registered Partner
>> > Houston, & Phoenix
>> >
>> >
>> >
>> > "Al Mulnick" wrote:
>> >
>> >> CNAME records are discouraged from being used for mail handling.
>> >> A records and MX records are the preferred method.
>> >>
>> >> Create an MX record for your domain, and whatever the A record is, it
>> >> is.
>> >>
>> >> As for the ISP's, each one will vary. There is no value in checking
>> >> to
>> >> see
>> >> if the sending host has an MX record as far as I'm concerned. SPF
>> >> values
>> >> are worse then worthless IMHO as they allow a spammer to publish and
>> >> then
>> >> in
>> >> practice, many hosts would allow bypassing of normal checks.
>> >>
>> >> Some ISP's do reverse lookup on the host to see if it belongs to the
>> >> domain
>> >> that's sending. That's accomplished with a PTR record. You *should*
>> >> configure a PTR record for your sending host.
>> >>
>> >> Can you post some of the NDR's you get for delivery if that doesn't
>> >> clear
>> >> some of your issues up and the recipient domain ISP name?
>> >>
>> >> Al
>> >>
>> >> "Gary Demi" <GaryDemi@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> >> news:451DB892-823C-49EF-8569-A0C9CE761FA1@xxxxxxxxxxxxxxxx
>> >> > Thanks for the info.
>> >> > I already have an 'A' record, it consists of @ and my IP address
>> >> > this
>> >> > works
>> >> > fine for http, https and ftp access (with associated CNAME records)
>> >> >
>> >> > For Exchange Mail 2003 As I understand It,
>> >> > I create a 'Cname' record such as alias=mail , points to @ ,
>> >> > ttl=3600
>> >> > then the MX record
>> >> > PRI=0, HOST=@
>> >> >
>> >> > This will allow other mail handlers to deliver mail to Exchange
>> >> > using
>> >> > anybody@xxxxxxxxxxxx (actual domain removed).)
>> >> >
>> >> > Wil this also fix the problem of bounced outgoing mail, as
>> >> > apparently
>> >> > many
>> >> > ISP's we send mail to apparently check to see if I am sending mail
>> >> > from
>> >> > a
>> >> > legit domain?
>> >> >
>> >> >
>> >> > Gary Demi
>> >> > Software & Communication Concepts, Inc.
>> >> > Microsoft Registered Partner
>> >> > Houston, & Phoenix
>> >> >
>> >> >
>> >> >
>> >> > "Al Mulnick" wrote:
>> >> >
>> >> >> The help file that comes with Exchange would be appropriate. Search
>> >> >> SMTP
>> >> >> and
>> >> >> or Internet.
>> >> >>
>> >> >> MX records are not "required" per se to deliver mail per RFC.
>> >> >> However,
>> >> >> it
>> >> >> is
>> >> >> a best practice to have one that designates the mail handler for
>> >> >> your
>> >> >> domain. This is accomplished by designating a host as a mail
>> >> >> handler
>> >> >> (MX
>> >> >> is
>> >> >> the designation for mail handler in DNS terms.)
>> >> >>
>> >> >> It is a best practice to designate a MX record that specifies a
>> >> >> host
>> >> >> by
>> >> >> it's
>> >> >> A record vs. any other type of record. During a SMTP transaction,
>> >> >> the
>> >> >> MTA
>> >> >> (mail transfer agent) will receive a message. It will determine
>> >> >> where
>> >> >> to
>> >> >> deliver that message and if it determines that message to be a
>> >> >> remote
>> >> >> MTA,
>> >> >> it will then look at it's routing table to figure out if it knows
>> >> >> how
>> >> >> to
>> >> >> contact that responsible MTA. If it doesn't have a specific route,
>> >> >> it
>> >> >> will
>> >> >> then look to DNS and specifically will look for a MX record that
>> >> >> specifies
>> >> >> the mail handler for that domain (domain here is everything to the
>> >> >> right
>> >> >> of
>> >> >> "@" in the address.) If an MX record does not exist, the MTA will
>> >> >> look
>> >> >> for
>> >> >> an A record. If that doesn't exist, it will fail the delivery and
>> >> >> return
>> >> >> a
>> >> >> non-delivery receipt (NDR). If an MX record does exist, it should
>> >> >> reference
>> >> >> an A record. Once that A record is discovered, it will be queried
>> >> >> for
>> >> >> it's
>> >> >> IP address and a conversation will be started between the MTA's via
>> >> >> the
>> >> >> well
>> >> >> known SMTP port, TCP 25. Messages will then be transferred and the
>> >> >> recipient
>> >> >> MTA will become responsible for the next step of delivery.
>> >> >>
>> >> >> Basically, that's how it works. Daniel Petri seems to have taken
>> >> >> the
>> >> >> time
>> >> >> to explain it as well.
>> >> >> http://www.petri.co.il/configure_mx_records_for_incoming_smtp_email_traffic.htm
>> >> >>
>> >> >> Having more than one MX record is done because the way SMTP mail
>> >> >> works,
>> >> >> it
>> >> >> will try the lowest weighted (preferred) mail handler first. If it
>> >> >> receives
>> >> >> an error (depends on the error type), the sending MTA should then
>> >> >> try
>> >> >> to
>> >> >> send to the next mailer listed. This provides some level of failure
>> >> >> tolerance because you can have multiple hosts that receive mail for
>> >> >> your
>> >> >> domain. Should one be out of service, the other should pick up the
>> >> >> slack.
>> >> >> It's not a requirement.
>> >> >>
>> >> >> Typically, your ISP will offer queuing services. If your host
>> >> >> should
>> >> >> be
>> >> >> down, they'll accept mail for your domain until you come back
>> >> >> on-line
>> >> >> at
>> >> >> which time they'll dump the queued messages to your mailer. So in
>> >> >> practice,
>> >> >> you'll often see records that look like:
>> >> >>
>> >> >> yourdomain.net MX preference = 10, mail exchanger =
>> >> >> smtp.yourdomain.net
>> >> >> yourdomain.net MX preference = 50, mail exchanger =
>> >> >> SMTP.yourISP.net
>> >> >>
>> >> >> Which would typically send mail destined for your domain to
>> >> >> smtp.yourdomain.net. However, if that server were unavailable, a
>> >> >> sending
>> >> >> host would try to send the mail to the other server,
>> >> >> SMTP.yourISP.net.
>> >> >> When
>> >> >> smtp.yourdomain.net came back into service, it would then receive
>> >> >> the
>> >> >> queued
>> >> >> messages from the ISP MTA, SMTP.yourISP.net.
>> >> >>
>> >> >> One caveat to be aware of, is that some admins have configured
>> >> >> their
>> >> >> hosts
>> >> >> to look for reverse DNS records as a way to reduce spam. I don't
>> >> >> consider
>> >> >> this effective, but that's my opinion. The reason I don't, is
>> >> >> because
>> >> >> I
>> >> >> can
>> >> >> have a sending host that is not also a receiving a host and
>> >> >> therefore
>> >> >> I
>> >> >> wouldn't have a corresponding MX record. To have the sending and
>> >> >> receiving
>> >> >> host be the same, is more often done in smaller IT shops vs. the
>> >> >> larger
>> >> >> and
>> >> >> global shops. By RFC, I am not required to have an MX record for a
>> >> >> host
>> >> >> that
>> >> >> is sending only nor would I want to as there would be no path for
>> >> >> that
>> >> >> mail
>> >> >> handler to ever deliver a message. A PTR record is a good idea for
>> >> >> your
>> >> >> sending host for the same reason. While not required, it is a good
>> >> >> idea
>> >> >> to
>> >> >> more reliably transfer messages with your customers because some
>> >> >> hosts
>> >> >> are
>> >> >> configured to check for a reverse lookup when receiving a message
>> >> >> from
>> >> >> your
>> >> >> domain. Same goes with SPF records (you may want one); I don't spf
>> >> >> records
>> >> >> as effective nor desirable, but what do I know? ;)
>> >> >>
>> >> >>
>> >> >> Does that help?
>> >> >>
>> >> >> Al
>> >> >>
>> >> >>
>> >> >>
>> >> >> "Gary Demi" <GaryDemi@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> >> >> news:1067F097-FA48-4B5F-97D3-5F0957549B12@xxxxxxxxxxxxxxxx
>> >> >> >I thought two MX records where required. The MX records should
>> >> >> >read
>> >> >> >something
>> >> >> > liklike mail.yourdomain.com or smtp.yourdomain.com (what prefix
>> >> >> > does
>> >> >> > Exchange
>> >> >> > use, and what help file are you referring to?
>> >> >> >
>> >> >> > Thanks
>> >> >> > --
>> >> >> > Gary Demi
>> >> >> > Software & Communication Concepts, Inc.
>> >> >> > Microsoft Registered Partner
>> >> >> > Houston, & Phoenix
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > "Al Mulnick" wrote:
>> >> >> >
>> >> >> >> Two MX resource records?
>> >> >> >>
>> >> >> >> MX resource records are used to designate mail handlers for your
>> >> >> >> domain.


.

Relevant Pages

  • Re: Newbie to Exchange needs MX record info
    ... As I undersand it now you can give your mail server any name (in the MX ... > tektoneco.net nameserver = park10.secureserver.net ... > for the responsible host. ... I took the cname records out for mail and set my mx ...
    (microsoft.public.exchange.setup)
  • Re: fedora-list Digest, Vol 12, Issue 126
    ... I add a domain, a host record, save and restart named and when I ... to go about it is to specify the name server you want to query against: ... The second hostname is the nameserver to use. ... entry for your host is probably wrong in your zone file. ...
    (Fedora)
  • Re: TN3270 Question
    ... I took a look at RFC 2355, ... The server should not send anything to the host ... application on behalf of the client. ...
    (bit.listserv.ibm-main)
  • Re: Internet connection snafu
    ... >>I can't get internet or mail to 3work on my desktop install. ... >>my ISP's name server is not known, but I know they are correct. ... > Host not found, try again. ... > connect to a nameserver at the IP address you gave it. ...
    (alt.os.linux.suse)
  • Re: RFC2822/RFC822-konforme Mails versenden
    ... directly to the host and that the host will resolve the user name, ... Mails über Exchange abzusetzen. ... Im RFC steht imho das eine gültige Absendedomäne ... Server durch einen eindeutigen eingehenden Anschluss definiert ist. ...
    (microsoft.public.de.exchange)