SMTP FQDN does not match DNS resolved name

Discussion in 'Windows Small Business Server' started by Roman B., Jul 3, 2008.

  1. Roman B.

    Roman B. Guest

    I'm running a SBS 2003 server, and I get the message below when I run the
    microsoft exchange troubleshooting assistant software. anyone know how I can
    fix this.


    The fully-qualified domain name of SMTP virtual server 'Default SMTP Virtual
    Server' on server srv1 does not match the DNS resolved server name. This may
    cause mail routing problems. SMTP virtual server: mycompany.org. DNS resolved
    server name: srv1.mycompany.local.


    Thanks
    Roman
     
    Roman B., Jul 3, 2008
    #1
    1. Advertisements

  2. Roman B.

    Joe Guest

    No, you don't fix it and you don't pay too much attention to the
    Exchange troubleshooter, which is assuming that the Exchange
    installation is that of a large organisation, which manages its own
    public DNS service.

    Best practice, as stated by Microsoft, is for the SBS domain to have a
    name which is invalid on the Internet ('local' may have to be re-thought
    soon, as custom TLDs seem to be on the way). The FQDN of the SBS SMTP
    virtual server can be set to anything, but whatever it is must be able
    to be resolved to a real non-private IP address using public DNS, the
    address you send mail from. These two conditions mean that a
    properly-configured SBS hostname can never match the SMTP FQDN. Don't
    worry about it.

    What you need to worry about is that the FQDN resolves to the IP address
    you send mail from, if you're sending mail by DNS, and it's good
    practice even if you're sending by smarthost (as you can temporarily
    switch to DNS to test things). It usually simplifies things if it also
    matches you domain's MX record, as the corresponding A record already
    exists. Finally you need to ensure that the reverse DNS of your IP
    address, the PTR record, can also be resolved by public DNS back to the
    IP address. If the PTR matches your MX and/or SMTP FQDN, so much the
    better, as it is alleged that some receiving mail servers check for this.

    If you're sending email by smarthost and collecting by POP3, none of
    this matters, but presumably then you wouldn't be running the Exchange
    troubleshooter.
     
    Joe, Jul 3, 2008
    #2
    1. Advertisements

  3. Roman B.

    Roman B. Guest

    Joe,

    I have a reverse DNS lookup with our ISP, which points our public ISP IP
    address to mail.mycompany.com.
    Question: When you talk about an A record. Are you talking Reverse Lookup
    Zone in my DNS on my server? Sorry I'm a little confused. Right now my DNS
    FORWARD and Reverse Lookup Zones contain A records that point to private IP
    addresses.

    Thanks in advance for your help. I very much appreciate it.

    Roman
     
    Roman B., Jul 3, 2008
    #3
  4. Roman B.

    Joe Guest

    No, that's the reason for using an invalid domain name for the SBS. The
    SBS DNS server is completely isolated from the outside world in terms of
    its stored records, at least after a default installation. It is not
    accessible publicly, and you don't normally need to make any changes to
    it. Neither its hostnames nor its private IP addresses are visible to
    the outside world.

    All the DNS records needed for mail delivery and transmission will be
    held in public DNS servers. The PTR record, also known as reverse DNS,
    is in your ISP's reverse lookup zone for his IP address range. When
    properly set up (and some ISPs are difficult about this) it will contain
    a hostname which will appear in the forward lookup zone of (usually)
    someone else's DNS server, which handles your public domain name. There
    will be one or more A records, normal forward DNS records, and one or
    more MX records for mail servers. There may be other kinds, but only
    these two matter for email.

    MX records contain hostnames, and there may be more than one for a
    domain. They have a number associated with them, and numbered MX records
    are tried in ascending order until a mail server replies, this is how
    secondary or backup mail servers are specified. The A records are for
    hostnames, and contain IP addresses. So each MX record must contain a
    hostname, which must appear somewhere in the world as an A record, which
    leads to an IP address. The PTR record for this address must contain a
    hostname which has an A record which points back to the IP address.
    Since more than one A record can exist for one IP address, then the
    PTR/A pair of records do not need to refer to the same hostname as the
    MX record (mine don't), but they often do.

    To receive email by SMTP, you need an MX record and its associated A
    record, both in the DNS server of your domain host. Typically the MX
    hostname will be mail.domain.com, but it doesn't need to be. The A
    record points to your public IP address. The domain host will either
    configure these records on request, or to save itself the trouble, will
    offer you a web page where you configure them.

    To send mail by SMTP, it's a little more complicated, and depends on the
    configuration of the server you're trying to send to. There are a few
    rules that most mail servers seem to require senders to comply with, to
    try to reduce the amount of spam sent to them. Almost all mail servers
    now will want:

    -The PTR record for your IP address to be a real hostname, which can be
    looked up in public DNS as an A record.

    -The A record to point back to your IP address.

    -Your mail server's FQDN string (sent in the HELO or EHLO of an SMTP
    transaction) to be a real hostname which has an A record in public DNS.

    -This A record to also point back to your IP address.

    As you can see, the simplest way to achieve this is to make up a
    hostname for your mail server, such as mail.domain.com, and create an A
    record for this at your domain host, leading to your IP address. You can
    then set the domain MX record, the ISP's PTR record and the Exchange
    FQDN to this hostname and all of these criteria will be satisfied. This
    is a common configuration, so much so that some mail servers are alleged
    to require it before accepting mail.

    Now to the Exchange troubleshooter: if you were to use public IP
    addresses on the servers within your network, and host your own public
    DNS server, you would set your internal domain name to be same as the
    public domain name. Your Exchange server would then really have the
    hostname which the MX and other records would point to, and the
    troubleshooter would be happy.

    If you don't have multiple public IP addresses and host the public DNS
    yourself, it is not advisable to use the public domain name internally,
    as reaching external resources which use your domain name becomes messy.
    Microsoft specifically advises against it with SBS. Therefore the
    Exchange troubleshooter is never going to be happy about SBS, at least
    in this respect.
     
    Joe, Jul 3, 2008
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.